All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Christian Brauner" <brauner@kernel.org>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH RFC v3 03/14] ext4: use sb_find_get_block_nonatomic() in ext4_get_inode_loc_noio()
Date: Mon, 09 Nov 2026 17:06:59 +0000	[thread overview]
Message-ID: <sashiko-outbox-205273@kernel.org> (raw)
In-Reply-To: <20261109-work-inode-metadata_writeback-v3-3-91ac6c024018@kernel.org>

> ext4_get_inode_loc_noio() looks the inode table block up with
> sb_find_get_block(). That's the atomic lookup. It serializes against
> try_to_free_buffers() with i_private_lock instead of the folio lock and
> gives up if the folio is being migrated. So it can report the block as
> not cached while it is.
> 
> For ext4_fc_snapshot_inode() that only means falling back to a full
> commit. But ext4_sync_inode_metadata() is going to use
> ext4_get_inode_loc_noio() to find the inode block that fsync() has to
> write out and there a dirty block must not be skipped.
> 
> ext4_fc_snapshot_inode() is the only caller and it can sleep. It runs
> under jbd2_journal_lock_updates() and allocates the snapshot with
> GFP_NOFS. So use sb_find_get_block_nonatomic() which takes the folio
> lock and waits for the migration instead.
> 
> Suggested-by: Jan Kara <jack@suse.cz>
> Cc: stable@vger.kernel.org # v7.3
> Reviewed-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109-work-inode-metadata_writeback-v3-0-91ac6c024018@kernel.org?part=3


  reply	other threads:[~2026-11-09 17:07 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09 16:51 [PATCH RFC v3 00/14] fs: reclaim inodes with I_METADATA_WRITEBACK Christian Brauner
2026-11-09 16:51 ` [PATCH RFC v3 01/14] ext2: add ext2_inode_block() helper Christian Brauner
2026-11-09 16:57   ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 02/14] ext2: don't read the inode block in ext2_sync_inode_metadata() Christian Brauner
2026-11-09 17:02   ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 03/14] ext4: use sb_find_get_block_nonatomic() in ext4_get_inode_loc_noio() Christian Brauner
2026-11-09 17:06   ` sashiko-bot [this message]
2026-11-09 16:51 ` [PATCH RFC v3 04/14] ext4: don't read the inode block in ext4_sync_inode_metadata() Christian Brauner
2026-11-09 17:11   ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 05/14] minix: add minix_inode_block() helper Christian Brauner
2026-11-09 17:13   ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 06/14] minix: don't read the inode block in minix_sync_inode_metadata() Christian Brauner
2026-11-09 17:16   ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 07/14] udf: don't allocate the inode block in udf_sync_inode_metadata() Christian Brauner
2026-11-09 17:24   ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 08/14] fs: set I_METADATA_WRITEBACK in mmb_mark_buffer_dirty() Christian Brauner
2026-11-09 17:50   ` sashiko-bot
2026-11-10 10:33   ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 09/14] fs: don't strand I_METADATA_WRITEBACK inodes outside the LRU Christian Brauner
2026-11-09 18:18   ` sashiko-bot
2026-11-10 10:28   ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 10/14] ext2: drop mmb_sync() from ext2_evict_inode() Christian Brauner
2026-11-09 18:36   ` sashiko-bot
2026-11-10 10:28   ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 11/14] ext4: drop mmb_sync() from ext4_evict_inode() Christian Brauner
2026-11-09 18:55   ` sashiko-bot
2026-11-10 10:28   ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 12/14] minix: drop mmb_sync() from minix_evict_inode() Christian Brauner
2026-11-09 18:58   ` sashiko-bot
2026-11-10 10:28   ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 13/14] udf: drop mmb_sync() from udf_evict_inode() Christian Brauner
2026-11-09 19:03   ` sashiko-bot
2026-11-10 10:29   ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 14/14] fat: drop mmb_sync() from fat_evict_inode() Christian Brauner
2026-11-09 19:08   ` sashiko-bot
2026-11-10 10:29   ` Jan Kara

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=sashiko-outbox-205273@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=brauner@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.