linux-kernel - Re: WARNING in mark

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+ZR9T9jGqx2aEijAzA8XP3W5gtGWtgubjW-WXBMirEAqA@mail.gmail.com>
Date:   Tue, 25 Jun 2019 14:07:42 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        syzbot <syzbot+a861f52659ae2596492b@...kaller.appspotmail.com>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: WARNING in mark_lock

On Tue, Jun 25, 2019 at 1:06 PM Peter Zijlstra <peterz@...radead.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.