Hi Peter, On 2022-11-23 at 23:26:43 +0800, Pengfei Xu wrote: > Hi Peter, > > On 2022-11-23 at 16:05:14 +0100, Peter Zijlstra wrote: > > On Sat, Nov 19, 2022 at 10:45:54AM +0800, Pengfei Xu wrote: > > > > > The result shows that your additional patch fixed this issue! > > > If possible, could you add Reported-and-tested-by tag from me. > > > > After talking with Marco for a bit the patch now looks like the below. > > I've tentatively retained your tested-by, except of course, you haven't. > > > > If I could bother you once more to test the branch: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/urgent > > > Yes, sure, it's my pleasure! I will clone and test the origin/perf/urgent > branch in this repo and update the email soon. I tested https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/urgent branch kernel, in the 53171 times execution: Only below dmesg info print, there is no any "__perf_event_overflow" Call Trace, the result show that this issue was fixed in above kernel. " 53171 times ./repro ... [ 59.184213] perf: interrupt took too long (2554 > 2500), lowering kernel.perf_event_max_sample_rate to 78250 [ 59.658503] perf: interrupt took too long (3303 > 3192), lowering kernel.perf_event_max_sample_rate to 60500 [ 60.157042] perf: interrupt took too long (4183 > 4128), lowering kernel.perf_event_max_sample_rate to 47750 [ 60.917294] perf: interrupt took too long (5312 > 5228), lowering kernel.perf_event_max_sample_rate to 37500 [ 62.370105] perf: interrupt took too long (6758 > 6640), lowering kernel.perf_event_max_sample_rate to 29500 [ 64.074435] perf: interrupt took too long (8457 > 8447), lowering kernel.perf_event_max_sample_rate to 23500 [ 66.916168] perf: interrupt took too long (10578 > 10571), lowering kernel.perf_event_max_sample_rate to 18750 [ 70.556182] perf: interrupt took too long (13232 > 13222), lowering kernel.perf_event_max_sample_rate to 15000 [ 76.730150] perf: interrupt took too long (16561 > 16540), lowering kernel.perf_event_max_sample_rate to 12000 [ 557.595321] perf: interrupt took too long (20732 > 20701), lowering kernel.perf_event_max_sample_rate to 9500 " Dmesg is in attached. Thanks! BR. > > > --- > > Subject: perf: Consider OS filter fail > > From: Peter Zijlstra > > Date: Sat, 19 Nov 2022 10:45:54 +0800 > > > > Some PMUs (notably the traditional hardware kind) have boundary issues > > with the OS filter. Specifically, it is possible for > > perf_event_attr::exclude_kernel=1 events to trigger in-kernel due to > > SKID or errata. > > > > This can upset the sigtrap logic some and trigger the WARN. > > > > However, if this invalid sample is the first we must not loose the > > SIGTRAP, OTOH if it is the second, it must not override the > > pending_addr with an invalid one. > > > > Fixes: ca6c21327c6a ("perf: Fix missing SIGTRAPs") > > Reported-by: Pengfei Xu > > Signed-off-by: Peter Zijlstra (Intel) > > Tested-by: Pengfei Xu > > Link: https://lkml.kernel.org/r/Y3hDYiXwRnJr8RYG@xpf.sh.intel.com > > --- > > kernel/events/core.c | 24 ++++++++++++++++++++++-- > > 1 file changed, 22 insertions(+), 2 deletions(-) > > > > --- a/kernel/events/core.c > > +++ b/kernel/events/core.c > > @@ -9273,6 +9273,19 @@ int perf_event_account_interrupt(struct > > return __perf_event_account_interrupt(event, 1); > > } > > > > +static inline bool sample_is_allowed(struct perf_event *event, struct pt_regs *regs) > > +{ > > + /* > > + * Due to interrupt latency (AKA "skid"), we may enter the > > + * kernel before taking an overflow, even if the PMU is only > > + * counting user events. > > + */ > > + if (event->attr.exclude_kernel && !user_mode(regs)) > > + return false; > > + > > + return true; > > +} > > + > > /* > > * Generic event overflow handling, sampling. > > */ > > @@ -9306,6 +9319,13 @@ static int __perf_event_overflow(struct > > } > > > > if (event->attr.sigtrap) { > > + /* > > + * The desired behaviour of sigtrap vs invalid samples is a bit > > + * tricky; on the one hand, one should not loose the SIGTRAP if > > + * it is the first event, on the other hand, we should also not > > + * trigger the WARN or override the data address. > > + */ > > + bool valid_sample = sample_is_allowed(event, regs); > > unsigned int pending_id = 1; > > > > if (regs) > > @@ -9313,7 +9333,7 @@ static int __perf_event_overflow(struct > > if (!event->pending_sigtrap) { > > event->pending_sigtrap = pending_id; > > local_inc(&event->ctx->nr_pending); > > - } else if (event->attr.exclude_kernel) { > > + } else if (event->attr.exclude_kernel && valid_sample) { > > /* > > * Should not be able to return to user space without > > * consuming pending_sigtrap; with exceptions: > > @@ -9330,7 +9350,7 @@ static int __perf_event_overflow(struct > > } > > > > event->pending_addr = 0; > > - if (data->sample_flags & PERF_SAMPLE_ADDR) > > + if (valid_sample && (data->sample_flags & PERF_SAMPLE_ADDR)) > > event->pending_addr = data->addr; > > irq_work_queue(&event->pending_irq); > > }