lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 17 Oct 2023 20:28:52 +0530
From:   Shreeya Patel <>
To:     Theodore Ts'o <>
Cc:     Thorsten Leemhuis <>,
        Andres Freund <>,,
        Ricardo CaƱuelo <>,
        "" <>,,,,
        Linux regressions mailing list <>,
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]
> ... 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.

Shreeya Patel

> 	      	     		       	  - Ted

Powered by blists - more mailing lists