[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181206154425.GA21381@krava>
Date: Thu, 6 Dec 2018 16:44:25 +0100
From: Jiri Olsa <jolsa@...hat.com>
To: Vince Weaver <vincent.weaver@...ne.edu>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Namhyung Kim <namhyung@...nel.org>,
Andi Kleen <andi@...stfloor.org>
Subject: Re: perf: perf_fuzzer triggers GPF in perf_prepare_sample
On Thu, Dec 06, 2018 at 10:35:28AM -0500, Vince Weaver wrote:
> On Wed, 5 Dec 2018, Jiri Olsa wrote:
>
> > On Wed, Dec 05, 2018 at 12:11:19PM -0500, Vince Weaver wrote:
> > > On Wed, 5 Dec 2018, Jiri Olsa wrote:
> > >
> > > > On Wed, Dec 05, 2018 at 01:45:38PM +0100, Jiri Olsa wrote:
> > > > > On Tue, Dec 04, 2018 at 10:54:55AM -0500, Vince Weaver wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I was able to trigger another oops with the perf_fuzzer with current git.
> > > > > >
> > > > > > This is 4.20-rc5 after the fix for the very similar oops I previously
> > > > > > reported got committed.
> > > > > >
> > > > > > It seems to be pointing to the same location in the source as
> > > > > > before, I guess maybe triggered a different way?
> > > > >
> > > > > nice.. yep, looks the same
> > > > >
> > > > > >
> > > > > > Unfortunately this crash is not easily reproducible like the last one was.
> > > > >
> > > > > will check
> > > >
> > > > what model are hitting this on?
> > >
> > > Haswell. 6/60/3.
> > >
> > > While I can't deterministically trigger this, the fuzzer usually hits it
> > > within an hour or two. Is there any debug or printk messages I can
> > > add that would help figure out what's going on?
> >
> > I can't see how we could end up with that config other than
> > some corruption.. the only way I see could be that we touch
> > cpu->events array without checking its active_mask bit
> >
> > but that does not explain why the crash happened in the same
> > place as before
>
> Maybe it is a corruption issue. I had applied my own debug patch that
> would dump some info if data->callchain was NULL.
>
> But my debug code didn't trigger this time because it looks like
> data->callchain was "1" rather than "0".
>
> [27764.840179] BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
> [27764.840179] PGD 0 P4D 0
> [27764.840180] Oops: 0000 [#1] SMP PTI
> [27764.840180] CPU: 1 PID: 18687 Comm: perf_fuzzer Tainted: G W 4.20.0-rc5+ #125
> [27764.840180] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS 01/26/2014
actually, you could try that patch from my previous email?
thanks,
jirka
Powered by blists - more mailing lists