public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Marco Elver <elver@google.com>
Cc: Pengfei Xu <pengfei.xu@intel.com>,
	peter.zijlstra@intel.com, linux-kernel@vger.kernel.org,
	heng.su@intel.com, Mark Rutland <mark.rutland@arm.com>
Subject: Re: [Syzkaller & bisect] There is "__perf_event_overflow" WARNING in v6.1-rc5 kernel in guest
Date: Thu, 24 Nov 2022 11:34:07 +0100	[thread overview]
Message-ID: <Y39InxmwK88yKkyp@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <Y38ylOkbhoBEYZjD@hirez.programming.kicks-ass.net>

On Thu, Nov 24, 2022 at 10:00:04AM +0100, Peter Zijlstra wrote:
> On Thu, Nov 24, 2022 at 09:31:10AM +0100, Marco Elver wrote:
> > On Wed, 23 Nov 2022 at 16:05, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > > Subject: perf: Consider OS filter fail
> > > From: Peter Zijlstra <peterz@infradead.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@intel.com>
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > Tested-by: Pengfei Xu <pengfei.xu@intel.com>
> > > Link: https://lkml.kernel.org/r/Y3hDYiXwRnJr8RYG@xpf.sh.intel.com
> > 
> > Thanks, FWIW
> > 
> > Reviewed-by: Marco Elver <elver@google.com>
> > 
> > One thing I wondered was, if the event fired in the kernel due to
> > skid, is the addr always some kernel address, or does this also depend
> > on the type of PMU? In any case, we don't even want to risk leaking
> > kernel addresses this way, so this looks sane.
> 
> That very much depends on the PMU and event. Most events will not fill
> out ->addr at all, some memop specific events can, but only when
> combined with PERF_SAMPLE_ADDR.
> 
> Typically it will then retain the address of the memop. On Intel it's
> mostly just PEBS events that can provide the ADDR and they'll have less
> such trouble. On AMD we have IBS that can do ADDR but I've forgotten
> much about IBS. PowerPC64 also can do ADDR and there I've no clue.

This is also not taking CPU Errata into consideration; there's plenty of
them where the OS filter is 'delayed', in which case you get actual
kernel samples in your 'user only' stream.

  reply	other threads:[~2022-11-24 10:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16  3:39 [Syzkaller & bisect] There is "__perf_event_overflow" WARNING in v6.1-rc5 kernel in guest Pengfei Xu
2022-11-16  3:45 ` Pengfei Xu
2022-11-16 14:40 ` Peter Zijlstra
2022-11-17  1:37   ` Pengfei Xu
2022-11-17 18:11 ` Peter Zijlstra
2022-11-19  2:45   ` Pengfei Xu
2022-11-23 15:05     ` Peter Zijlstra
2022-11-23 15:06       ` Peter Zijlstra
2022-11-23 15:26       ` Pengfei Xu
2022-11-24  1:40         ` Pengfei Xu
2022-11-24  8:31       ` Marco Elver
2022-11-24  9:00         ` Peter Zijlstra
2022-11-24 10:34           ` Peter Zijlstra [this message]
2022-11-24  9:43     ` [tip: perf/urgent] perf: Consider OS filter fail tip-bot2 for Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y39InxmwK88yKkyp@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=elver@google.com \
    --cc=heng.su@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pengfei.xu@intel.com \
    --cc=peter.zijlstra@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox