linux-kernel - Re: [PATCH 01/12] iomap: check if folio size is equal to FS block size

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: <ZwChy4jNCP6gJNJ0@casper.infradead.org>
Date: Sat, 5 Oct 2024 03:17:47 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Goldwyn Rodrigues <rgoldwyn@...e.de>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Goldwyn Rodrigues <rgoldwyn@...e.com>
Subject: Re: [PATCH 01/12] iomap: check if folio size is equal to FS block
 size

On Fri, Oct 04, 2024 at 04:04:28PM -0400, Goldwyn Rodrigues wrote:
> Filesystems such as BTRFS use folio->private so that they receive a
> callback while releasing folios. Add check if folio size is same as
> filesystem block size while evaluating iomap_folio_state from
> folio->private.
> 
> I am hoping this will be removed when all of btrfs code has moved to
> iomap and BTRFS uses iomap's subpage.

This seems like a terrible explanation for why you need this patch.

As I understand it, what you're really doing is saying that iomap only
uses folio->private for block size < folio size.  So if you add this
hack, iomap won't look at folio->private for block size == folio size
and that means that btrfs can continue to use it.

I don't think this is a good way to start the conversion.  I appreciate
that it's a long, complex procedure, and you can't do the whole
conversion in a single patchset.

Also, please stop calling this "subpage".  That's btrfs terminology,
it's confusing as hell, and it should be deleted from your brain.

But I don't understand why you need it at all.  btrfs doesn't attach
private data to folios unless block size < page size.  Which is precisely
the case that you're not using.  So it seems like you could just drop
this patch and everything would still work.