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

Message-ID: <20190518214148.GI17978@ZenIV.linux.org.uk>
Date:   Sat, 18 May 2019 22:41:49 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Theodore Ts'o <tytso@....edu>, 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 04:18:43PM -0400, Theodore Ts'o wrote:

> > 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.

FWIW, what _is_ the underlying problem?  It looks like the basic issue
is with rebase/cherry-pick of a commit; it seems to be trying to
handle two things:
	1) report X' in commit C' is similar to report X in commit C,
with C' apparently being a rebase/cherry-pick/whatnot of C; don't
want to lose that information
	2) reports X, Y and Z in commit C don't seem to be reoccuring
on the current tree, without any claimed fix in it.  Want to keep
an eye on those.

... and getting screwed by a mix of those two: reports X, Y and Z in
commit C don't seem to be reoccuring on the current tree, even though
it does contain a commit C' that seems to be a rebase of C.  A fix for
C is *not* present as an identifiable commit in the current tree.
Was it lost or was it renamed/merged with other commits/replaced by
another fix?

What I don't quite understand is why does the tool care.  Suppose
we have a buggy commit + clearly marked fix.  And see a report
very similar to the original ones, on the tree with alleged fix
clearly present.  IME the earlier reports are often quite relevant -
the fix might have been incomplete/racy/etc., and in that case
the old reports (*AND* pointer to the commit that was supposed to
have fixed those) are very useful.

What's the problem these reminders are trying to solve?  Computational
resources eaten by comparisons?