From: Benjamin Marzinski <bmarzins@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>,
Mike Snitzer <snitzer@redhat.com>, Jens Axboe <axboe@kernel.dk>
Cc: dm-devel@lists.linux.dev, linux-block@vger.kernel.org,
Damien Le Moal <dlemoal@kernel.org>,
Christoph Hellwig <hch@lst.de>
Subject: [RFC PATCH 0/7] dm: fix issues with swapping dm tables
Date: Sun, 9 Mar 2025 18:28:56 -0400 [thread overview]
Message-ID: <20250309222904.449803-1-bmarzins@redhat.com> (raw)
There were multiple places in dm's __bind() function where it could fail
and not completely roll back, leaving the device using the the old
table, but with device limits and resources from the new table.
Additionally, unused mempools for request-based devices were not always
freed immediately.
Finally, there were a number of issues with switching zoned tables that
emulate zone append (in other words, dm-crypt on top of zoned devices).
dm_blk_report_zones() could be called while the device was suspended and
modifying zoned resources or could possibly fail to end a srcu read
section. More importantly, blk_revalidate_disk_zones() would never get
called when updating a zoned table. This could cause the dm device to
see the wrong zone write offsets, not have a large enough zwplugs
reserved in its mempool, or read invalid memory when checking the
conventional zones bitmap.
This patchset fixes these issues. It does not make it so that
device-mapper is able to load any zoned table from any other zoned
table. Zoned dm-crypt devices can be safely grown and shrunk, but
reloading a zoned dm-crypt device to, for instance, point at a
completely different underlying device won't work correctly. IO might
fail since the zone write offsets of the dm-crypt device will not be
updated for all the existing zones with plugs. If the new device's zone
offsets don't match the old device's offsets, IO to the zone will fail.
If the ability to switch tables from a zoned dm-crypt device to an
abritry other zoned dm-crypt device is important to people, it could be
done as long as there are no plugged zones when dm suspends.
This patchset also doesn't touch the code for switching from a zoned to
a non-zoned device. Switching from a zoned dm-crypt device to a
non-zoned device is problematic if there are plugged zones, since the
underlying device will not be prepared to handle these plugged writes.
Switching to a target that does not pass down IOs, like the dm-error
target, is fine. So is switching when there are no plugged zones, except
that we do not free the zoned resources in this case, even though we
safely could.
If people are interested in removing some of these limitations, I can
send patches for them, but I'm not sure how much extra code we want,
just to support niche zoned dm-crypt reloads.
Benjamin Marzinski (7):
dm: don't change md if dm_table_set_restrictions() fails
dm: free table mempools if not used in __bind
dm: handle failures in dm_table_set_restrictions
dm: fix dm_blk_report_zones
blk-zoned: clean up zone settings for devices without zwplugs
blk-zoned: modify blk_revalidate_disk_zones for bio-based drivers
dm: allow devices to revalidate existing zones
block/blk-zoned.c | 78 ++++++++++++++++++++++--------------------
block/blk.h | 4 ---
drivers/md/dm-core.h | 1 +
drivers/md/dm-table.c | 24 ++++++++-----
drivers/md/dm-zone.c | 75 ++++++++++++++++++++++++++--------------
drivers/md/dm.c | 30 ++++++++--------
drivers/md/dm.h | 1 +
include/linux/blkdev.h | 4 +++
8 files changed, 128 insertions(+), 89 deletions(-)
--
2.48.1
next reply other threads:[~2025-03-09 22:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-09 22:28 Benjamin Marzinski [this message]
2025-03-09 22:28 ` [PATCH 1/7] dm: don't change md if dm_table_set_restrictions() fails Benjamin Marzinski
2025-03-09 23:18 ` Damien Le Moal
2025-03-10 16:39 ` Benjamin Marzinski
2025-03-09 22:28 ` [PATCH 2/7] dm: free table mempools if not used in __bind Benjamin Marzinski
2025-03-09 23:19 ` Damien Le Moal
2025-03-09 22:28 ` [PATCH 3/7] dm: handle failures in dm_table_set_restrictions Benjamin Marzinski
2025-03-09 23:25 ` Damien Le Moal
2025-03-10 17:37 ` Benjamin Marzinski
2025-03-10 18:15 ` Benjamin Marzinski
2025-03-10 23:27 ` Damien Le Moal
2025-03-14 13:38 ` Mikulas Patocka
2025-03-14 13:46 ` Mikulas Patocka
2025-03-10 23:16 ` Damien Le Moal
2025-03-09 22:29 ` [PATCH 4/7] dm: fix dm_blk_report_zones Benjamin Marzinski
2025-03-09 23:27 ` Damien Le Moal
2025-03-09 22:29 ` [PATCH 5/7] blk-zoned: clean up zone settings for devices without zwplugs Benjamin Marzinski
2025-03-09 23:31 ` Damien Le Moal
2025-03-09 22:29 ` [RFC PATCH 6/7] blk-zoned: modify blk_revalidate_disk_zones for bio-based drivers Benjamin Marzinski
2025-03-09 22:29 ` [RFC PATCH 7/7] dm: allow devices to revalidate existing zones Benjamin Marzinski
2025-03-09 23:59 ` Damien Le Moal
2025-03-10 17:43 ` Benjamin Marzinski
2025-03-10 23:19 ` Damien Le Moal
2025-03-10 23:42 ` Benjamin Marzinski
2025-03-11 0:00 ` Damien Le Moal
2025-03-09 23:16 ` [RFC PATCH 0/7] dm: fix issues with swapping dm tables Damien Le Moal
2025-03-10 16:38 ` Benjamin Marzinski
2025-03-10 23:13 ` Damien Le Moal
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=20250309222904.449803-1-bmarzins@redhat.com \
--to=bmarzins@redhat.com \
--cc=axboe@kernel.dk \
--cc=dlemoal@kernel.org \
--cc=dm-devel@lists.linux.dev \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=snitzer@redhat.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