mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®