linux-ext4 - Re: [PATCH 2/3] fs/buffer: avoid races with folio migrations on __find_get_block

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z-3spxNHYe_CbLgP@bombadil.infradead.org>
Date: Wed, 2 Apr 2025 19:04:23 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Jan Kara <jack@...e.cz>, brauner@...nel.org, tytso@....edu,
	adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
	riel@...riel.com, 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
Subject: Re: [PATCH 2/3] fs/buffer: avoid races with folio migrations on
 __find_get_block_slow()

On Wed, Apr 02, 2025 at 02:58:28AM +0100, Matthew Wilcox wrote:
> On Tue, Apr 01, 2025 at 02:49:51PM -0700, Davidlohr Bueso wrote:
> > So the below could be tucked in for norefs only (because this is about the addr
> > space i_private_lock), but this also shortens the hold time; if that matters
> > at all, of course, vs changing the migration semantics.
> 
> I like this approach a lot better.  One wrinkle is that it doesn't seem
> that we need to set the BH_Migrate bit on every buffer; we could define
> that it's only set on the head BH, right?

Yes, we are also only doing this for block devices, and for migration
purposes. Even though a bit from one buffer may be desirable it makes
no sense to allow for that in case migration is taking place.  So indeed
we have no need to add the flag for all buffers.

I think the remaining question is what users of __find_get_block_slow()
can really block, and well I've started trying to determine that with
coccinelle [0], its gonna take some more time.

Perhaps its easier to ask, why would a block device mapping want to
allow __find_get_block_slow() to not block?

[0] https://lkml.kernel.org/r/20250403020123.1806887-1-mcgrof@kernel.org

  Luis