From: Chi Zhiling <chizhiling@163.com>
To: exfat@lists.linux.dev, linux-kernel@vger.kernel.org
Cc: Namjae Jeon <linkinjeon@kernel.org>,
Sungjong Seo <sj1557.seo@samsung.com>,
Yuezhang Mo <yuezhang.mo@sony.com>,
Chi Zhiling <chizhiling@kylinos.cn>
Subject: [RFC PATCH v1 6/6] exfat: take s_lock in read mode for iomap mapping paths
Date: Fri, 21 Aug 2026 18:05:31 +0800 [thread overview]
Message-ID: <20260821100531.998196-7-chizhiling@163.com> (raw)
In-Reply-To: <20260821100531.998196-1-chizhiling@163.com>
From: Chi Zhiling <chizhiling@kylinos.cn>
The iomap mapping paths mainly access the FAT chain of the file itself.
Concurrent mappings of distinct inodes can therefore proceed in
parallel by taking s_lock in read mode instead of write mode. The
superblock-wide state shared between files is already protected by the
preceding patches: the allocation bitmap, used_clusters and clu_srch_ptr
by bitmap_lock, and the volume dirty flag / boot sector by atomic bit
ops with a single writer on the 0 -> 1 transition.
Concurrent access to the same inode stays serialized by the exclusive
inode_lock held in exfat_file_write_iter().
Writeback takes the read lock even though it does not hold inode_lock.
Folios under writeback are marked writeback, and truncate first flushes
and truncates the page cache, so truncate cannot run concurrently with
writeback. Writeback therefore only maps clusters that are still
committed or owned by the inode and cannot race with cluster freeing.
The lock ordering remains inode_lock -> s_lock -> bitmap_lock, so this
change does not introduce any new deadlock scenarios.
Signed-off-by: Chi Zhiling <chizhiling@kylinos.cn>
---
fs/exfat/iomap.c | 4 ++--
fs/exfat/super.c | 4 ++++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/exfat/iomap.c b/fs/exfat/iomap.c
index bc8bdfa9bb80..147e9da01a47 100644
--- a/fs/exfat/iomap.c
+++ b/fs/exfat/iomap.c
@@ -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);
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;
}
diff --git a/fs/exfat/super.c b/fs/exfat/super.c
index 72a35f4079b4..64ec4d2d1bf6 100644
--- a/fs/exfat/super.c
+++ b/fs/exfat/super.c
@@ -94,6 +94,8 @@ int exfat_set_volume_dirty(struct super_block *sb)
{
struct exfat_sb_info *sbi = EXFAT_SB(sb);
+ lockdep_assert_held(&sbi->s_lock);
+
if (test_and_set_bit(VOLUME_DIRTY_BIT, &sbi->vol_flags))
return 0;
@@ -104,6 +106,8 @@ int exfat_clear_volume_dirty(struct super_block *sb)
{
struct exfat_sb_info *sbi = EXFAT_SB(sb);
+ lockdep_assert_held_write(&sbi->s_lock);
+
if (!test_and_clear_bit(VOLUME_DIRTY_BIT, &sbi->vol_flags))
return 0;
--
2.53.0
prev parent reply other threads:[~2026-08-21 10:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 10:05 [RFC PATCH 0/6] exfat: take s_lock in read mode for iomap mapping paths Chi Zhiling
2026-08-21 10:05 ` [RFC PATCH v1 1/6] exfat: remove dead hint_bmap updates in I/O and truncate paths Chi Zhiling
2026-08-21 10:05 ` [RFC PATCH v1 2/6] exfat: take bitmap_lock at the start of exfat_alloc_cluster() Chi Zhiling
2026-08-21 10:05 ` [RFC PATCH v1 3/6] exfat: use atomic bit ops for volume dirty flag Chi Zhiling
2026-08-21 10:05 ` [RFC PATCH v1 4/6] exfat: lock FAT2 buffer while copying mirrored FAT entries Chi Zhiling
2026-08-21 10:05 ` [RFC PATCH v1 5/6] exfat: convert s_lock mutex to rw_semaphore using write lock Chi Zhiling
2026-08-21 10:05 ` Chi Zhiling [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260821100531.998196-7-chizhiling@163.com \
--to=chizhiling@163.com \
--cc=chizhiling@kylinos.cn \
--cc=exfat@lists.linux.dev \
--cc=linkinjeon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sj1557.seo@samsung.com \
--cc=yuezhang.mo@sony.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox