Re: [BUG] ntfs: data race on ni->mrec between resident read path and MFT record mutation

[Hyeontae Lee]

Hi Hyunchul,

Thanks. In case it saves you some time: I tried the naive fix - taking
mrec_lock unconditionally in __ntfs_read_iomap_begin() - and it deadlocks
immediately. ntfs_lookup() already holds the directory inode's mrec_lock
when it reads an index folio via read_mapping_folio(), so the read iomap
path re-enters and lockdep reports recursive locking:

  WARNING: possible recursive locking detected
  --------------------------------------------
  bash/1 is trying to acquire lock:
   (&ni->mrec_lock), at: __ntfs_read_iomap_begin+0x291/0x3f0
  but task is already holding lock:
   (&ni->mrec_lock), at: ntfs_lookup+0x7f/0x3e0

  Call Trace:
   __mutex_lock+0xd3/0x1190
   __ntfs_read_iomap_begin+0x291/0x3f0
   iomap_iter+0x1a4/0x480
   iomap_read_folio+0xb1/0x1c0
   ntfs_read_folio+0x82/0xd0
   filemap_read_folio+0x18/0x80
   do_read_cache_folio+0x7a/0x1b0
   ntfs_lookup_inode_by_name+0x624/0xe00
   ntfs_lookup+0x93/0x3e0
   path_openat+0xb4f/0x1370

So the read path is entered both with and without mrec_lock held (this one
has no attribute list involved), which lines up with your point on the June
thread that an unconditional lock there does not work. The comment at
fs/ntfs/dir.c:295 notes the same read_mapping_folio() hazard.

I will think about a different approach.

Thanks,
Hyeontae