lkml.org 
[lkml]   [2019]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: WARNING in mark_lock
On Tue, Jun 25, 2019 at 1:06 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, Jun 25, 2019 at 01:03:01PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 25, 2019 at 08:20:56AM +0200, Thomas Gleixner wrote:
> > > On Mon, 24 Jun 2019, syzbot wrote:
> >
> > > > syzbot found the following crash on:
> > > >
> > > > HEAD commit: dc636f5d Add linux-next specific files for 20190620
> > > > git tree: linux-next
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=162b68b1a00000
>
> syzcaller folks; why doesn't the above link include the actual kernel
> boot, but only the userspace bits starting at syzcaller start?
>
> I was trying to figure out the setup, but there's not enough information
> here.

Hi Peter,

Usually there is too much after-boot output, so boot output is evicted
anyway even if was preserved initially. Also usually it's not
important (this is the first time this comes up). And also
structurally boot is a separate procedure in syzkaller VM abstraction,
a machine is booted, output is analyzed for potential crashes, then
the machine is considered in a known good state and then some workload
is started as a separate procedure and new output capturing starts
from this point again.

What info are you interested in? Can if be obtained after boot?
Perhaps I can give it to you now. And there is also this long standing request:
https://github.com/google/syzkaller/issues/466
to collect some kind of "machine info" along with crashes. Perhaps we
need to add the info you are looking for to that list.

\
 
 \ /
  Last update: 2019-06-25 14:09    [W:0.057 / U:23.204 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site