From: fdmanana@kernel.org
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/3] btrfs: fixes for races when checking if an inode was logged before
Date: Wed, 6 Aug 2025 12:11:29 +0100 [thread overview]
Message-ID: <cover.1754432805.git.fdmanana@suse.com> (raw)
From: Filipe Manana <fdmanana@suse.com>
The first patch is actually a new version of a patch sent out before [1],
because holding the inode's log_mutex at inode_logged() can make lockdep
unhappy in situations like when logging conflicting inodes, where we are
already holding the log_mutex of some other inode and could potentially
result in a ABBA deadlock.
The second patch splits part of what the initial version of patch 1 fixed,
but with a different solution that makes the management of an inode's
last_dir_index_offset field simpler.
Patch 3 is completely new.
Details in the change logs.
[1] - https://lore.kernel.org/linux-btrfs/7585d15c0e9c163d5cdf32307014a4e792e62541.1753807163.git.fdmanana@suse.com/
Filipe Manana (3):
btrfs: fix race between logging inode and checking if it was logged before
btrfs: fix race between setting last_dir_index_offset and inode logging
btrfs: avoid load/store tearing races when checking if an inode was logged
fs/btrfs/btrfs_inode.h | 2 +-
fs/btrfs/inode.c | 1 +
fs/btrfs/tree-log.c | 78 ++++++++++++++++++++++++++++--------------
3 files changed, 55 insertions(+), 26 deletions(-)
--
2.47.2
next reply other threads:[~2025-08-06 11:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-06 11:11 fdmanana [this message]
2025-08-06 11:11 ` [PATCH 1/3] btrfs: fix race between logging inode and checking if it was logged before fdmanana
2025-08-06 11:11 ` [PATCH 2/3] btrfs: fix race between setting last_dir_index_offset and inode logging fdmanana
2025-08-06 11:11 ` [PATCH 3/3] btrfs: avoid load/store tearing races when checking if an inode was logged fdmanana
2025-08-08 21:07 ` [PATCH 0/3] btrfs: fixes for races when checking if an inode was logged before Boris Burkov
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=cover.1754432805.git.fdmanana@suse.com \
--to=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/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.