linux-stable.git/drivers/md, branch linux-6.16.y

dm-integrity: limit MAX_TAG_SIZE to 255

2025-10-12T11:01:01+00:00

[ Upstream commit 77b8e6fbf9848d651f5cb7508f18ad0971f3ffdb ]

MAX_TAG_SIZE was 0x1a8 and it may be truncated in the "bi->metadata_size
= ic->tag_size" assignment. We need to limit it to 255.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Sasha Levin

dm-stripe: fix a possible integer overflow

2025-09-25T09:16:46+00:00

commit 1071d560afb4c245c2076494226df47db5a35708 upstream.

There's a possible integer overflow in stripe_io_hints if we have too
large chunk size. Test if the overflow happened, and if it did, don't set
limits->io_min and limits->io_opt;

Signed-off-by: Mikulas Patocka 
Reviewed-by: John Garry 
Suggested-by: Dongsheng Yang 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

dm-raid: don't set io_min and io_opt for raid1

2025-09-25T09:16:46+00:00

commit a86556264696b797d94238d99d8284d0d34ed960 upstream.

These commands
 modprobe brd rd_size=1048576
 vgcreate vg /dev/ram*
 lvcreate -m4 -L10 -n lv vg
trigger the following warnings:
device-mapper: table: 252:10: adding target device (start sect 0 len 24576) caused an alignment inconsistency
device-mapper: table: 252:10: adding target device (start sect 0 len 24576) caused an alignment inconsistency

The warnings are caused by the fact that io_min is 512 and physical block
size is 4096.

If there's chunk-less raid, such as raid1, io_min shouldn't be set to zero
because it would be raised to 512 and it would trigger the warning.

Signed-off-by: Mikulas Patocka 
Reviewed-by: Martin K. Petersen 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

md: keep recovery_cp in mdp_superblock_s

2025-09-19T14:37:27+00:00

[ Upstream commit c27973211ffcdf0a092eec265d5993e64b89adaf ]

commit 907a99c314a5 ("md: rename recovery_cp to resync_offset") replaces
recovery_cp with resync_offset in mdp_superblock_s which is in md_p.h.
md_p.h is used in userspace too. So mdadm building fails because of this.
This patch revert this change.

Fixes: 907a99c314a5 ("md: rename recovery_cp to resync_offset")
Signed-off-by: Xiao Ni 
Link: https://lore.kernel.org/linux-raid/20250815040028.18085-1-xni@redhat.com
Signed-off-by: Yu Kuai 
Signed-off-by: Sasha Levin

md: prevent incorrect update of resync/recovery offset

2025-09-09T17:02:39+00:00

[ Upstream commit 7202082b7b7a256d04ec96131c7f859df0a79f64 ]

In md_do_sync(), when md_sync_action returns ACTION_FROZEN, subsequent
call to md_sync_position() will return MaxSector. This causes
'curr_resync' (and later 'recovery_offset') to be set to MaxSector too,
which incorrectly signals that recovery/resync has completed, even though
disk data has not actually been updated.

To fix this issue, skip updating any offset values when the sync action
is FROZEN. The same holds true for IDLE.

Fixes: 7d9f107a4e94 ("md: use new helpers in md_do_sync()")
Signed-off-by: Li Nan 
Link: https://lore.kernel.org/linux-raid/20250904073452.3408516-1-linan666@huaweicloud.com
Signed-off-by: Yu Kuai 
Signed-off-by: Sasha Levin

md/raid1: fix data lost for writemostly rdev

2025-09-09T17:02:39+00:00

[ Upstream commit 93dec51e716db88f32d770dc9ab268964fff320b ]

If writemostly is enabled, alloc_behind_master_bio() will allocate a new
bio for rdev, with bi_opf set to 0. Later, raid1_write_request() will
clone from this bio, hence bi_opf is still 0 for the cloned bio. Submit
this cloned bio will end up to be read, causing write data lost.

Fix this problem by inheriting bi_opf from original bio for
behind_mast_bio.

Fixes: e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags")
Reported-and-tested-by: Ian Dall 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220507
Link: https://lore.kernel.org/linux-raid/20250903014140.3690499-1-yukuai1@huaweicloud.com
Signed-off-by: Yu Kuai 
Reviewed-by: Li Nan 
Signed-off-by: Sasha Levin

md: fix sync_action incorrect display during resync

2025-08-28T14:34:46+00:00

[ Upstream commit b7ee30f0efd12f42735ae233071015389407966c ]

During raid resync, if a disk becomes faulty, the operation is
briefly interrupted. The MD_RECOVERY_RECOVER flag triggered by
the disk failure causes sync_action to incorrectly show "recover"
instead of "resync". The same issue affects reshape operations.

Reproduction steps:
  mdadm -Cv /dev/md1 -l1 -n4 -e1.2 /dev/sd{a..d} // -> resync happened
  mdadm -f /dev/md1 /dev/sda                     // -> resync interrupted
  cat sync_action
  -> recover

Add progress checks in md_sync_action() for resync/recover/reshape
to ensure the interface correctly reports the actual operation type.

Fixes: 4b10a3bc67c1 ("md: ensure resync is prioritized over recovery")
Signed-off-by: Zheng Qixing 
Link: https://lore.kernel.org/linux-raid/20250816002534.1754356-3-zhengqixing@huaweicloud.com
Signed-off-by: Yu Kuai 
Signed-off-by: Sasha Levin

md: add helper rdev_needs_recovery()

2025-08-28T14:34:46+00:00

[ Upstream commit cb0780ad4333040a98e10f014b593ef738a3f31e ]

Add a helper for checking if an rdev needs recovery.

Signed-off-by: Zheng Qixing 
Link: https://lore.kernel.org/linux-raid/20250816002534.1754356-2-zhengqixing@huaweicloud.com
Signed-off-by: Yu Kuai 
Stable-dep-of: b7ee30f0efd1 ("md: fix sync_action incorrect display during resync")
Signed-off-by: Sasha Levin

md: rename recovery_cp to resync_offset

2025-08-28T14:34:45+00:00

[ Upstream commit 907a99c314a5a695e35acff78ac61f4ec950a6d3 ]

'recovery_cp' was used to represent the progress of sync, but its name
contains recovery, which can cause confusion. Replaces 'recovery_cp'
with 'resync_offset' for clarity.

Signed-off-by: Li Nan 
Link: https://lore.kernel.org/linux-raid/20250722033340.1933388-1-linan666@huaweicloud.com
Signed-off-by: Yu Kuai 
Stable-dep-of: b7ee30f0efd1 ("md: fix sync_action incorrect display during resync")
Signed-off-by: Sasha Levin

dm: Check for forbidden splitting of zone write operations

2025-08-28T14:34:12+00:00

commit 409f9287dab3b53bffe8d28d883a529028aa6a42 upstream.

DM targets must not split zone append and write operations using
dm_accept_partial_bio() as doing so is forbidden for zone append BIOs,
breaks zone append emulation using regular write BIOs and potentially
creates deadlock situations with queue freeze operations.

Modify dm_accept_partial_bio() to add missing BUG_ON() checks for all
these cases, that is, check that the BIO is a write or write zeroes
operation. This change packs all the zone related checks together under
a static_branch_unlikely(&zoned_enabled) and done only if the target is
a zoned device.

Fixes: f211268ed1f9 ("dm: Use the block layer zone append emulation")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal 
Reviewed-by: Mikulas Patocka 
Link: https://lore.kernel.org/r/20250625093327.548866-6-dlemoal@kernel.org
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman