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 2/2] hfs: don't take inode_lock in hfs_file_fsync()
Date: Thu, 12 Nov 2026 16:37:56 -0800 [thread overview]
Message-ID: <20261113003756.1066989-3-slava@dubeyko.com> (raw)
In-Reply-To: <20261113003756.1066989-1-slava@dubeyko.com>
hfs_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:
- write_inode_now() ends up in hfs_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), and the extent and catalog records
are updated under the extents and catalog b-tree locks taken by
hfs_find_init().
- flush_delayed_work() of mdb_work runs flush_mdb(), which commits the
MDB, the alternate MDB and the volume bitmap under sbi->mdb_lock.
This state is per-superblock, so inode_lock of one file never
protected it anyway.
- sync_blockdev() works on the block device and needs no inode lock.
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, while
holding off writers of that file for the whole duration of the MDB
commit and the block device flush. Drop inode_lock()/inode_unlock()
from hfs_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/hfs/inode.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c
index ef1275bbbcbb..f1122ffae712 100644
--- a/fs/hfs/inode.c
+++ b/fs/hfs/inode.c
@@ -773,7 +773,6 @@ static int hfs_file_fsync(struct file *filp, loff_t start, loff_t end,
ret = file_write_and_wait_range(filp, start, end);
if (ret)
return ret;
- inode_lock(inode);
/* sync the inode to buffers */
ret = write_inode_now(inode, 0);
@@ -785,7 +784,6 @@ static int hfs_file_fsync(struct file *filp, loff_t start, loff_t end,
err = sync_blockdev(sb->s_bdev);
if (!ret)
ret = err;
- inode_unlock(inode);
return ret;
}
--
2.53.0
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 ` [PATCH 1/2] hfsplus: don't take inode_lock in hfsplus_file_fsync() Viacheslav Dubeyko
2026-11-13 0:37 ` Viacheslav Dubeyko [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=20261113003756.1066989-3-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®