On Sat, 1 May 2021 at 01:23, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > I am looking at perf_sigtrap and I am confused by the code. > > > /* > * We'd expect this to only occur if the irq_work is delayed and either > * ctx->task or current has changed in the meantime. This can be the > * case on architectures that do not implement arch_irq_work_raise(). > */ > if (WARN_ON_ONCE(event->ctx->task != current)) > return; > > /* > * perf_pending_event() can race with the task exiting. > */ > if (current->flags & PF_EXITING) > return; > > > It performs tests that absolutely can never fail if we are talking about > a synchronous exception. The code force_sig family of functions only > make sense to use with and are only safe to use with synchronous > exceptions. > > Are the tests in perf_sigtrap necessary or is perf_sigtrap not reporting > a synchronous event? Yes it's synchronous, insofar that the user will receive the signal right when the event happens (I've tested this extensively, also see tools/testing/selftests/perf_events). Of course, there's some effort involved from the point where the event triggered to actually safely delivering the signal. In particular, for HW events, these arrive in NMI, and we can't do much in NMI, and therefore will queue an irq_work. On architectures that properly implement irq_work, it will do a self-IPI, so that once it is safe to do so, another interrupt is delivered where we process the event and do the force_sig_info(). The task where the event occurred never got a chance to run -- except for bad architectures with broken irq_work, and the first WARN_ON() is there so we don't crash the kernel if somebody botched their irq_work. Since we're talking about various HW events, these can still trigger while the task is exiting, before perf_event_exit_task() being called during do_exit(). That's why we have the 2nd check. Thanks, -- Marco
