linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: syzbot <syzbot+73c7fe4f77776505299b@syzkaller.appspotmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	sabin.rapan@gmail.com, syzkaller-bugs@googlegroups.com
Subject: Re: BUG: unable to handle kernel paging request in do_mount
Date: Fri, 17 May 2019 14:48:50 +0100	[thread overview]
Message-ID: <20190517134850.GG17978@ZenIV.linux.org.uk> (raw)
In-Reply-To: <0000000000000eaf23058912af14@google.com>

On Fri, May 17, 2019 at 03:17:02AM -0700, syzbot wrote:
> This bug is marked as fixed by commit:
> vfs: namespace: error pointer dereference in do_remount()
> But I can't find it in any tested tree for more than 90 days.
> Is it a correct commit? Please update it by replying:
> #syz fix: exact-commit-title
> Until then the bug is still considered open and
> new crashes with the same signature are ignored.

Could somebody explain how the following situation is supposed to
be handled:

1) branch B1 with commits  C1, C2, C3, C4 is pushed out
2) C2 turns out to have a bug, which gets caught and fixed
3) fix is folded in and branch B2 with C1, C2', C3', C4' is
pushed out.  The bug is not in it anymore.
4) B1 is left mouldering (or is entirely removed); B2 is
eventually merged into other trees.

This is normal and it appears to be problematic for syzbot.
How to deal with that?  One thing I will *NOT* do in such
situations is giving up on folding the fixes in.  Bisection
hazards alone make that a bad idea.

  reply	other threads:[~2019-05-17 13:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-21  6:44 BUG: unable to handle kernel paging request in do_mount syzbot
2018-09-24 16:09 ` Sabin Rapan
2019-02-22 10:13 ` syzbot
2019-03-08 10:14 ` syzbot
2019-03-22 10:14 ` syzbot
2019-04-05 10:15 ` syzbot
2019-04-19 10:16 ` syzbot
2019-05-03 10:16 ` syzbot
2019-05-17 10:17 ` syzbot
2019-05-17 13:48   ` Al Viro [this message]
2019-05-17 14:08     ` Dmitry Vyukov
2019-05-18 15:00       ` Dmitry Vyukov
2019-05-18 16:21         ` Al Viro
2019-05-18 16:26           ` Al Viro
2019-05-18 20:18           ` Theodore Ts'o
2019-05-18 21:41             ` Al Viro
2019-05-20 14:22               ` Dmitry Vyukov
2019-05-20 16:22             ` Dmitry Vyukov
2019-05-20 14:12           ` Dmitry Vyukov

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=20190517134850.GG17978@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sabin.rapan@gmail.com \
    --cc=syzbot+73c7fe4f77776505299b@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /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).