linux-kernel - Re: [PATCH v5 2/2] mm: guestmem: Convert address

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] [day] [month] [year] [list]

Message-ID: <Z0DOdTRAaK3whZKW@casper.infradead.org>
Date: Fri, 22 Nov 2024 18:33:25 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Elliot Berman <quic_eberman@...cinc.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Sean Christopherson <seanjc@...gle.com>,
	Fuad Tabba <tabba@...gle.com>,
	Ackerley Tng <ackerleytng@...gle.com>,
	Mike Rapoport <rppt@...nel.org>,
	David Hildenbrand <david@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Jonathan Corbet <corbet@....net>,
	Trond Myklebust <trondmy@...nel.org>,
	Anna Schumaker <anna@...nel.org>,
	Mike Marshall <hubcap@...ibond.com>,
	Martin Brandenburg <martin@...ibond.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	James Gowans <jgowans@...zon.com>, Mike Day <michael.day@....com>,
	linux-fsdevel@...r.kernel.org, kvm@...r.kernel.org,
	linux-coco@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-doc@...r.kernel.org, linux-nfs@...r.kernel.org,
	devel@...ts.orangefs.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v5 2/2] mm: guestmem: Convert address_space operations to
 guestmem library

On Fri, Nov 22, 2024 at 09:29:39AM -0800, Elliot Berman wrote:
> A few near-term features are coming to guest_memfd which make sense to
> create a built-in library.

You haven't created a library, you've created a middle-layer.  This
file primarily consists of functions which redispatch to a function
pointer.  I think you'd be better off creating a library!  That is,
have the consumers register their own address_space_operations and
have functions in this library which provide useful implementations.

That's, eg, how iomap works:

const struct address_space_operations xfs_address_space_operations = {
        .read_folio             = xfs_vm_read_folio,
        .readahead              = xfs_vm_readahead,
        .writepages             = xfs_vm_writepages,
        .dirty_folio            = iomap_dirty_folio,
        .release_folio          = iomap_release_folio,
        .invalidate_folio       = iomap_invalidate_folio,
        .bmap                   = xfs_vm_bmap,
        .migrate_folio          = filemap_migrate_folio,
        .is_partially_uptodate  = iomap_is_partially_uptodate,
        .error_remove_folio     = generic_error_remove_folio,
        .swap_activate          = xfs_iomap_swapfile_activate,
};

Some of these functions are xfs specific, some are iomap specific and
some are the generic VFS implementations.