linux-stable.git/block, branch v6.17.4

blk-crypto: fix missing blktrace bio split events

2025-10-19T14:37:23+00:00

commit 06d712d297649f48ebf1381d19bd24e942813b37 upstream.

trace_block_split() is missing, resulting in blktrace inability to catch
BIO split events and making it harder to analyze the BIO sequence.

Cc: stable@vger.kernel.org
Fixes: 488f6682c832 ("block: blk-crypto-fallback for Inline Encryption")
Signed-off-by: Yu Kuai 
Reviewed-by: Bart Van Assche 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

blk-throttle: fix throtl_data leak during disk release

2025-10-15T10:03:34+00:00

[ Upstream commit 336aec7b06be860477be80a4299263a2e9355789 ]

Tightening the throttle activation check in blk_throtl_activated() to
require both q->td presence and policy bit set introduced a memory leak
during disk release:

blkg_destroy_all() clears the policy bit first during queue deactivation,
causing subsequent blk_throtl_exit() to skip throtl_data cleanup when
blk_throtl_activated() fails policy check.

Idealy we should avoid modifying blk_throtl_exit() activation check because
it's intuitive that blk-throtl start from blk_throtl_init() and end in
blk_throtl_exit(). However, call blk_throtl_exit() before
blkg_destroy_all() will make a long term deadlock problem easier to
trigger[1], hence fix this problem by checking if q->td is NULL from
blk_throtl_exit(), and remove policy deactivation as well since it's
useless.

[1] https://lore.kernel.org/all/CAHj4cs9p9H5yx+ywsb3CMUdbqGPhM+8tuBvhW=9ADiCjAqza9w@mail.gmail.com/#t

Fixes: bd9fd5be6bc0 ("blk-throttle: fix access race during throttle policy activation")
Reported-by: Yi Zhang 
Closes: https://lore.kernel.org/all/CAHj4cs-p-ZwBEKigBj7T6hQCOo-H68-kVwCrV6ZvRovrr9Z+HA@mail.gmail.com/
Signed-off-by: Yu Kuai 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

block: fix stacking of atomic writes when atomics are not supported

2025-10-15T10:03:34+00:00

[ Upstream commit f2d8c5a2f79c28569edf4948b611052253b5e99a ]

Atomic writes support may not always be possible when stacking devices
which support atomic writes. Such as case is a different atomic write
boundary between stacked devices (which is not supported).

In the case that atomic writes cannot supported, the top device queue HW
limits are set to 0.

However, in blk_stack_atomic_writes_limits(), we detect that we are
stacking the first bottom device by checking the top device
atomic_write_hw_max value == 0. This get confused with the case of atomic
writes not supported, above.

Make the distinction between stacking the first bottom device and no
atomics supported by initializing stacked device atomic_write_hw_max =
UINT_MAX and checking that for stacking the first bottom device.

Fixes: d7f36dc446e8 ("block: Support atomic writes limits for stacked devices")
Signed-off-by: John Garry 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

block: update validation of atomic writes boundary for stacked devices

2025-10-15T10:03:34+00:00

[ Upstream commit bfd4037296bd7e1f95394a2e3daf8e3c1796c3b3 ]

