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

[Chi Zhiling <chizhiling@163.com>]

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.

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.

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.

Thanks,

> 
>>          iomap->bdev = inode->i_sb->s_bdev;
>>          iomap->offset = offset;
>>
>> @@ -135,7 +135,7 @@ static int __exfat_iomap_begin(struct inode *inode, loff_t offset, loff_t length
>>
>>          iomap->flags |= IOMAP_F_MERGED;
>>   out:
>> -       up_write(&sbi->s_lock);
>> +       up_read(&sbi->s_lock);
>>          return err;
>>   }