[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250415181409.eqkichqm4dddq4z4@offworld>
Date: Tue, 15 Apr 2025 11:14:09 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Jan Kara <jack@...e.cz>
Cc: Luis Chamberlain <mcgrof@...nel.org>, brauner@...nel.org, tytso@....edu,
adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
riel@...riel.com, willy@...radead.org, hannes@...xchg.org,
oliver.sang@...el.com, david@...hat.com, axboe@...nel.dk,
hare@...e.de, david@...morbit.com, djwong@...nel.org,
ritesh.list@...il.com, linux-fsdevel@...r.kernel.org,
linux-block@...r.kernel.org, linux-mm@...ck.org,
gost.dev@...sung.com, p.raghav@...sung.com, da.gomez@...sung.com,
syzbot+f3c6fda1297c748a7076@...kaller.appspotmail.com
Subject: Re: [PATCH v2 1/8] migrate: fix skipping metadata buffer heads on
migration
On Tue, 15 Apr 2025, Jan Kara wrote:
>On Mon 14-04-25 18:36:41, Davidlohr Bueso wrote:
>> On Wed, 09 Apr 2025, Luis Chamberlain wrote:
>>
>> > corruption can still happen even with the spin lock held. A test was
>> > done using vanilla Linux and adding a udelay(2000) right before we
>> > spin_lock(&bd_mapping->i_private_lock) on __find_get_block_slow() and
>> > we can reproduce the same exact filesystem corruption issues as observed
>> > without the spinlock with generic/750 [1].
>>
>> fyi I was actually able to trigger this on a vanilla 6.15-rc1 kernel,
>> not even having to add the artificial delay.
>
>OK, so this is using generic/750, isn't it? How long did you have to run it
>to trigger this? Because I've never seen this tripping...
Correct, generic/750. It triggered after 90+ hrs running.
Powered by blists - more mailing lists