kernel/drivers/md/dm-unstripe.c, branch linux-5.10.y

dm-unstripe: fix mapping bug when there are multiple targets in a table

2026-03-04T12:20:17Z

[ Upstream commit 83c10e8dd43628d0bf86486616556cd749a3c310 ] The "unstriped" device-mapper target incorrectly calculates the sector offset on the mapped device when the target's origin is not zero. Take for example this hypothetical concatenation of the members of a two-disk RAID0: linearized: 0 2097152 unstriped 2 128 0 /dev/md/raid0 0 linearized: 2097152 2097152 unstriped 2 128 1 /dev/md/raid0 0 The intent in this example is to create a single device named /dev/mapper/linearized that comprises all of the chunks of the first disk of the RAID0 set, followed by all of the chunks of the second disk of the RAID0 set. This fails because dm-unstripe.c's map_to_core function does its computations based on the sector number within the mapper device rather than the sector number within the target. The bug turns invisible when the target's origin is at sector zero of the mapper device, as is the common case. In the example above, however, what happens is that the first half of the mapper device gets mapped correctly to the first disk of the RAID0, but the second half of the mapper device gets mapped past the end of the RAID0 device, and accesses to any of those sectors return errors. Signed-off-by: Matt Whitlock Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Fixes: 18a5bf270532 ("dm: add unstriped target") Signed-off-by: Sasha Levin

dm-unstriped: cast an operand to sector_t to prevent potential uint32_t overflow

2024-11-17T13:59:37Z

commit 5a4510c762fc04c74cff264cd4d9e9f5bf364bae upstream. This was found by a static analyzer. There may be a potential integer overflow issue in unstripe_ctr(). uc->unstripe_offset and uc->unstripe_width are defined as "sector_t"(uint64_t), while uc->unstripe, uc->chunk_size and uc->stripes are all defined as "uint32_t". The result of the calculation will be limited to "uint32_t" without correct casting. So, we recommend adding an extra cast to prevent potential integer overflow. Fixes: 18a5bf270532 ("dm: add unstriped target") Signed-off-by: Zichen Xie Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

dm: Check for device sector overflow if CONFIG_LBDAF is not set

2018-12-18T14:02:26Z

Reference to a device in device-mapper table contains offset in sectors. If the sector_t is 32bit integer (CONFIG_LBDAF is not set), then several device-mapper targets can overflow this offset and validity check is then performed on a wrong offset and a wrong table is activated. See for example (on 32bit without CONFIG_LBDAF) this overflow: # dmsetup create test --table "0 2048 linear /dev/sdg 4294967297" # dmsetup table test 0 2048 linear 8:96 1 This patch adds explicit check for overflow if the offset is sector_t type. Signed-off-by: Milan Broz Reviewed-by: Mikulas Patocka Signed-off-by: Mike Snitzer

dm unstripe: remove unnecessary header includes

2018-04-03T19:04:15Z

Signed-off-by: Heinz Mauelshagen Signed-off-by: Mike Snitzer

dm unstripe: remove superfluous module init error path message

2018-04-03T19:04:14Z

Signed-off-by: Heinz Mauelshagen Reviewed-by: Scott Bauer Signed-off-by: Mike Snitzer

dm unstripe: add "dm-unstriped" module alias

2018-04-03T19:04:13Z

This target's kernel module being named dm-unstripe.ko doesn't allow lvm2's DM module autoload capability to load the dm-unstripe.ko because lvm2 looks for dm-unstriped.ko due to the target name being "unstriped". Add the "dm-unstriped" module alias to resolve this oversight. NOTE: this isn't needed for the "striped" target, despite its source file being named dm-stripe.c, because it is part of dm-mod.ko. Signed-off-by: Heinz Mauelshagen Signed-off-by: Mike Snitzer

dm unstripe: support non-power-of-2 chunk size

2018-04-03T19:04:12Z

Address "FIXME: must support non power of 2 chunk_size, dm-stripe.c does". Bump target version to indicate change. Signed-off-by: Heinz Mauelshagen Tested-by: Scott Bauer Reviewed-by: Scott Bauer Signed-off-by: Mike Snitzer

dm unstripe: fix target length versus number of stripes size check

2018-01-29T18:44:58Z

Since the unstripe target takes a target length which is the size of *one* striped member we're trying to expose, not the total size of *all* the striped members, the check does not make sense and fails for some striped setups. For example, say we have a 4TB striped device: or 3907018496 sectors per underlying device: if (sector_div(width, uc->stripes)) : 3907018496 / 2(num stripes) == 1953509248 tmp_len = width; if (sector_div(tmp_len, uc->chunk_size)) : 1953509248 / 256(chunk size) == 7630895.5 (fails) Fix this by removing the first check which isn't valid for unstriping. Signed-off-by: Scott Bauer Signed-off-by: Mike Snitzer

dm: add unstriped target

2018-01-17T14:16:00Z

This device mapper "unstriped" target remaps and unstripes I/O so it is issued solely on a single drive in a HW RAID0 or dm-striped target. In a 4 drive HW RAID0 the striped target exposes 1/4th of the LBA range as a virtual drive. Each I/O to that virtual drive will only be issued to the 1 drive that was selected of the 4 drives in the HW RAID0. This unstriped target is most useful for Intel NVMe drives that have multiple cores but that do not have firmware control to pin separate LBA ranges to each discrete cpu core. Signed-off-by: Scott Bauer Signed-off-by: Heinz Mauelshagen Acked-by: Keith Busch Signed-off-by: Mike Snitzer