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

[Chi Zhiling]

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;
> >   }