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 <bmarzins@xxxxxxxxxx>
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: "
