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

[sashiko-bot at kernel.org]

> From: Josef Bacik <josef at toxicpanda.com>
> 
> 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.
> 
> Most callers hold a reference on the inode, but not all.
> 
> Documentation/filesystems/vfs.rst explicitly states that ->free_folio()
> must not assume the original address_space mapping still exists.
> 
> Fix it by loading ->free_folio while i_lock is still held, similar to
> what folio_unmap_invalidate() does.
> 
> Inline filemap_free_folio() into its remaining caller such that
> delete_from_page_cache_batch() also just loads the callback before
> dropping the i_lock.
> 
> The bug was found by code inspection and has not been reproduced.
> 
> Fix generated by an LLM and sent by Josef Bacik in private.
> 
> Fixes: 59c66c5f8c4f ("mm: factor out page cache page freeing into a separate function")
> Cc: stable at vger.kernel.org
> Signed-off-by: Josef Bacik <josef at toxicpanda.com>
> [ david: get rid of filemap_free_folio() entirely; improve patch description ]
> Signed-off-by: David Hildenbrand (Arm) <david at kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261027-fixes_core-v1-0-6f74bec9a5bb@kernel.org?part=6