Re: [RFC PATCH v1 6/6] exfat: take s_lock in read mode for iomap mapping paths

[Namjae Jeon]

On Thu, Aug 27, 2026 at 11:22 AM Chi Zhiling <chizhiling@xxxxxxx> wrote:
>
> On 8/27/26 9:08 AM, Namjae Jeon wrote:
> >> @@ -68,7 +68,7 @@ static int __exfat_iomap_begin(struct inode *inode, loff_t offset, loff_t length
> >>          num_clusters = exfat_bytes_to_cluster_round_up(sbi,
> >>                          offset + length) - exfat_bytes_to_cluster(sbi, offset);
> >>
> >> -       down_write(&sbi->s_lock);
> >> +       down_read(&sbi->s_lock);
> > If may_alloc is true, Should we use down_write() ?
>
> IMO, there is no need for down_write(); the block mapping of an inode is
> protected by the inode lock, not s_lock. see exfat_fallocate(), where we
> don't hold s_lock.
Okay.
>
> If may_alloc is true, we need to allocate clusters and append them to
> the file's FAT chain. The allocation is protected by bitmap_lock, while
> the FAT chain is protected by the inode lock, since we hold the inode
> write lock in exfat_file_write_iter(), exfat_fallocate() and
> exfat_truncate(), there is no race when modifying the FAT chain.
Okay.
>
> Besides, I'm trying to remove s_lock in the next version and am
> considering adding a per-inode lock to exfat_inode_info, since the inode
> lock has a relatively large scope.
Okay, Sounds great!
Thanks!