linux-kernel - Re: [PATCH v8 14/18] mm: memfd

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: <aWfLS48tG7XInpNN@kernel.org>
Date: Wed, 14 Jan 2026 18:58:51 +0200
From: Mike Rapoport <rppt@...nel.org>
To: Chris Mason <clm@...a.com>, Pratyush Yadav <pratyush@...nel.org>
Cc: Pasha Tatashin <pasha.tatashin@...een.com>, jasonmiu@...gle.com,
	graf@...zon.com, dmatlack@...gle.com, rientjes@...gle.com,
	corbet@....net, rdunlap@...radead.org,
	ilpo.jarvinen@...ux.intel.com, kanie@...ux.alibaba.com,
	ojeda@...nel.org, aliceryhl@...gle.com, masahiroy@...nel.org,
	akpm@...ux-foundation.org, tj@...nel.org, yoann.congal@...le.fr,
	mmaurer@...gle.com, roman.gushchin@...ux.dev, chenridong@...wei.com,
	axboe@...nel.dk, mark.rutland@....com, jannh@...gle.com,
	vincent.guittot@...aro.org, hannes@...xchg.org,
	dan.j.williams@...el.com, david@...hat.com,
	joel.granados@...nel.org, rostedt@...dmis.org,
	anna.schumaker@...cle.com, song@...nel.org, linux@...ssschuh.net,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-mm@...ck.org, gregkh@...uxfoundation.org, tglx@...utronix.de,
	mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
	x86@...nel.org, hpa@...or.com, rafael@...nel.org, dakr@...nel.org,
	bartosz.golaszewski@...aro.org, cw00.choi@...sung.com,
	myungjoo.ham@...sung.com, yesanishhere@...il.com,
	Jonathan.Cameron@...wei.com, quic_zijuhu@...cinc.com,
	aleksander.lobakin@...el.com, ira.weiny@...el.com,
	andriy.shevchenko@...ux.intel.com, leon@...nel.org, lukas@...ner.de,
	bhelgaas@...gle.com, wagi@...nel.org, djeffery@...hat.com,
	stuart.w.hayes@...il.com, ptyadav@...zon.de, lennart@...ttering.net,
	brauner@...nel.org, linux-api@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, saeedm@...dia.com,
	ajayachandra@...dia.com, jgg@...dia.com, parav@...dia.com,
	leonro@...dia.com, witu@...dia.com, hughd@...gle.com,
	skhawaja@...gle.com, chrisl@...nel.org
Subject: Re: [PATCH v8 14/18] mm: memfd_luo: allow preserving memfd

On Tue, Jan 13, 2026 at 06:09:23AM -0800, Chris Mason wrote:
> On Tue, 25 Nov 2025 11:58:44 -0500 Pasha Tatashin <pasha.tatashin@...een.com> wrote:
> 
> Hi everyone,
> 
> I'm running the v6.19 mm commits through patch review automation, and this
> commit was flagged.  I don't know this code well, but it looks like it
> might be a real bug.
> 
> [AI review output below]
> 
> > diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> > new file mode 100644
> > index 0000000000000..4f6ba63b43105
> > --- /dev/null
> > +++ b/mm/memfd_luo.c
> 
> [ ... ]
> 
> > +static int memfd_luo_retrieve_folios(struct file *file,
> > +				     struct memfd_luo_folio_ser *folios_ser,
> > +				     u64 nr_folios)
> > +{
> > +	struct inode *inode = file_inode(file);
> > +	struct address_space *mapping = inode->i_mapping;
> > +	struct folio *folio;
> > +	int err = -EIO;
> > +	long i;
> > +
> > +	for (i = 0; i < nr_folios; i++) {
> 
> [ ... ]
> 
> > +		err = shmem_add_to_page_cache(folio, mapping, index, NULL,
> > +					      mapping_gfp_mask(mapping));
> > +		if (err) {
> > +			pr_err("shmem: failed to add to page cache folio index %ld: %d\n",
> > +			       i, err);
> > +			goto unlock_folio;
> > +		}
> > +
> > +		if (flags & MEMFD_LUO_FOLIO_UPTODATE)
> > +			folio_mark_uptodate(folio);
> > +		if (flags & MEMFD_LUO_FOLIO_DIRTY)
> > +			folio_mark_dirty(folio);
> > +
> > +		err = shmem_inode_acct_blocks(inode, 1);
> > +		if (err) {
> > +			pr_err("shmem: failed to account folio index %ld: %d\n",
> > +			       i, err);
> > +			goto unlock_folio;
> > +		}
> 
> When shmem_inode_acct_blocks() fails here, the folio has already been
> added to the page cache by shmem_add_to_page_cache(). Should the folio be
> removed from the page cache before going to unlock_folio?
> 
> Looking at shmem_alloc_and_add_folio() in mm/shmem.c, when
> shmem_inode_acct_blocks() fails after the folio has been added, it calls
> filemap_remove_folio() to remove it:
> 
>     error = shmem_inode_acct_blocks(inode, pages);
>     if (error) {
>         ...
>         if (error) {
>             filemap_remove_folio(folio);
>             goto unlock;
>         }
>     }
> 
> Without this, the folio remains in the page cache (counted in
> mapping->nrpages) but info->alloced is not incremented (since
> shmem_recalc_inode is not called). This could cause shmem accounting
> inconsistency.
 
My understanding that if anything fails in memfd_luo_retrieve_folios() the
file is destroyed anyway and the accounting wouldn't matter.

But to be on the safe side we should fix the error handling here.
@Pratyush, what do you say?

-- 
Sincerely yours,
Mike.