Linux EXT4 FS development
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: <linux-fsdevel@vger.kernel.org>
Cc: Christian Brauner <brauner@kernel.org>,
	aivazian.tigran@gmail.com, Ted Tso <tytso@mit.edu>,
	<linux-ext4@vger.kernel.org>,
	OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Jan Kara <jack@suse.cz>
Subject: [PATCH v3 0/19] fs: Fix missed inode write during fsync
Date: Thu,  2 Jul 2026 20:20:57 +0200	[thread overview]
Message-ID: <20260702175436.12226-1-jack@suse.cz> (raw)

Hello,

here is v3 of the patch series which fixes the possibly missing inode write
during fsync(2) for filesystems using generic metadata bh tracking. This is
a heavily reworked version since v2 mostly based on problems Sashiko found
which prompted me to redesign the whole approach.

The series now strives to make sure sync_inode_metadata() ->
writeback_single_inode() will end up to properly persisting not only the inode
but also all metadata associated with the inode. This is beneficial for several
reasons:

1) This removes the need for separate mmb_fsync() implementations. Filesystems
can just use simple_fsync().

2) This makes sure all metadata is written for IS_SYNC / IS_DIRSYNC inodes.
Currently most filesystems just write inode itself.

3) This fixes races when multiple fsyncs race for a while where mmb_sync()
could return before all buffers were really persisted (now I_SYNC state flag
properly serializes everything).

To be able to achieve this we add new .sync_inode_metadata superblock operation
which gets called from __writeback_single_inode() and new I_METADATA_WRITEBACK
state flag (putting everything into .write_inode is possible but it looked too
ugly so I've decided for the new operation).

This scheme with I_METADATA_WRITEBACK state flag also fixes the problem that
when WB_SYNC_NONE writeback happened between write(2) and fsync(2), fsync(2)
would fail to properly persist the inode. Note that this problem isn't specific
to filesystems using the generic metadata bh tracking. This patch set doesn't
fix such filesystems as it is already big enough but the universality of this
problem among simple filesystems is another reason why I've chosen the new
superblock operation instead of trying to somehow hack up metadata bh tracking
infrastructure.

Patches passed some basic testing with fstests, more tests are still running
but I guess the patch set is good enough for people to have a look.

Changes since v2:
* redesigned the patch set to use new superblock operation
* fixed race of inode freeing with IO error processing in
  mark_buffer_write_io_error() 

Changes since v1:
* Fixed freeing for ext4 dynamically allocated mmb struct
* Optimized tracking of block carrying the inode so that we don't flush it
  unnecessarily on fsync
* Add forgotten check for reclaimed bh to mmb_sync() to avoid NULL ptr deref
* Couple other smaller fixups pointed out by Sashiko

								Honza
Previous versions:
Link: http://lore.kernel.org/r/20260511115725.28441-1-jack@suse.cz # v1
Link: http://lore.kernel.org/r/20260525085035.12891-1-jack@suse.cz # v2

             reply	other threads:[~2026-07-02 18:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02 18:20 Jan Kara [this message]
2026-07-02 18:20 ` [PATCH v3 01/19] affs: Drop support for metadata bh tracking Jan Kara
2026-07-02 18:20 ` [PATCH v3 02/19] fs: Fix possible UAF in mark_buffer_write_io_error() Jan Kara
2026-07-02 18:21 ` [PATCH v3 03/19] fs: Fix missed inode writeback when racing with __writeback_single_inode Jan Kara
2026-07-02 18:21 ` [PATCH v3 04/19] ext4: Allocate mapping_metadata_bhs struct on demand Jan Kara
2026-07-03 10:00   ` Christian Brauner
2026-07-03 16:10     ` Jan Kara
2026-07-02 18:21 ` [PATCH v3 05/19] ext2: Drop __ext2_write_inode() Jan Kara
2026-07-02 18:21 ` [PATCH v3 06/19] ext2: Avoid unnecessary inode buffer writeback for sync(2) Jan Kara
2026-07-02 18:21 ` [PATCH v3 07/19] fs: Provide way for filesystem to wait for metadata writeback Jan Kara
2026-07-03 10:06   ` Christian Brauner
2026-07-03 16:12     ` Jan Kara
2026-07-02 18:21 ` [PATCH v3 08/19] ext2: Fix data integrity writeout issues Jan Kara
2026-07-02 18:21 ` [PATCH v3 09/19] udf: " Jan Kara
2026-07-02 18:21 ` [PATCH v3 10/19] udf: Use sync_inode_metadata() to writeout IS_SYNC inode Jan Kara
2026-07-02 18:21 ` [PATCH v3 11/19] udf: Write all metadata for IS_SYNC inodes Jan Kara
2026-07-02 18:21 ` [PATCH v3 12/19] udf: Fold udf_update_inode() into udf_write_inode() Jan Kara
2026-07-02 18:21 ` [PATCH v3 13/19] bfs: Fix data integrity writeout issues Jan Kara
2026-07-02 18:21 ` [PATCH v3 14/19] minix: " Jan Kara
2026-07-02 18:21 ` [PATCH v3 15/19] ext4: Fix data integrity writeout issues in nojournal mode Jan Kara
2026-07-02 18:21 ` [PATCH v3 16/19] fat: Fix missed inode writeback during fsync(2) Jan Kara
2026-07-02 18:21 ` [PATCH v3 17/19] fat: Remove some superfluous sync_dirty_buffer() calls Jan Kara
2026-07-02 18:21 ` [PATCH v3 18/19] fat: Replace fat_sync_inode() with sync_inode_metadata() Jan Kara
2026-07-02 18:21 ` [PATCH v3 19/19] vfs: Remove mmb_fsync() Jan Kara
2026-07-03 10:09 ` [PATCH v3 0/19] fs: Fix missed inode write during fsync Christian Brauner

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=20260702175436.12226-1-jack@suse.cz \
    --to=jack@suse.cz \
    --cc=aivazian.tigran@gmail.com \
    --cc=brauner@kernel.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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