diff options
| author | Vlastimil Babka <vbabka@suse.cz> | 2025-11-03 15:24:15 +0300 |
|---|---|---|
| committer | Vlastimil Babka <vbabka@suse.cz> | 2025-11-06 10:13:12 +0300 |
| commit | c379b745e12a99f0a54bafaaf75fc710614511ce (patch) | |
| tree | d7c58fd5e3635bb3ccdf3dd9cd2dfd326685407e /drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | |
| parent | 7f434e1d9a17ca5f567c9796c9c105a65c18db9a (diff) | |
| download | linux-c379b745e12a99f0a54bafaaf75fc710614511ce.tar.xz | |
slab: prevent infinite loop in kmalloc_nolock() with debugging
In review of a followup work, Harry noticed a potential infinite loop.
Upon closed inspection, it already exists for kmalloc_nolock() on a
cache with debugging enabled, since commit af92793e52c3 ("slab:
Introduce kmalloc_nolock() and kfree_nolock().")
When alloc_single_from_new_slab() fails to trylock node list_lock, we
keep retrying to get partial slab or allocate a new slab. If we indeed
interrupted somebody holding the list_lock, the trylock fill fail
deterministically and we end up allocating and defer-freeing slabs
indefinitely with no progress.
To fix it, fail the allocation if spinning is not allowed. This is
acceptable in the restricted context of kmalloc_nolock(), especially
with debugging enabled.
Reported-by: Harry Yoo <harry.yoo@oracle.com>
Closes: https://lore.kernel.org/all/aQLqZjjq1SPD3Fml@hyeyoo/
Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().")
Acked-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
Link: https://patch.msgid.link/20251103-fix-nolock-loop-v1-1-6e2b3e82b9da@suse.cz
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Diffstat (limited to 'drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c')
0 files changed, 0 insertions, 0 deletions
