Messages in this thread | | | From | Marco Elver <> | Date | Thu, 7 Dec 2023 18:05:10 +0100 | Subject | Re: [PATCH v2 1/3] perf: Reorder overflow handler ahead of event_limit/sigtrap |
| |
On Thu, 7 Dec 2023 at 17:35, Kyle Huey <me@kylehuey.com> wrote: > > The perf subsystem already allows an overflow handler to clear pending_kill > to suppress a fasync signal (although nobody currently does this). Allow an > overflow handler to suppress the other visible side effects of an overflow, > namely event_limit accounting and SIGTRAP generation. > > Signed-off-by: Kyle Huey <khuey@kylehuey.com> > --- > kernel/events/core.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/kernel/events/core.c b/kernel/events/core.c > index b704d83a28b2..19fddfc27a4a 100644 > --- a/kernel/events/core.c > +++ b/kernel/events/core.c > @@ -9541,6 +9541,12 @@ static int __perf_event_overflow(struct perf_event *event, > */ > > event->pending_kill = POLL_IN; > + > + READ_ONCE(event->overflow_handler)(event, data, regs); > + > + if (!event->pending_kill) > + return ret;
It's not at all intuitive that resetting pending_kill to 0 will suppress everything else, too. There is no relationship between the fasync signals and SIGTRAP. pending_kill is for the former and pending_sigtrap is for the latter. One should not affect the other.
A nicer solution would be to properly undo the various pending_* states (in the case of pending_sigtrap being set it should be enough to reset pending_sigtrap to 0, and also decrement event->ctx->nr_pending).
Although I can see why this solution is simpler. Perhaps with enough comments it might be clearer.
Preferences?
| |