Re: [PATCH v2 2/2] ntfs: take invalidate_lock in ntfs_filemap_page_mkwrite()

[Namjae Jeon]

On Mon, Aug 31, 2026 at 5:33 PM Hongling Zeng <zenghongling@xxxxxxxxxx> wrote:
>
> ntfs_filemap_page_mkwrite() calls iomap_page_mkwrite() without holding
> mapping->invalidate_lock, so a concurrent truncate or fallocate can be
> in the middle of invalidating pagecache and rewriting the runlist while
> the write fault maps blocks and dirties the folio.  This races with
> ntfs_attr_fallocate(), which merges clusters into the in-memory
> runlist, drops the runlist lock, and only afterwards zeroes the newly
> allocated clusters on disk; and with the punch-hole/insert/collapse
> paths that free clusters after truncating the cache.
>
> Per Documentation/filesystems/locking.rst, ->page_mkwrite() must ensure
> there are no truncate/invalidate races, "usually mapping->invalidate_lock
> is suitable for proper serialization".  xfs takes its mmaplock (= the
> invalidate_lock rwsem) shared in exactly this path.
>
> Take invalidate_lock shared around iomap_page_mkwrite().  The read-only
> fault path is already covered because filemap_fault() itself grabs
> invalidate_lock shared on instantiation/read paths; only page_mkwrite
> was bypassing it in this driver.
>
> Fixes: 9c87959601e8 ("ntfs: update file operations")
> Cc: stable@xxxxxxxxxxxxxxx
> Reviewed-by: Hyunchul Lee <hyc.lee@xxxxxxxxx>
> Reviewed-by: Baolin Liu <liubaolin@xxxxxxxxxx>
> Co-developed-by: Namjae Jeon <linkinjeon@xxxxxxxxxx>
> Signed-off-by: Hongling Zeng <zenghongling@xxxxxxxxxx>
Applied it to #ntfs-next.
Thanks!