kernel/linux.git/drivers/md/dm.c, branch v7.2-rc2

dm: limit target bio polling to one shot

2026-05-18T12:27:11+00:00

dm_poll_bio() is the ->poll_bio() callback for a stacked dm device. The caller only knows about the dm queue, so it may decide to do a spinning poll if it thinks a single queue is being polled. Passing those flags unchanged to the mapped clone lets blk_mq_poll() spin on a target queue from inside dm_poll_bio(). With io_uring IOPOLL on a dm-stripe target this can keep a task in dm_poll_bio() -> bio_poll() -> blk_mq_poll() long enough to trigger an RCU CPU stall, before io_uring gets back to io_iopoll_check() and its need_resched() check. Keep dm's ->poll_bio() bounded by forcing one-shot polling for target bios. The caller can invoke dm_poll_bio() again if it wants to keep polling, and it also gets a chance to reap completions or reschedule between passes. Fixes: f22ecf9c14c1 ("blk-mq: delete task running check in blk_hctx_poll()") Signed-off-by: Fengnan Chang Signed-off-by: Mikulas Patocka

dm-ima: Fix UAF errors and measuring incorrect context

2026-05-04T12:53:09+00:00

the dm-ima code did not keep the dm_ima_measure_on_* functions from running at the same time. This could lead to various errors. If two processes were updating the device state, one could update the state first, but the other could measure the state first, causing the the current device state to appear incorrect. If a table load happened while a device was resuming, the IMA measurement could report the wrong table being active. And if two dm_ima_measure_on_* functions ran at the same time, one of them could free data that the other was accessing, causing a crash. All the core dm functions that call a dm_ima_measure_on_* function update the device state they want to measure under the _hash_lock, except for do_resume(). But holding the _hash_lock is not a good way to synchronize these functions. It's a global mutex, that is needed in many dm operations, and the dm_ima_measure_* functions can sleep, blocking any dm operation on any device that needs the _hash_lock. To serialize and order the IMA measurement functions, the dm_ima_measurements now has two counters, update_idx and measure_idx. update_idx is incremented while holding the _hash_lock and saved, along with the device name and uuid, in a dm_ima_context struct. Once the _hash_lock is dropped, the dm_ima_measure_* function is called. It waits until measure_idx matches the saved value of update_idx, ensuring that the updates and measurements happen in the same order if there are multiple processes changing the device at the same time. Then it measures the device, updates measure_idx, and wakes up any other process waiting to do a measurement. This makes sure that the measurements are serialized and done in the order that the _hash_lock was acquired in. But they only block other measurements for the same device, which are unlikely to happen at the same time. do_resume() is trickier, because it removes the inactive table while holding the _hash_lock, but doesn't hold it while updating md->map. To make sure it is also ordered, the IMA code grabs the _hash_lock after md->map is updated. Then it makes sure that the device isn't being removed and that another do_resume() hasn't already changed the active table again, and serializes like the other functions do. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka

dm-ima: remove dm_ima_reset_data()

2026-05-04T12:52:18+00:00

There's no point in saving the string length of DM_IMA_VERSION_STR. It's a constant, so the compiler will precompute it. dm_create() will already zero out the rest of dm->ima. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka

dm: use bio_clone_blkg_association

2026-01-26T14:36:22+00:00

The origin bio carries blk-cgroup information which could be set from foreground(task_css(css) - wbc->wb->blkcg_css), so the blkcg won't control buffer io since commit ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone"). The synchronous io is still under control by blkcg, because 'bio->bi_blkg' is set by io submitting task which has been added into 'cgroup.procs'. Fix it by using bio_clone_blkg_association when submitting a cloned bio. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220985 Fixes: ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone") Reported-by: Zhihao Cheng Signed-off-by: Mikulas Patocka Tested-by: Zhihao Cheng

dm: add WQ_PERCPU to alloc_workqueue users

2026-01-14T12:16:00+00:00

This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The refactoring is going to alter the default behavior of alloc_workqueue() to be unbound by default. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. For more details see the Link tag below. In order to keep alloc_workqueue() behavior identical, explicitly request WQ_PERCPU. Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Signed-off-by: Mikulas Patocka

Merge tag 'for-6.19/dm-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm

2025-12-11T03:13:29+00:00