In commit 63d092d1c1b1 ("block: use chunk_sectors when evaluating stacked
atomic write limits"), it was missed to use a chunk sectors limit check
in blk_stack_atomic_writes_boundary_head(), so update that function to
do the proper check.

Fixes: 63d092d1c1b1 ("block: use chunk_sectors when evaluating stacked atomic write limits")
Signed-off-by: John Garry 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

blk-mq: fix potential deadlock while nr_requests grown

2025-10-15T10:03:29+00:00

[ Upstream commit b86433721f46d934940528f28d49c1dedb690df1 ]

Allocate and free sched_tags while queue is freezed can deadlock[1],
this is a long term problem, hence allocate memory before freezing
queue and free memory after queue is unfreezed.

[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
Fixes: e3a2b3f931f5 ("blk-mq: allow changing of queue depth through sysfs")

Signed-off-by: Yu Kuai 
Reviewed-by: Nilay Shroff 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

blk-mq-sched: add new parameter nr_requests in blk_mq_alloc_sched_tags()

2025-10-15T10:03:29+00:00

[ Upstream commit 6293e336f6d7d3f3415346ce34993b3398846166 ]

This helper only support to allocate the default number of requests,
add a new parameter to support specific number of requests.

Prepare to fix potential deadlock in the case nr_requests grow.

Signed-off-by: Yu Kuai 
Reviewed-by: Nilay Shroff 
Signed-off-by: Jens Axboe 
Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown")
Signed-off-by: Sasha Levin

blk-mq: split bitmap grow and resize case in blk_mq_update_nr_requests()

2025-10-15T10:03:29+00:00

[ Upstream commit e63200404477456ec60c62dd8b3b1092aba2e211 ]

No functional changes are intended, make code cleaner and prepare to fix
the grow case in following patches.

Signed-off-by: Yu Kuai 
Reviewed-by: Nilay Shroff 
Signed-off-by: Jens Axboe 
Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown")
Signed-off-by: Sasha Levin

blk-mq: cleanup shared tags case in blk_mq_update_nr_requests()

2025-10-15T10:03:29+00:00

[ Upstream commit 7f2799c546dba9e12f9ff4d07936601e416c640d ]

For shared tags case, all hctx->sched_tags/tags are the same, it doesn't
make sense to call into blk_mq_tag_update_depth() multiple times for the
same tags.

Signed-off-by: Yu Kuai 
Reviewed-by: Nilay Shroff 
Signed-off-by: Jens Axboe 
Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown")
Signed-off-by: Sasha Levin

blk-mq: convert to serialize updating nr_requests with update_nr_hwq_lock

2025-10-15T10:03:29+00:00

[ Upstream commit 626ff4f8ebcb7207f01e7810acb85812ccf06bd8 ]

request_queue->nr_requests can be changed by:

a) switch elevator by updating nr_hw_queues
b) switch elevator by elevator sysfs attribute
c) configue queue sysfs attribute nr_requests

Current lock order is:

1) update_nr_hwq_lock, case a,b
2) freeze_queue
3) elevator_lock, case a,b,c

And update nr_requests is seriablized by elevator_lock() already,
however, in the case c, we'll have to allocate new sched_tags if
nr_requests grow, and do this with elevator_lock held and queue
freezed has the risk of deadlock.

Hence use update_nr_hwq_lock instead, make it possible to allocate
memory if tags grow, meanwhile also prevent nr_requests to be changed
concurrently.

Signed-off-by: Yu Kuai 
Reviewed-by: Nilay Shroff 
Signed-off-by: Jens Axboe 
Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown")
Signed-off-by: Sasha Levin

blk-mq: check invalid nr_requests in queue_requests_store()

2025-10-15T10:03:28+00:00

[ Upstream commit b46d4c447db76e36906ed59ebb9b3ef8f3383322 ]

queue_requests_store() is the only caller of
blk_mq_update_nr_requests(), and blk_mq_update_nr_requests() is the
only caller of blk_mq_tag_update_depth(), however, they all have
checkings for nr_requests input by user.

Make code cleaner by moving all the checkings to the top function:

1) nr_requests > reserved tags;
2) if there is elevator, 4 <= nr_requests <= 2048;
3) if elevator is none, 4 <= nr_requests <= tag_set->queue_depth;

Meanwhile, case 2 is the only case tags can grow and -ENOMEM might be
returned.

Signed-off-by: Yu Kuai 
Reviewed-by: Nilay Shroff 
Signed-off-by: Jens Axboe 
Stable-dep-of: b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown")
Signed-off-by: Sasha Levin