From: Hillf Danton <hdanton@sina.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: syzbot <syzbot+919c5a9be8433b8bf201@syzkaller.appspotmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] WARNING in do_mkdirat
Date: Sun, 11 Dec 2022 18:22:08 +0800 [thread overview]
Message-ID: <20221211102208.2600-1-hdanton@sina.com> (raw)
In-Reply-To: <Y5WXNhO9UNogf8lq@ZenIV>
On 11 Dec 2022 08:39:18 +0000 Al Viro <viro@zeniv.linux.org.uk>
> On Sun, Dec 11, 2022 at 03:56:12PM +0800, Hillf Danton wrote:
> > On 11 Dec 2022 02:52:57 +0000 Al Viro <viro@zeniv.linux.org.uk>
> > > On Sat, Dec 10, 2022 at 06:30:22PM -0800, syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > > WARNING in done_path_create
> > >
> > > How many times does it need to be repeated that ANY BUG REPORTS INVOLVING NTFS3 IN
> > > REPRODUCER NEED TO BE CCED TO MAINTAINERS OF NTFS3?
> > >
> > > I'm done with any syzbot output. From now on it's getting triaged
> > > straight to /dev/null here.
> >
> > Calm downnnnnn Sir even if this is not the east ender style.
> >
> > Frankly no interest here at all wasting any network bandwidth just to get you
> > interrupted if it would take less than 72 hours to discover one of the beatles
> > you created. And actually more than double check is needed to ensure who
> > did that.
>
> The first iterations of the same suggestion had been a lot calmer...
> One of the earlier examples: https://lore.kernel.org/all/YzEJ2D8kga+ZRDZx@ZenIV/
> And I distinctly remember similar attempts from other folks.
>
> It's really a matter of triage; as it is, syzkaller folks are
> expecting that any mail from the bot will be looked into by everyone
> on fsdevel, on the off-chance that it's relevant for them. What's
FILESYSTEMS (VFS and infrastructure)
M: Alexander Viro <viro@zeniv.linux.org.uk>
L: linux-fsdevel@vger.kernel.org
S: Maintained
F: fs/*
F: include/linux/fs.h
F: include/linux/fs_types.h
F: include/uapi/linux/fs.h
F: include/uapi/linux/openat2.h
_> ls fs/* | grep ntfs
fs/ntfs:
ntfs.h
fs/ntfs3:
fsntfs.c
ntfs.h
ntfs_fs.h
Why not change what you really want to cover instead of complaining once more
and opting to triage?
> more, it's not just "read the mail" - information in the mail body
> is next to useless in such situations. So you are asking to
> * start a browser
> * cut'n'paste the URL from MUA
> * dig around in the files linked to the damn thing
> ... all of that for an fs maintainer to see if his filesystem is
> even present? Seriously? For each syzbot fsdevel posting?
>
> I would have looked at it anyway; granted, seeing ntfs3 I'd chalked
> it up to ntfs bugs (fs/ntfs3 has not been there for long and it didn't get
> outright memory corruptors beaten out of it yet).
>
> But how the bleeding hell are ntfs folks supposed to guess that
> this report might be relevant for them? Same for XFS, ext4, orangefs,
> et sodding cetera - and for most of those any of such reports would've
> ended up wasted time for the good and simple reasons that it's not
> any fs they'd been involved with.
>
> What really pisses me off is that on the sending side the
> required check is trivial - if you are going to fuzz a filesystem,
> put a note into report, preferably in subject. Sure, it's your
> code, you get to decide what to spend your time upon (you == syzkaller
> maintainers). But please keep in mind that for recepients it's
> a lot of recurring work, worthless for the majority of those who
> end up bothering with it. Every time they receive a mail from
> that source.
>
> Ignore polite suggestions enough times, earn a mix of
> impolite ones and .procmailrc recipes, it's that simple...
>
next prev parent reply other threads:[~2022-12-11 10:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20221211002908.2210-1-hdanton@sina.com>
[not found] ` <00000000000025ff8d05ef842be6@google.com>
[not found] ` <Y5VGCefLZmrOyd0Z@ZenIV>
2022-12-11 7:56 ` [syzbot] WARNING in do_mkdirat Hillf Danton
2022-12-11 8:39 ` Al Viro
2022-12-11 10:22 ` Hillf Danton [this message]
2022-12-11 15:46 ` Matthew Wilcox
2022-12-11 20:54 ` Al Viro
2022-12-12 3:29 ` Hillf Danton
2022-12-12 18:58 ` Theodore Ts'o
2022-12-12 19:29 ` Marco Elver
2022-12-13 1:44 ` Al Viro
2022-12-13 2:25 ` Hillf Danton
2022-12-16 15:48 ` Aleksandr Nogikh
2022-12-29 21:17 ` Eric Biggers
2022-12-31 16:57 ` Theodore Ts'o
2022-12-31 17:03 ` Randy Dunlap
2023-01-03 13:36 ` Aleksandr Nogikh
2022-12-13 1:47 ` Hillf Danton
2022-12-13 3:36 ` Al Viro
2022-12-13 4:12 ` Hillf Danton
2022-12-13 11:05 ` Alexander Potapenko
[not found] <00000000000064d06705eeed9b4e@google.com>
2022-12-04 1:04 ` Hillf Danton
2022-12-09 19:50 ` syzbot
2022-12-09 19:57 ` Matthew Wilcox
2022-12-10 18:06 ` syzbot
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=20221211102208.2600-1-hdanton@sina.com \
--to=hdanton@sina.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=syzbot+919c5a9be8433b8bf201@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/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).