linux-kernel - Re: [PATCH 13/16] mm: update cramfs to use mmap_prepare, mmap

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: <20250908132723.GC616306@nvidia.com>
Date: Mon, 8 Sep 2025 10:27:23 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Jonathan Corbet <corbet@....net>,
	Matthew Wilcox <willy@...radead.org>, Guo Ren <guoren@...nel.org>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	Heiko Carstens <hca@...ux.ibm.com>,
	Vasily Gorbik <gor@...ux.ibm.com>,
	Alexander Gordeev <agordeev@...ux.ibm.com>,
	Christian Borntraeger <borntraeger@...ux.ibm.com>,
	Sven Schnelle <svens@...ux.ibm.com>,
	"David S . Miller" <davem@...emloft.net>,
	Andreas Larsson <andreas@...sler.com>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dan Williams <dan.j.williams@...el.com>,
	Vishal Verma <vishal.l.verma@...el.com>,
	Dave Jiang <dave.jiang@...el.com>, Nicolas Pitre <nico@...xnic.net>,
	Muchun Song <muchun.song@...ux.dev>,
	Oscar Salvador <osalvador@...e.de>,
	David Hildenbrand <david@...hat.com>,
	Konstantin Komarov <almaz.alexandrovich@...agon-software.com>,
	Baoquan He <bhe@...hat.com>, Vivek Goyal <vgoyal@...hat.com>,
	Dave Young <dyoung@...hat.com>, Tony Luck <tony.luck@...el.com>,
	Reinette Chatre <reinette.chatre@...el.com>,
	Dave Martin <Dave.Martin@....com>,
	James Morse <james.morse@....com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	"Liam R . Howlett" <Liam.Howlett@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Michal Hocko <mhocko@...e.com>, Hugh Dickins <hughd@...gle.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Uladzislau Rezki <urezki@...il.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Andrey Konovalov <andreyknvl@...il.com>,
	Jann Horn <jannh@...gle.com>, Pedro Falcato <pfalcato@...e.de>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-csky@...r.kernel.org,
	linux-mips@...r.kernel.org, linux-s390@...r.kernel.org,
	sparclinux@...r.kernel.org, nvdimm@...ts.linux.dev,
	linux-cxl@...r.kernel.org, linux-mm@...ck.org,
	ntfs3@...ts.linux.dev, kexec@...ts.infradead.org,
	kasan-dev@...glegroups.com
Subject: Re: [PATCH 13/16] mm: update cramfs to use mmap_prepare,
 mmap_complete

On Mon, Sep 08, 2025 at 12:10:44PM +0100, Lorenzo Stoakes wrote:
> We thread the state through the mmap_context, allowing for both PFN map and
> mixed mapped pre-population.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> ---
>  fs/cramfs/inode.c | 134 +++++++++++++++++++++++++++++++---------------
>  1 file changed, 92 insertions(+), 42 deletions(-)
> 
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index b002e9b734f9..11a11213304d 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -59,6 +59,12 @@ static const struct address_space_operations cramfs_aops;
>  
>  static DEFINE_MUTEX(read_mutex);
>  
> +/* How should the mapping be completed? */
> +enum cramfs_mmap_state {
> +	NO_PREPOPULATE,
> +	PREPOPULATE_PFNMAP,
> +	PREPOPULATE_MIXEDMAP,
> +};
>  
>  /* These macros may change in future, to provide better st_ino semantics. */
>  #define OFFSET(x)	((x)->i_ino)
> @@ -342,34 +348,89 @@ static bool cramfs_last_page_is_shared(struct inode *inode)
>  	return memchr_inv(tail_data, 0, PAGE_SIZE - partial) ? true : false;
>  }
>  
> -static int cramfs_physmem_mmap(struct file *file, struct vm_area_struct *vma)
> +static int cramfs_physmem_mmap_complete(struct file *file, struct vm_area_struct *vma,
> +					const void *context)
>  {
>  	struct inode *inode = file_inode(file);
>  	struct cramfs_sb_info *sbi = CRAMFS_SB(inode->i_sb);
> -	unsigned int pages, max_pages, offset;
>  	unsigned long address, pgoff = vma->vm_pgoff;
> -	char *bailout_reason;
> -	int ret;
> +	unsigned int pages, offset;
> +	enum cramfs_mmap_state mmap_state = (enum cramfs_mmap_state)context;
> +	int ret = 0;
>  
> -	ret = generic_file_readonly_mmap(file, vma);
> -	if (ret)
> -		return ret;
> +	if (mmap_state == NO_PREPOPULATE)
> +		return 0;

It would be nicer to have different ops than this, the normal op could
just call the generic helper and then there is only the mixed map op.

Makes me wonder if putting the op in the fops was right, a
mixed/non-mixed vm_ops would do this nicely.

Jason