Re: [PATCH] mm: thp: unlock i_mmap before releasing split folios

[Kiryl Shutsemau <kirill@shutemov.name>]

On Fri, Jul 10, 2026 at 03:13:44PM +0800, Hao Zhang wrote:
> From: Hao Zhang <zhanghao1@kylinos.cn>
> Date: Thu, 9 Jul 2026 16:30:00 +0800
> 
> __folio_split() takes mapping->i_mmap_rwsem while unmapping and
> splitting a file-backed large folio. The lock is currently released
> only after the split folios that are not returned locked to the caller
> have been unlocked and put.
> 
> That leaves a lifetime hole. Once the split folios are unlocked and
> their references are dropped, inode eviction can make progress through
> the final page-cache truncation path. After the folios are removed from
> the page cache and the last inode reference is dropped, the inode that
> embeds the address_space can be freed after an RCU grace period. A later
> i_mmap_unlock_read(mapping) then dereferences mapping->i_mmap_rwsem
> from freed memory.
> 
> A possible race is:
> 
>   CPU0                                    CPU1
>   __folio_split()
>     i_mmap_lock_read(mapping)
>     ...
>     remap_page()
>     folio_unlock(new_folio)
>     free_folio_and_swap_cache(new_folio)
>                                           evict inode
>                                           truncate_inode_pages_final()
>                                           destroy_inode()
>                                           call_rcu()
>                                           RCU callback frees inode
>     i_mmap_unlock_read(mapping)
> 
> Release mapping->i_mmap_rwsem after the page-cache and reverse-mapping
> work has completed, but before unlocking and putting any of the split
> folios. Clear the local mapping pointer after the early unlock so the
> common exit path does not unlock it a second time.

I don't buy this analysis. We still have the lock_at page which is locked
and still in the page cache. Inode eviction cannot complete past
truncate_inode_pages_final() until it is unlocked, which only happens
after __folio_split() has released i_mmap_rwsem.

One possible path how this can be hit is if lock_at ends up in an
after-split folio beyond EOF and __folio_freeze_and_split_unmapped()
removes it from the page cache. Note the drop loop starts at
folio_next(folio), so this requires splitting at a tail page (e.g.
memory-failure) racing with truncate.

But that's not what your analysis claims. Please share the actual crash
reports. Let's get to the bottom of the situation before changing the
code.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov