Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Tue, 3 Oct 2023 19:25:05 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Andres Freund <andres@anarazel.de>
Cc:     Shreeya Patel <shreeya.patel@collabora.com>,
        linux-ext4@vger.kernel.org,
        Ricardo =?iso-8859-1?Q?Ca=F1uelo?= 
        <ricardo.canuelo@collabora.com>,
        "gustavo.padovan@collabora.com" <gustavo.padovan@collabora.com>,
        groeck@google.com, zsm@google.com, garrick@google.com,
        Linux regressions mailing list <regressions@lists.linux.dev>
Subject: Re: [syzbot] INFO: task hung in ext4_fallocate
Message-ID: <20231003232505.GA444157@mit.edu>
References: <d89989ef-e53b-050e-2916-a4f06433798b@collabora.com>
 <ZQjKOjrjDYsoXBXj@mit.edu>
 <20231003141138.owt6qwqyf4slgqgp@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231003141138.owt6qwqyf4slgqgp@alap3.anarazel.de>
Precedence: bulk

On Tue, Oct 03, 2023 at 07:11:38AM -0700, Andres Freund wrote:
> Hi,
> 
> On 2023-09-18 18:07:54 -0400, Theodore Ts'o wrote:
> > On Mon, Sep 18, 2023 at 08:13:30PM +0530, Shreeya Patel wrote:
> > > 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 :-
> > >
> > > [?? 89.689751][ T3922] loop1: detected capacity change from 0 to 512
> > > [?? 89.690514][ T3916] EXT4-fs error (device loop4): ext4_map_blocks:577:
> > > inode #3: block 9: comm poc: lblock 0 mapped to illegal pblock 9 (length 1)
> > > [?? 89.694709][ T3890] EXT4-fs error (device loop0): ext4_map_blocks:577:
> >
> > Please note that maliciously corrupted file system is considered low
> > priority by ext4 developers.
> 
> FWIW, I am seeing occasional hangs in ext4_fallocate with 6.6-rc4 as well,
> just doing database development on my laptop.

Unless you are using a corrupted file system (e.g., there are EXT4-fs
error messages in dmesg), it's likely a different issue.

There is issue here which doesn't involve a corrupted file system
recently reported:

	https://bugzilla.kernel.org/show_bug.cgi?id=217965

However, *please* let's not conflate bug reports unless we know they
are the same thing.  It's better to keep reports separate, as opposed
to having users see multiple bug reports with vaguely the same
symptoms (say, like a headache) and pestering a doctor at a cocktail
party claiming that *of* *course* their issue is the same as the one
they read about in some vlog because the symptoms are the same.

(This is why I hate, hate, HATE bug reports via Launchpad, which tend
very much to be a flaming hott mess....)

Can you give us details about (a) what kind of block device; are you
using dm-crypt, or just a HDD or a SSD?  If an SSD, what kind of SSD?
What CPU architecture is it?  And can you send me the output of
dumpe2fs -h <block device>?  And while the file system is mounted,
please send the contents of /proc/fs/<block-device>/options, e.g.:

% cat /proc/fs/ext4/dm-0/options 
rw
bsddf
nogrpid
block_validity
dioread_nolock
nodiscard
delalloc
nowarn_on_error
journal_checksum
barrier
auto_da_alloc
user_xattr
acl
noquota
resuid=0
resgid=0
errors=remount-ro
commit=5
min_batch_time=0
max_batch_time=15000
stripe=0
data=ordered
inode_readahead_blks=32
init_itable=10
max_dir_size_kb=0

And finally, how full was the file system?  What is the output of "df
<mountpoint>" and "df -i <mountpoint>".

Thanks,

						- Ted