| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <Y37Lo4n6MKoMABAu@xpf.sh.intel.com>
Date: Thu, 24 Nov 2022 09:40:51 +0800
From: Pengfei Xu <pengfei.xu@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: <peter.zijlstra@...el.com>, <linux-kernel@...r.kernel.org>,
<heng.su@...el.com>, Marco Elver <elver@...gle.com>,
Mark Rutland <mark.rutland@....com>
Subject: Re: [Syzkaller & bisect] There is "__perf_event_overflow" WARNING in
v6.1-rc5 kernel in guest
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 <peterz@...radead.org>
> > 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 <pengfei.xu@...el.com>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> > Tested-by: Pengfei Xu <pengfei.xu@...el.com>
> > 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);
> > }
View attachment "6.1-rc6_perf_urgent_fix_dmesg.log" of type "text/plain" (34902 bytes)
Powered by blists - more mailing lists