Date:   Tue, 17 Oct 2023 20:28:52 +0530
From:   Shreeya Patel <shreeya.patel@...labora.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Thorsten Leemhuis <regressions@...mhuis.info>,
        Andres Freund <andres@...razel.de>, linux-ext4@...r.kernel.org,
        Ricardo Cañuelo <ricardo.canuelo@...labora.com>,
        "gustavo.padovan@...labora.com" <gustavo.padovan@...labora.com>,
        groeck@...gle.com, zsm@...gle.com, garrick@...gle.com,
        Linux regressions mailing list <regressions@...ts.linux.dev>,
        gustavo.noronha@...labora.com
Subject: Re: [syzbot] INFO: task hung in ext4_fallocate


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@collabora.com/
>
> ... 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
>

Powered by blists - more mailing lists