linux-kernel - Re: [RFC PATCH 1/1] block/ioctl: Add an ioctl to enable large folios for block buffered IO path

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z0a7f9T5lRPO_sEC@infradead.org>
Date: Tue, 26 Nov 2024 22:26:07 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Bharata B Rao <bharata@....com>
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, nikunj@....com,
	willy@...radead.org, vbabka@...e.cz, david@...hat.com,
	akpm@...ux-foundation.org, yuzhao@...gle.com, mjguzik@...il.com,
	axboe@...nel.dk, viro@...iv.linux.org.uk, brauner@...nel.org,
	jack@...e.cz, joshdon@...gle.com, clm@...a.com
Subject: Re: [RFC PATCH 1/1] block/ioctl: Add an ioctl to enable large folios
 for block buffered IO path

On Wed, Nov 27, 2024 at 11:17:37AM +0530, Bharata B Rao wrote:
> In order to experiment using large folios for block devices read/write
> operations, expose an ioctl that userspace can selectively use on the
> raw block devices.
> 
> For the write path, this forces iomap layer to provision large
> folios (via iomap_file_buffered_write()).

Well, unless CONFIG_BUFFER_HEAD is disabled, the block device uses
the buffer head based write path, which currently doesn't fully
support large folios (although there is series out to do so on
fsdevel right now), so I don't think this will fully work.

But the more important problem, and the reason why we don't use
the non-buffer_head path by default is that the block device mapping
is reused by a lot of file systems, which are not aware of large
folios, and will get utterly confused.  So if we want to do anything
smart on the block device mapping, we'll have to ensure we're back
to state compatible with these file systems before calling into
their mount code, and stick to the old code while file systems are
mounted.

Of course the real question is:  why do you care about buffered
I/O performance on the block device node?