On 14/10/23 07:24, Theodore Ts'o wrote:
Hi Ted,
On Fri, Oct 13, 2023 at 02:28:52AM +0530, Shreeya Patel wrote:
Just to clarify, this issue is still seen on upstream 5.10 and earlier
kernels.
I can confirm that we did not see this issue being reproduced on mainline
kernel using #sys test feature.
So I'm confused. In the original post on this thread[1], it was stated:
When I tried to reproduce this issue on mainline linux kernel using the
reproducer provided by syzbot, I see an endless loop of following errors :-
I stated this because at that time we didn't know we could use #syz test
feature on buganizer tickets as well.
I locally tested it using the reproducer and I was seeing an endless
loops of errors which I thought
is something not an expected behaviour.
This was happening on mainline as well as 5.10 kernel.
and
#regzbot introduced: v6.6-rc1..
[1] https://lore.kernel.org/all/d89989ef-e53b-050e-2916-a4f06433798b@xxxxxxxxxxxxx/
... and now you're sayingg this *wasn't* reproduced upstream? And of
course, because this was a private syzbot instance, there was syzbot
dashboard given, and the reproducer had the serial number filed off
(there is a URL in the comments at the beginning of the reproducer for
a *reason*), so *I* couldn't run "#syz test".
Huh?
Reading between the lines, it looks like the only similarity between
what was happening in the 5.10 kernel and the mainline kernel was that
it did not *hang* the kernel, but it was generating a stream of
EXT4-fs error messages. Well, if you take a deliberately corrupted
kernel, and mount it with errors=continue, and then keep pounding it
with lots of file system operations, of *course* it will continually
spew ext4 errors message. That is "Working As Intended" by
*definition*.
This is what I actually wanted to understand if the loops of errors were
something of concern or not.
I'm not an expert in the area of filesystem so I assumed loops of errors
that I was seeing
shouldn't be an intented behaviour.
And this is why I maintain that irresponsible use of syzbot is
effectively a denial of service attack on upstream maintainers.
At this point, just as upstream policy is that debugging ancient LTS
kernels is not something upstream maintainers to do (and attempting to
trick them to debug it by claiming it is found in mainline is *really*
uncool), if there are bugs that are reported using private syzbot
instances, or where there isn't a URL to a public syzbot dashboard,
they should be treated as P4 priority or worse....
We never had the intention to trick you into debugging this issue. When
I reported this issue,
I did it on the basis of what I saw after using the reproducer locally.
After some days when I came to know we could use #syz test in buganizer,
I tested mainline and 5.10 kernel again through it
but I didn't see it getting reproduced on mainline kernel and hence I
said it didn't reproduce upstream in my second email.
I should have given you more context when I said it doesn't happen in
upstream kernel so I'm sorry for the misunderstanding.
Thanks,
Shreeya Patel
- Ted
