Skip to content

Ls warn and stop nmi#11462

Closed
ameryhung wants to merge 2 commits intokernel-patches:bpf-next_basefrom
ameryhung:ls_warn_and_stop_nmi
Closed

Ls warn and stop nmi#11462
ameryhung wants to merge 2 commits intokernel-patches:bpf-next_basefrom
ameryhung:ls_warn_and_stop_nmi

Conversation

@ameryhung
Copy link
Copy Markdown
Contributor

No description provided.

While very unlikely, local storage theoretically may leak memory of the
size of "struct bpf_local_storage" when destroy() fails to grab
local_storage->lock and initializes selem->local_storage before other
racing map_free() see it. Warn the user to allow debugging the issue
instead of leaking the memory silently.

Note that test_maps in bpf selftests already stress tested
bpf_selem_unlink_nofail() by creating 4096 sockets and then immediately
destroying them in multiple threads. With 64 threads, 64 x 4096 socket
local storages were created and destroyed during the test and no warning
in the function were triggered.

Signed-off-by: Amery Hung <ameryhung@gmail.com>
Currently, local storage may deadlock when deferring freeing selem or
local storage through kfree_rcu(), call_rcu() or call_rcu_tasks_trace()
in NMI or reentrant. kfree_rcu() and call_rcu() have always been unsafe
in NMI. call_rcu_tasks_trace() only became unsafe when it switched to
call_srcu(). Since deleting selem in NMI is an unlikely use case,
partially mitigate it by returning error when calling from
bpf_xxx_storage_delete() helpers in NMI. The check is only added to
bpf_selem_unlink(), which is used by helpers and syscalls.
bpf_selem_unlink_nofail() is fine as it is called during map and owner
tear down that never run in NMI or reentrant.

The long-term solution requires _nolock versions of call_rcu. Another
possible solution is to defer the free through irq_work, but it would
grow the size of selem, which is non-ideal.

Fixes: a10787e ("bpf: Enable task local storage for tracing programs")
Signed-off-by: Amery Hung <ameryhung@gmail.com>
@kernel-patches-daemon-bpf kernel-patches-daemon-bpf Bot force-pushed the bpf-next_base branch 16 times, most recently from 434ad19 to 2c59812 Compare March 25, 2026 15:55
@kernel-patches-daemon-bpf
Copy link
Copy Markdown

Automatically cleaning up stale PR; feel free to reopen if needed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant