Re: [PATCH 06/46] mm/filemap: read mapping->a_ops->free_folio under i_lock

[Matthew Wilcox]

On Tue, Oct 27, 2026 at 03:47:35PM +0000, Pedro Falcato wrote:
> On Tue, Oct 27, 2026 at 12:17:26AM +0100, David Hildenbrand (Arm) wrote:
> > From: Josef Bacik <josef@xxxxxxxxxxxxxx>
> > 
> > memory_failure() -> ... -> filemap_remove_folio() can read mapping->a_ops
> > after the inode has been freed. Once the folio is deleted from the
> > pagecache it no longer pins the mapping, so after i_lock is dropped
> > e.g., a concurrent final iput() can evict and free the inode before
> > filemap_free_folio() looks up mapping->a_ops->free_folio.
> 
> Ok, but after iput() then nothing also pins the filesystem, and thus the
> module. So we can be calling into total garbage. So what gives?
> 
> You can't just take the pointer, you need to make sure the filesystem
> is also still alive.

I hate the existance of ->free_folio().  It'd be lovely to get rid of
it, but I think that's outside the scope of this patch series.

This patch narrows down the race (and removing modules is a CONFIG
option anywaysoit actually fixes it for some users).  I think this
patch is a significant enough improvement that it's worth applying and
perhaps we can work on removing ->free_folio in the near future?  There
are only four implementations of it today:

fs/nfs/dir.c:   .free_folio = nfs_readdir_clear_array,
fs/orangefs/inode.c:    .free_folio = orangefs_free_folio,
mm/secretmem.c: .free_folio     = secretmem_free_folio,
virt/kvm/guest_memfd.c: .free_folio = kvm_gmem_free_folio,