Re: [PATCH v2] perf record: Fix destructor invocation and event counting in fdarray__filter

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] perf record and perf trace hang indefinitely when profiling a target process that exits.
--

--- Patch [1]: [PATCH v2] perf record: Fix destructor invocation and event counting in fdarray__filter ---
commit 586c1ed32764876e9ecee40639dd9f2a7fcfdcd5
Author: Ian Rogers <irogers@google.com>

perf record: Fix destructor invocation and event counting in fdarray__filter

This commit modifies the fdarray filtering logic to separate lifecycle and
masking logic. It removes the early bypass for nonfilterable file descriptors
so their destructors can run, and uses a non_perf_event flag to prevent
clearing their masks.

> diff --git a/tools/lib/api/fd/array.c b/tools/lib/api/fd/array.c
> index 16a047f1906ee..92d9a3fb652c0 100644
> --- a/tools/lib/api/fd/array.c
> +++ b/tools/lib/api/fd/array.c
> @@ -115,9 +115,6 @@ int fdarray__filter(struct fdarray *fda, short revents,
>  		return 0;
>  
>  	for (fd = 0; fd < fda->nr; ++fd) {
> -		if (fda->priv[fd].flags & fdarray_flag__nonfilterable)
> -			continue;
> -
>  		if (!fda->entries[fd].events)
>  			continue;
>  
> @@ -125,6 +122,9 @@ int fdarray__filter(struct fdarray *fda, short revents,
>  			if (entry_destructor)
>  				entry_destructor(fda, fd, arg);
>  
> +			if (fda->priv[fd].flags & fdarray_flag__non_perf_event)
> +				continue;
> +
>  			/*
>  			 * Set fd to -1 so poll() ignores this entry; otherwise

[Severity: High]
With the removal of the early continue for nonfilterable file descriptors,
does this regression cause the active event count to never reach zero? 

When profiling a target process that exits, auxiliary file descriptors like
control pipes usually do not match the revents mask (such as POLLHUP). They
now bypass the revents check block and unconditionally reach the counter
increment at the bottom of the loop:

fdarray__filter()
        ...
		if (fda->entries[fd].revents & revents) {
			...
			continue;
		}

		++nr;
	}

	return nr;
}

In the main event loop, __cmd_record() relies on this function returning 0
to transition to the draining state and terminate gracefully:

    if (fdarray__filter(&thread->pollfd, POLLERR | POLLHUP,
                        record__thread_munmap_filtered, NULL) == 0)
        draining = true;

Since nonfilterable and non-perf-event file descriptors unconditionally
increment nr when they don't have matching revents, could this cause
perf record and perf trace to hang indefinitely waiting in poll()
after the traced process exits?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716073753.567782-1-irogers@google.com?part=1