From: Viacheslav Dubeyko <slava@dubeyko.com>
To: glaubitz@physik.fu-berlin.de, frank.li@vivo.com
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
vdubeyko@coreweave.com, Viacheslav Dubeyko <slava@dubeyko.com>
Subject: [PATCH 1/2] hfsplus: don't take inode_lock in hfsplus_file_fsync()
Date: Thu, 12 Nov 2026 16:37:55 -0800 [thread overview]
Message-ID: <20261113003756.1066989-2-slava@dubeyko.com> (raw)
In-Reply-To: <20261113003756.1066989-1-slava@dubeyko.com>
hfsplus_file_fsync() takes inode_lock() around the metadata part of
fsync. For HFS+ it is not needed, because everything done under the lock is
already serialized by other means:
- sync_inode_metadata() ends up in hfsplus_write_inode(), which is
also called by the flusher threads and by sync without holding
inode_lock. Concurrent writeback of the same inode is serialized by
the writeback code itself (I_SYNC), the extent record is written
under hip->extents_lock, and the catalog record is updated under
the catalog b-tree lock taken by hfs_find_init().
- The catalog, extents, attributes and allocation file flushes are
per-superblock, not per-inode. They are guarded by the atomic
HFSPLUS_I_*_DIRTY bits and the page cache of the b-tree inodes, so
fsync() calls on different inodes already run this code in parallel,
as does hfsplus_sync_fs(), which does the same flushes without
inode_lock.
- The volume header is prepared and committed under sbi->vh_mutex
(and sbi->alloc_mutex in hfsplus_commit_superblock()).
So inode_lock only serializes fsync() of an inode against write(),
truncate and setattr on the same inode, and against another fsync()
of it, without protecting any state that is not already protected.
Taking it there also means that fsync() of a large file holds off
writers of that file for the whole duration of the b-tree flushes and
the device cache flush. Other file systems (for example, ext4) don't
take inode_lock in ->fsync() either. Drop inode_lock()/inode_unlock()
from hfsplus_file_fsync().
Fixes: 02c24a82187d ("fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers")
cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
cc: Yangtao Li <frank.li@vivo.com>
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
---
fs/hfsplus/inode.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c
index 5fa72b465922..8073fb99217d 100644
--- a/fs/hfsplus/inode.c
+++ b/fs/hfsplus/inode.c
@@ -370,7 +370,6 @@ int hfsplus_file_fsync(struct file *file, loff_t start, loff_t end,
error = file_write_and_wait_range(file, start, end);
if (error)
return error;
- inode_lock(inode);
/*
* Sync inode metadata into the catalog and extent trees.
@@ -429,8 +428,6 @@ int hfsplus_file_fsync(struct file *file, loff_t start, loff_t end,
if (!test_bit(HFSPLUS_SB_NOBARRIER, &sbi->flags))
blkdev_issue_flush(inode->i_sb->s_bdev);
- inode_unlock(inode);
-
return error;
}
--
2.53.0
next prev parent reply other threads:[~2026-11-13 0:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 0:37 [PATCH 0/2] hfs/hfsplus: don't take inode_lock in ->fsync() Viacheslav Dubeyko
2026-11-13 0:37 ` Viacheslav Dubeyko [this message]
2026-11-13 0:37 ` [PATCH 2/2] hfs: don't take inode_lock in hfs_file_fsync() Viacheslav Dubeyko
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=20261113003756.1066989-2-slava@dubeyko.com \
--to=slava@dubeyko.com \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vdubeyko@coreweave.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
all inboxes | Powered by JetHome®