fix sbitmap initialization and null_blk shared tagset behavior#58
fix sbitmap initialization and null_blk shared tagset behavior#58blktests-ci[bot] wants to merge 2 commits intolinus-master_basefrom
Conversation
|
Upstream branch: 25fae0b |
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
2 times, most recently
from
6637119 to
f092a9b
Compare
|
Upstream branch: 260f6f4 |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
d4404cf to
799965c
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
f092a9b to
0b59764
Compare
|
Upstream branch: d6084bb |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
799965c to
eb0225b
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
0b59764 to
aee5bd3
Compare
|
Upstream branch: 831462f |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
eb0225b to
8538687
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
aee5bd3 to
ef18525
Compare
|
Upstream branch: c93529a |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
8538687 to
746320f
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
ef18525 to
3851b3f
Compare
|
Upstream branch: cbbf0a7 |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
746320f to
d497799
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
3851b3f to
28b3384
Compare
|
Upstream branch: 6a68cec |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
d497799 to
31508da
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
28b3384 to
8ab9be5
Compare
|
Upstream branch: f2d282e |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
31508da to
1f7c21d
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
8ab9be5 to
5b90760
Compare
|
Upstream branch: 89748ac |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
1f7c21d to
bef3eb6
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
5b90760 to
3893da1
Compare
|
Upstream branch: 2988dfe |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
007586e to
c5fd524
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
1356209 to
ae9bce3
Compare
|
Upstream branch: c30a135 |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
c5fd524 to
20672cf
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
ae9bce3 to
e263d6e
Compare
|
Upstream branch: 561c803 |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
20672cf to
dee83e3
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
e263d6e to
77110f5
Compare
|
Upstream branch: b96ddbc |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
dee83e3 to
3a5caee
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
77110f5 to
a2e0474
Compare
|
Upstream branch: 2b38afc |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
3a5caee to
5d61311
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
a2e0474 to
36a8aec
Compare
|
Upstream branch: 8f5ae30 |
blktests-ci
Bot
force-pushed
the
series/985147=>linus-master
branch
from
5d61311 to
4a0aeda
Compare
blktests-ci
Bot
force-pushed
the
linus-master_base
branch
from
36a8aec to
1a46df6
Compare
|
Upstream branch: 53e760d |
|
Upstream branch: 0e39a73 |
|
Upstream branch: 8742b2d |
|
Upstream branch: 91325f3 |
|
Upstream branch: 3a4a036 |
|
Upstream branch: dfc0f63 |
|
Upstream branch: 0cc5352 |
|
Upstream branch: 24ea63e |
|
Upstream branch: d7ee5bd |
We observed a kernel crash when the I/O scheduler allocates an sbitmap for a hardware queue (hctx) that has no associated software queues (ctx), and later attempts to free it. When no software queues are mapped to a hardware queue, the sbitmap is initialized with a depth of zero. In such cases, the sbitmap_init_node() function should set sb->alloc_hint to NULL. However, if this is not done, sb->alloc_hint may contain garbage, and calling sbitmap_free() will pass this invalid pointer to free_percpu(), resulting in a kernel crash. Example crash trace: ================================================================== Kernel attempted to read user page (28) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000028 Faulting instruction address: 0xc000000000708f88 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries [...] CPU: 5 UID: 0 PID: 5491 Comm: mk_nullb_shared Kdump: loaded Tainted: G B 6.16.0-rc5+ #294 VOLUNTARY Tainted: [B]=BAD_PAGE Hardware name: IBM,9043-MRX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_028) hv:phyp pSeries [...] NIP [c000000000708f88] free_percpu+0x144/0xba8 LR [c000000000708f84] free_percpu+0x140/0xba8 Call Trace: free_percpu+0x140/0xba8 (unreliable) kyber_exit_hctx+0x94/0x124 blk_mq_exit_sched+0xe4/0x214 elevator_exit+0xa8/0xf4 elevator_switch+0x3b8/0x5d8 elv_update_nr_hw_queues+0x14c/0x300 blk_mq_update_nr_hw_queues+0x5cc/0x670 nullb_update_nr_hw_queues+0x118/0x1f8 [null_blk] nullb_device_submit_queues_store+0xac/0x170 [null_blk] configfs_write_iter+0x1dc/0x2d0 vfs_write+0x5b0/0x77c ksys_write+0xa0/0x180 system_call_exception+0x1b0/0x4f0 system_call_vectored_common+0x15c/0x2ec If the sbitmap depth is zero, sb->alloc_hint memory is NOT allocated, but the pointer is not explicitly set to NULL. Later, during sbitmap_free(), the kernel attempts to free sb->alloc_hint, which is a per cpu pointer variable, regardless of whether it was valid, leading to a crash. This patch ensures that sb->alloc_hint is explicitly set to NULL in sbitmap_init_node() when the requested depth is zero. This prevents free_percpu() from freeing sb->alloc_hint and thus avoids the observed crash. Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Nilay Shroff <[email protected]> Reviewed-by: Yu Kuai <[email protected]>
|
Upstream branch: b19a97d |
When a user updates the number of submit or poll queues on a null_blk device, the block layer creates new hardware queues (hctxs). However, if the device is using a shared tagset, null_blk does not map any software queues (ctx) to the newly created hctx (via null_map_queues()), resulting in those hardware queues being left unused for I/O. This behavior is misleading, as the user may expect the new queues to be functional, even though they are effectively ignored. To avoid this confusion and potential misconfiguration: - Reject runtime updates to submit_queues or poll_queues via sysfs when the device uses a shared tagset by returning -EINVAL. - During configuration validation (prior to powering on the device), reset submit_queues and poll_queues to the module parameters (g_submit_queues and g_poll_queues) if the shared tagset is enabled. This ensures consistent behavior and avoids creating unused hardware queues (hctxs) due to ineffective runtime queue updates. Signed-off-by: Nilay Shroff <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Yu Kuai <[email protected]>
2 participants
Pull request for series with
subject: fix sbitmap initialization and null_blk shared tagset behavior
version: 1
url: https://patchwork.kernel.org/project/linux-block/list/?series=985147