linux-kernel - Re: [RFC PATCH 0/5] Rust block device driver API and null block driver

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]

Date: Sun, 17 Mar 2024 21:34:01 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Andreas Hindborg <nmi@...aspace.dk>
Cc: Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>,
	Keith Busch <kbusch@...nel.org>,
	Damien Le Moal <Damien.LeMoal@....com>,
	Bart Van Assche <bvanassche@....org>,
	Hannes Reinecke <hare@...e.de>,
	"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
	Andreas Hindborg <a.hindborg@...sung.com>,
	Niklas Cassel <Niklas.Cassel@....com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Alice Ryhl <aliceryhl@...gle.com>,
	Chaitanya Kulkarni <chaitanyak@...dia.com>,
	Luis Chamberlain <mcgrof@...nel.org>,
	Yexuan Yang <1182282462@...t.edu.cn>,
	Sergio González Collado <sergio.collado@...il.com>,
	Joel Granados <j.granados@...sung.com>,
	"Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>,
	Daniel Gomez <da.gomez@...sung.com>,
	open list <linux-kernel@...r.kernel.org>,
	"rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
	"lsf-pc@...ts.linux-foundation.org" <lsf-pc@...ts.linux-foundation.org>,
	"gost.dev@...sung.com" <gost.dev@...sung.com>
Subject: Re: [RFC PATCH 0/5] Rust block device driver API and null block
 driver

On Sun, Mar 17, 2024 at 08:09:53AM +0100, Andreas Hindborg wrote:
> I was under the impression that using folios also give the advantage
> that handles are always head pages. No need to worry about head/tail
> pages. If the driver moves to use higher order pages for larger block
> sizes, would it then make sense with folios, or are page still
> preferred?

This is a good question.

If you do enhance this driver to support larger block sizes, I would
recommend indexing the xarray by sector number instead of page number.
You would allocate a compound page, but at no point would you need to
ask the page what order it is (you already know), you don't need to
change the page flags, etc, etc.

The page cache is in a bit of a different spot.  It has to support
multiple folio sizes for the same file; it has to support folios being
split, it has to support lookup from users who don't know what the folio
size is, etc, etc.

I don't think there's ever a point at which you'd need to call
compound_head() because you'd always look up the head page.  You'd still
want an iterator of some kind to copy to a compound page (because you
can only map one at a time).  And that might look a lot like the folio
copying code.  Probably the right way to handle this is for the folio
copying code to call the page copying code since a folio is always
composed of pages.