Pull device mapper updates from Mikulas Patocka: - convert crypto_shash users to direct crypto library use with simpler and faster code and reduced stack usage (Eric Biggers): - the dm-verity SHA-256 conversion also teaches it to do two-way interleaved hashing for added performance - dm-crypt MD5 conversion (used for Loop-AES compatibility) - added document for for takeover/reshape raid1 -> raid5 examples (Heinz Mauelshagen) - fix dm-vdo kerneldoc warnings (Matthew Sakai) - various random fixes and cleanups * tag 'for-6.19/dm-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: (29 commits) dm pcache: fix segment info indexing dm pcache: fix cache info indexing dm-pcache: advance slot index before writing slot dm raid: add documentation for takeover/reshape raid1 -> raid5 table line examples dm log-writes: Add missing set_freezable() for freezable kthread dm-raid: fix possible NULL dereference with undefined raid type dm-snapshot: fix 'scheduling while atomic' on real-time kernels dm: ignore discard return value MAINTAINERS: add Benjamin Marzinski as a device mapper maintainer dm-mpath: Simplify the setup_scsi_dh code dm vdo: fix kerneldoc warnings dm-bufio: align write boundary on physical block size dm-crypt: enable DM_TARGET_ATOMIC_WRITES dm: test for REQ_ATOMIC in dm_accept_partial_bio() dm-verity: remove useless mempool dm-verity: disable recursive forward error correction dm-ebs: Mark full buffer dirty even on partial write dm mpath: enable DM_TARGET_ATOMIC_WRITES dm verity fec: Expose corrected block count via status dm: Don't warn if IMA_DISABLE_HTABLE is not enabled ...

dm: test for REQ_ATOMIC in dm_accept_partial_bio()

2025-12-10T18:28:12+00:00

Any bio with REQ_ATOMIC flag set should never be split or partially completed, so BUG_ON() on this scenario in dm_accept_partial_bio() (whose intent is to allow partial completions). Also, we must reject atomic bio to targets that don't support them, otherwise this BUG could be triggered by stray bios that have the REQ_ATOMIC set. Signed-off-by: John Garry Signed-off-by: Mikulas Patocka Tested-by: John Garry

dm: fix failure when empty flush's bi_sector points beyond the device end

2025-11-20T18:50:42+00:00

An empty flush bio can have arbitrary bi_sector. The commit 2b1c6d7a890a introduced a regression that device mapper would fail an empty flush bio with -EIO if the sector pointed beyond the end of the device. The commit introduced an optimization, that optimization would pass flushes to __split_and_process_bio and __split_and_process_bio is not prepared to handle empty bios. Fix this bug by passing only non-empty flushes to __split_and_process_bio - non-empty flushes must have valid bi_sector. Empty bios will go through __send_empty_flush, as they did before the optimization. This problem can be reproduced by running the lvm2 test: make check_local T=lvconvert-thin.sh LVM_TEST_PREFER_BRD=0 Signed-off-by: Mikulas Patocka Fixes: 2b1c6d7a890a ("dm: optimize REQ_PREFLUSH with data when using the linear target") Reported-by: Zdenek Kabelac Reviewed-by: Bart Van Assche

dm: Don't warn if IMA_DISABLE_HTABLE is not enabled

2025-11-18T17:24:25+00:00

Commit f1cd6cb24b6b ("dm ima: add a warning in dm_init if duplicate ima events are not measured") added a warning message if CONFIG_IMA is enabled but CONFIG_IMA_DISABLE_HTABLE is not to inform users. When enabling CONFIG_IMA, CONFIG_IMA_DISABLE_HTABLE is disabled by default and so warning is seen. Therefore, it seems more appropriate to make this an INFO level message than warning. If this truly is a warning, then maybe CONFIG_IMA_DISABLE_HTABLE should default to y if CONFIG_IMA is enabled. Signed-off-by: Jon Hunter Signed-off-by: Mikulas Patocka

dm: Fix deadlock when reloading a multipath table

2025-10-20T13:26:57+00:00

Request-based devices (dm-multipath) queue I/O in blk-mq on noflush suspends. Any queued IO will make it impossible to freeze the queue. If a process attempts to update the queue limits while there is queued IO, it can be get stuck holding the limits lock, while unable to freeze the queue. If device-mapper then attempts to update the limits during a table swap, it will deadlock trying to grab the limits lock while making it impossible to flush the IO. Disallow updating the queue limits during a table swap, when updating an immutable request-based dm device (dm-multipath) during a noflush suspend. It is userspace's responsibility to make sure that the new table uses the same limits as the existing table if it asks for a noflush suspend. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka