On 30/05/2025 15:50, Benjamin Marzinski wrote:
+
dm_set_device_limits() should check q->limits.features for
BLK_FEAT_ATOMIC_WRITES while holding q->limits_lock, like it does for
the rest of the queue limits.
Fixes: b7c18b17a173 ("dm-table: Set BLK_FEAT_ATOMIC_WRITES for target queue
limits")
Signed-off-by: Benjamin Marzinski <bmarz...@redhat.com>
In itself, the change seems fine, but I have doubts whether it's
preferred to even grab the q->limits_lock outside block layer / its helpers.
And, apart from this, if the bottom device limits change later, do we
actually trigger a top device limits evaluation update?
---
drivers/md/dm-table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 57573e8b5aa9..9f95f77687ef 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -430,13 +430,13 @@ static int dm_set_device_limits(struct dm_target *ti,
struct dm_dev *dev,
return 0;
}
+ mutex_lock(&q->limits_lock);
/*
* BLK_FEAT_ATOMIC_WRITES is not inherited from the bottom device in
* blk_stack_limits(), so do it manually.
*/
limits->features |= (q->limits.features & BLK_FEAT_ATOMIC_WRITES);
- mutex_lock(&q->limits_lock);
if (blk_stack_limits(limits, &q->limits,
get_start_sect(bdev) + start) < 0)
DMWARN("%s: adding target device %pg caused an alignment
inconsistency: "
