summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorYao Sang <sangyao@kylinos.cn>2026-08-04 20:57:36 +0800
committerJens Axboe <axboe@kernel.dk>2026-08-15 17:44:21 -0600
commit4fd66a7f829f3f38f92a79081f0f2688aed644f0 (patch)
treec238ef6807d8592d0a226c504a922ac4083ba437 /tools/perf/scripts/python/stackcollapse.py
parent95491fb05105b61050cb623a5e0227eb26aa3525 (diff)
ublk: avoid teardown retry loop on xarray allocation failure
__ublk_shmem_remove_ranges() removes matching maple tree ranges in batches, but first stores each range into a temporary xarray so that the pages can be unpinned after dropping the maple tree lock. That temporary xarray is filled under the maple tree lock with xa_store(..., GFP_ATOMIC). If the store fails before mas_erase(), the current range is left in the tree and the helper returns false. The outer ublk_shmem_remove_ranges() loop then immediately retries the same range. While the atomic allocation keeps failing, the teardown path has no forward progress. The issue can be reproduced with radix_tree_node failslab injection after a SHMEM_ZC buffer has already been registered: # Kernel config: # CONFIG_BLK_DEV_UBLK=y # CONFIG_DEBUG_FS=y # CONFIG_FAULT_INJECTION=y # CONFIG_FAULT_INJECTION_DEBUG_FS=y # CONFIG_FAILSLAB=y echo 10 > /proc/sys/vm/nr_hugepages mkdir -p /tmp/htlb mount -t hugetlbfs none /tmp/htlb fallocate -l 4M /tmp/htlb/ublk_buf dev_id=$(kublk add -t null --shmem_zc \ --htlb /tmp/htlb/ublk_buf | awk -F '[ :]' '/dev id/ {print $3}') echo 1 > /sys/kernel/slab/radix_tree_node/failslab echo Y > /sys/kernel/debug/failslab/cache-filter echo Y > /sys/kernel/debug/failslab/ignore-gfp-wait echo 1 > /sys/kernel/debug/failslab/interval echo -1 > /sys/kernel/debug/failslab/times echo 100 > /sys/kernel/debug/failslab/probability kublk del -n "$dev_id" On the unfixed kernel the delete command was still running after 3 seconds. Disabling failslab made it return. The fault-injection stack showed: should_failslab kmem_cache_alloc_lru_noprof __xas_nomem __xa_store xa_store __ublk_shmem_remove_ranges ublk_cdev_rel ublk_ctrl_del_dev Remove the allocation from the teardown loop. Keep the existing batch limit, but collect {base_pfn, nr_pages} pairs in a fixed-size stack array. Once a matching range is found, the range is erased from the maple tree before dropping the lock, so each successful scan makes progress without depending on any GFP_ATOMIC allocation. With the same failslab settings, the fixed kernel completed "kublk del -n $dev_id" successfully in about 45 ms. Fixes: 309e02dccf64 ("ublk: avoid unpinning pages under maple tree spinlock") Signed-off-by: Yao Sang <sangyao@kylinos.cn> Reviewed-by: Ming Lei <tom.leiming@gmail.com> Link: https://patch.msgid.link/20260804125736.2011774-1-sangyao@kylinos.cn Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions