From: Boris Burkov <boris@bur.io>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH v5 0/5] btrfs: fix corruption caused by partial dio writes
Date: Wed, 22 Mar 2023 12:11:47 -0700 [thread overview]
Message-ID: <cover.1679512207.git.boris@bur.io> (raw)
The final patch in this series ensures that bios submitted by btrfs dio
match the corresponding ordered_extent and extent_map exactly. As a
result, there is no hole or deadlock as a result of partial writes, even
if the write buffer is a partly overlapping mapping of the range being
written to.
This required a bit of refactoring and setup. Specifically, the zoned
device code for "extracting" an ordered extent matching a bio could be
reused with some refactoring to return the new ordered extents after the
split.
Patch 1: Generic patch for returning an ordered extent while creating it
Patch 2: Cache the dio ordered extent so that we can efficiently detect
partial writes during bio submission, without an extra lookup.
Patch 3: Use Patch 1 to track the new ordered_extent(s) that result from
splitting an ordered_extent.
Patch 4: Fix a bug in ordered extent splitting
Patch 5: Use the new more general split logic of Patch 4 and the stashed
ordered extent from Patch 2 to split partial dio bios to fix
the corruption while avoiding the deadlock.
---
Changelog:
v5:
- skip splitting em on nocow writes, this removes the need to refactor
split_em, so remove that patch, and just rename split_zoned_em to
split_em.
v4:
- significant changes; redesign the fix to use bio splitting instead of
extending the ordered_extent lifetime across calls into iomap.
- all the oe/em splitting refactoring and fixes
v3:
- handle BTRFS_IOERR set on the ordered_extent in btrfs_dio_iomap_end.
If the bio fails before we loop in the submission loop and exit from
the loop early, we never submit a second bio covering the rest of the
extent range, resulting in leaking the ordered_extent, which hangs umount.
We can distinguish this from a short write in btrfs_dio_iomap_end by
checking the ordered_extent.
v2:
- rename new ordered extent function
- pull the new function into a prep patch
- reorganize how the ordered_extent is stored/passed around to avoid so
many annoying memsets and exposing it to fs/btrfs/file.c
- lots of small code style improvements
- remove unintentional whitespace changes
- commit message improvements
- various ASSERTs for clarity/debugging
Boris Burkov (5):
btrfs: add function to create and return an ordered extent
btrfs: stash ordered extent in dio_data during iomap dio
btrfs: return ordered_extent splits from bio extraction
btrfs: fix crash with non-zero pre in btrfs_split_ordered_extent
btrfs: split partial dio bios before submit
fs/btrfs/bio.c | 2 +-
fs/btrfs/btrfs_inode.h | 5 ++-
fs/btrfs/inode.c | 94 +++++++++++++++++++++++++++++++----------
fs/btrfs/ordered-data.c | 88 ++++++++++++++++++++++++++++----------
fs/btrfs/ordered-data.h | 13 ++++--
5 files changed, 152 insertions(+), 50 deletions(-)
--
2.38.1
next reply other threads:[~2023-03-22 19:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-22 19:11 Boris Burkov [this message]
2023-03-22 19:11 ` [PATCH v5 1/5] btrfs: add function to create and return an ordered extent Boris Burkov
2023-03-22 19:11 ` [PATCH v5 2/5] btrfs: stash ordered extent in dio_data during iomap dio Boris Burkov
2023-03-22 19:11 ` [PATCH v5 3/5] btrfs: return ordered_extent splits from bio extraction Boris Burkov
2023-03-23 8:47 ` Christoph Hellwig
2023-03-23 16:15 ` Boris Burkov
2023-03-23 17:00 ` Boris Burkov
2023-03-23 17:45 ` Boris Burkov
2023-03-23 21:29 ` Christoph Hellwig
2023-03-23 22:43 ` Boris Burkov
2023-03-24 0:24 ` Christoph Hellwig
2023-03-22 19:11 ` [PATCH v5 4/5] btrfs: fix crash with non-zero pre in btrfs_split_ordered_extent Boris Burkov
2023-03-23 8:36 ` Naohiro Aota
2023-03-23 16:22 ` Boris Burkov
2023-03-22 19:11 ` [PATCH v5 5/5] btrfs: split partial dio bios before submit 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.1679512207.git.boris@bur.io \
--to=boris@bur.io \
--cc=kernel-team@fb.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox