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]

Date:   Tue, 25 Jun 2019 16:01:29 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Dmitry Vyukov <dvyukov@...gle.com>
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 02:07:42PM +0200, Dmitry Vyukov wrote:
> 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.

Ah, for my own machines I spool all serial console output to a file,
everything is preserved until logrotate kills it after a week or so.

There is no distinction between boot and anything else, everything that
goes to serial (and I make sure everything does) lands together.

> What info are you interested in? Can if be obtained after boot?

I was interested in the kernel commandline; and in particular the
nohz_full configuration if any.