linux-kernel - Re: BUG: unable to handle kernel paging request in do

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] [day] [month] [year] [list]

Message-ID: <CACT4Y+Z8gfJC1a9_WMPRE4Z+qF2wfANkkXCqD3D7YFbkES8XPQ@mail.gmail.com>
Date:   Mon, 20 May 2019 18:22:05 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     "Theodore Ts'o" <tytso@....edu>, Al Viro <viro@...iv.linux.org.uk>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        syzbot <syzbot+73c7fe4f77776505299b@...kaller.appspotmail.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, sabin.rapan@...il.com,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: BUG: unable to handle kernel paging request in do_mount

On Sat, May 18, 2019 at 10:19 PM Theodore Ts'o <tytso@....edu> wrote:
>
> On Sat, May 18, 2019 at 05:21:42PM +0100, Al Viro wrote:
> > IOW, Dan's fix folded into the offending commit.  And that kind of
> > pattern is not rare; I would argue that appending Dan's patch at
> > the end of queue and leaving the crap in between would be a fucking
> > bad idea - it would've left a massive bisection hazard *and* made
> > life much more unpleasant when the things got to merging into the
> > mainline (or reviewing, for that matter).
>
> When this happens in the ext4 git tree, I usually don't worry about
> giving credit to whatever system finds the problem, whether coming
> from it's Coverity, or someone running sparse, or syzbot, etc.
>
> There will always be issues where there are no way to clear out the
> syzbot report via a commit description --- for example, when a patch
> gets dropped entirely from linux-next.  With Coverity, the report gets
> dropped automatically.  With syzbot, it will have closed out by hand.
>
> > What would you prefer to happen in such situations?  Commit summaries
> > modified enough to confuse CI tools into *NOT* noticing that those
> > are versions of the same patch?  Some kind of metadata telling the
> > same tools that such-and-such commits got folded in (and they might
> > have been split in process, with parts folded into different spots
> > in the series, at that)?
> >
> > Because "never fold in, never reorder, just accumulate patches in
> > the end of the series" is not going to fly.  For a lot of reasons.
>
> As far as I'm concerned, this is the tools problem; I don't think it's
> worth it for developers to feel they need to twist themselves into
> knots just to try to make the CI tools' life easier.
>
>                                         - Ted


I've added docs re linux-next handling:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#linux-next
In the end it's still just adding a tag. And it's not so much about
crediting or making somebody's life easier, this is mainly about
making Linux less buggy and higher-quality.