From: Dmitry Vyukov <dvyukov@google.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
syzbot <syzbot+6004acbaa1893ad013f0@syzkaller.appspotmail.com>,
Arnd Bergmann <arnd@arndb.de>, Jens Axboe <axboe@kernel.dk>,
Borislav Petkov <bp@alien8.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Christian Brauner <christian@brauner.io>,
David Howells <dhowells@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Hannes Reinecke <hare@suse.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@redhat.com>,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
Thomas Gleixner <tglx@linutronix.de>,
"the arch/x86 maintainers" <x86@kernel.org>
Subject: Re: general protection fault in do_move_mount (2)
Date: Fri, 5 Jul 2019 15:02:54 +0200 [thread overview]
Message-ID: <CACT4Y+ZR98hxgG9GC0ijC_o0UuYdYEY2pAnf01nBLNTjhG4+Vw@mail.gmail.com> (raw)
In-Reply-To: <20190701151808.GA790@sol.localdomain>
On Mon, Jul 1, 2019 at 5:18 PM Eric Biggers <ebiggers@kernel.org> wrote:
> > > FYI, it also isn't really appropriate for syzbot to bisect all bugs in new
> > > syscalls to wiring them up to x86, and then blame all the x86 maintainers.
> > > Normally such bugs will be in the syscall itself, regardless of architecture.
> >
> > Agree. Do you think it's something worth handling automatically
> > (stands out of the long tail of other inappropriate cases)? If so, how
> > could we detect such cases? It seems that some of these predicates are
> > quite hard to program. Similar things happen with introduction of new
> > bug detection tools and checks, wiring any functionality to new access
> > points and similar things.
> >
>
> Yes, this case could easily be automatically detected (most of the time) by
> listing the filenames changed in the commit, and checking whether they all match
> the pattern syscall.*\.tbl. Sure, it's not common, but it could be alongside
> other similar straightforward checks like checking for merge commits and
> checking for commits that only modify Documentation/.
>
> I'm not even asking for more correct bisection results at this point, I'm just
> asking for fewer bad bisection results.
Agree, if we implement a common framework for doing this type of
checks and affecting reporting in some fixed set of ways, adding more
rules can make sense even if they don't affect lots of cases. I filed
https://github.com/google/syzkaller/issues/1271 for this.
There are several open questions, though.
1. The syscall.*\.tbl change is formally the right bisection result
and it communicates a bit of potentially useful information. Do we
want to handle them differently from, say, Documentation/* changes
which are significantly a different type "incorrect".
2. You mentioned merges. It seems that they can be just anything:
completely incorrect results; formally correct, but not the change
that introduced the bug; as well as the totally right commit to blame.
Are you sure we should mark all of them as completely incorrect?
prev parent reply other threads:[~2019-07-05 13:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 10:47 general protection fault in do_move_mount (2) syzbot
2019-06-18 14:02 ` Al Viro
2019-06-24 9:28 ` Dmitry Vyukov
2019-06-29 20:27 ` [PATCH] vfs: move_mount: reject moving kernel internal mounts Eric Biggers
2019-06-29 20:39 ` Al Viro
2019-07-01 1:08 ` Al Viro
2019-07-01 15:43 ` Eric Biggers
2019-07-01 7:38 ` David Howells
2019-07-01 11:19 ` Al Viro
2019-07-01 16:45 ` Eric Biggers
2019-07-01 18:22 ` Al Viro
2019-07-01 19:20 ` Al Viro
2019-07-02 18:22 ` Eric Biggers
2019-07-09 19:40 ` Eric Biggers
2019-07-09 20:54 ` Al Viro
2019-07-10 3:23 ` 6 new syscalls without tests (was: [PATCH] vfs: move_mount: reject moving kernel internal mounts) Eric Biggers
2019-07-05 9:01 ` move_mount.2 David Howells
2019-06-29 20:39 ` general protection fault in do_move_mount (2) Eric Biggers
2019-07-01 14:59 ` Dmitry Vyukov
2019-07-01 15:18 ` Eric Biggers
2019-07-05 12:17 ` Dmitry Vyukov
2019-07-05 13:02 ` Dmitry Vyukov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACT4Y+ZR98hxgG9GC0ijC_o0UuYdYEY2pAnf01nBLNTjhG4+Vw@mail.gmail.com \
--to=dvyukov@google.com \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=christian@brauner.io \
--cc=dhowells@redhat.com \
--cc=ebiggers@kernel.org \
--cc=geert@linux-m68k.org \
--cc=hare@suse.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=syzbot+6004acbaa1893ad013f0@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).