On 12 Dec 2022 13:58:51 -0500 Theodore Ts'o <tytso@xxxxxxx>
> On Mon, Dec 12, 2022 at 11:29:11AM +0800, Hillf Danton wrote:
> > > You've completely misunderstood Al's point. He's not whining about
> > > being cc'd, he's pointing at this is ONLY USEFUL IF THE NTFS3
> > > MAINTAINERS ARE CC'd. And they're not. So this is just noise.
> > > And enough noise means that signal is lost.
> >
> > Call Trace:
> > <TASK>
> > inode_unlock include/linux/fs.h:761 [inline]
> > done_path_create fs/namei.c:3857 [inline]
> > do_mkdirat+0x2de/0x550 fs/namei.c:4064
> > __do_sys_mkdirat fs/namei.c:4076 [inline]
> > __se_sys_mkdirat fs/namei.c:4074 [inline]
> > __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4074
> > do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> > do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
> > entry_SYSCALL_64_after_hwframe+0x63/0xcd
> >
> > Given the call trace above, how do you know the ntfs3 guys should be also
> > Cced in addition to AV? What if it would take more than three months for
> > syzbot to learn the skills in your mind? What is preventing you routing
> > the report to ntfs3?
>
> If it takes 3 months for syzbot to take a look at the source code in
> their own #!@?! reproducer, or just to take a look at the strace link
> in the dashboard:
>
> [pid 3639] mount("/dev/loop0", "./file2", "ntfs3", MS_NOSUID|MS_NOEXEC|MS_DIRSYNC|MS_I_VERSION, "") = 0
>
> There's something really wrong. The point Al has been making (and
> I've been making for multiple years) is that Syzbot has the
> information, but unfortunately, at the moment, it is only analyzing
> the the stack trace, and it is not doing things that really could be
> done automatically --- and cloud VM time is cheap, and upstream
Another case of easy talk instead of patching hard?
What is preventing you from making the syzbot more automatic?
Is it sane to teach the bot to patch ext4 because you are a maintainer?
> maintainer time is expensive. So by not improving syzbot in a way
> that really shouldn't be all that difficult, the syzbot maintainers is
> disrespectiving the time of the upstream maintainers.
Are upstream maintainers prefering to spend weeks and months creating
ext4 beatles for example over taking a couple of hours scanning the
syzbot reports like this one? Why does the bot kick you if you have a
clean butt? Why are usb people irrelevant in this case?
>
> So sure, we could ask Linus to triage all syzbot reports --- or we
> could ask Al to triage all syzbot file system reports --- but that is
> not a good use of upstream resources.
Lolll who is preventing you from doing so? Who care/complain if you do?
Why not directly fix today what was reported instead and issue a PR?
