This is not strictly legal C code: declarations must be at the beginning of a block.

Please first update this so the additions follow the coding standard. Some examples of things that don't follow those guidelines:

• comparisons (== and != where the constant is not on the left
• conditions with embedded assignments
• uninitialized local variables (e.g. entry, bytes_read above)
• code should be indented one tab per level (not 8 spaces)
• missing comments on #else and #endif

I have made the changes given by you and updated PR

Missing space after /*.

Please indent with a tab instead of spaces.

• ctype.h is not needed (we can use just strtoull() without isdigit())
• stdint.h is already included via inttypes.h

Suggest moving this declaration to the point of initialization (after line 7581):

	DIR *dir = opendir("/proc");

Suggest we only need one of these buffers at a time (write the first path, try to read that file and only write the second path if necessary).

This must check for negative values:

		if (bytes_read <= 0) {

Likewise on line 7615.

command should be NUL-terminated here:

		command[bytes_read] = '\0';

This should use pid computed above:

		callback_result = callback(pid, command, userData);

New tracepoints must be added to the end of the file; see https://github.com/eclipse-openj9/openj9/blob/master/doc/diagnostics/AddingTracepoints.md.

Locals should be declared in the smallest block possible; entry should be declared where it is initialized (on line 7588).
Only these need to be declared here:

	uintptr_t callback_result = 0;
	DIR *dir = opendir("/proc");

It's not strictly legal in C to declare a local here.

No trailing spaces, please (here and line 7629).

This may truncate commands which can be much longer than PATH_MAX (think megabytes).

This should not impose a fixed limit on the size of a command line. Greater than 4MB is unreasonable for a single stack frame.

This test should be file >= 0 (a negative value signals failure, 0 is a valid file descriptor); same for line 7640.

This should be extracted into a new function which can be reused on line 7641.
Note that the second and subsequent reads should not write to the beginning of command.

I checked kernel header file and The result shows that TASK_COMM_LEN is defined as 16 in the kernel header file

278:#define TASK_COMM_LEN 16
1050: char comm[TASK_COMM_LEN];
1941: BUILD_BUG_ON(sizeof(buf) != TASK_COMM_LEN);
comm is a fixed-size buffer of 16 characters, so it doesn’t need resizing.

I don't see any value in making assumptions about the size of /proc/N/comm.

this is the reference I used: https://man7.org/linux/man-pages/man5/proc_pid_comm.5.html which specifies the command argument length as 16 characters.

Please explain why a function that can handle arbitrarily long cmdline should not also be used for comm.

I have initialised buffer size of command in the beginning as 4096
cmdline argument length can be more than 4 KB so for that first I am trying to read command line and if the buffer is too small then I am resizing by doubling the buffer size until command line fits the buffer
but for comm argument fixed size is 16 characters so it doesn't need resizing

I wasn't suggesting it would need resizing. I am asking why it should be treated differently than reading cmdline, or equivalently, why should the code assume that comm is shorter?

The /proc/[pid]/comm and /proc/[pid]/cmdline fields are treated differently because they serve distinct purposes. comm stores the process name with a fixed 16-character limit, while cmdline contains the full command-line arguments and can be much longer. first information is extracted from cmdline , but it is only available for user-space processes. If cmdline is unavailable, comm is used as a fallback to obtain the executable name.
if you have any other approach I would look into it

I suggested that the code "should be extracted into a new function which can be reused". Doing so avoids making any assumption about the size of the string in comm.

This is not legal C code; variables must be declared at the beginning of a block.

bytes_read should be declared here, the length argument should not include - 1 and the line should be split:

		intptr_t bytes_read = portLibrary->file_read(
				portLibrary,
				file,
				*data + total_bytes_read,
				buffer_size - total_bytes_read);

This should not subtract 1:

		if (total_bytes_read < buffer_size) {

Please split:

		new_data = (char *)portLibrary->mem_reallocate_memory(
				portLibrary,
				*data,
				buffer_size,
				OMR_GET_CALLSITE(),
				OMRMEM_CATEGORY_PORT_LIBRARY);

This is redundant - the caller will store the NUL.

I removed all the subtraction logic (-1) but placed one in the beginning of the read_fully function, to make sure that there is at least one byte left for inserting the NULL character by the caller, in the edge case where the number of bytes read is exactly equal the size of the buffer. hope you are fine with that?

Please remove this macro - it is only used once.

This should be split:

	command = (char *)portLibrary->mem_allocate_memory(
			portLibrary,
			buffer_size,
			OMR_GET_CALLSITE(),
			OMRMEM_CATEGORY_PORT_LIBRARY);

This comment should be more similar to the one on line 7643:

		/* If cmdline is empty, try reading /proc/[pid]/comm. */

Subtracting one here is inappropriate; line 7578 guarantees that when this function succeeds, there is room for a NUL to be appended.

Done