Re: [PATCH bpf] bpf, lpm_trie: Allow lookups from sleepable BPF programs

["Emil Tsalapatis" <emil@etsalapatis.com>]

On Fri May 29, 2026 at 3:02 PM EDT, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] This problem wasn't introduced by this patch, but the fix is incomplete. The patch resolves an RCU lockdep splat in `trie_lookup_elem` for sleepable BPF programs, but leaves identical core kernel locking rule violations in `trie_update_elem` and `trie_delete_elem`. Sleepable eBPF programs hold `rcu_read_lock_trace()`, not the classic `rcu_read_lock()`. The update and delete operations acquire the map's spinlock (`trie->lock`) and correctly serialize access, but they use `rcu_dereference()` to traverse the trie instead of the update-side API `rcu_dereference_protected()`. `rcu_dereference()` strictly asserts that `rcu_read_lock_held()` is true. Holding a spinlock disables preemption but does not satisfy this check, leading to the exact same 'suspicious rcu_dereference_check() usage' lockdep splat that this patch aimed to fix.
> --
>
> commit 1ac6e30b3c7fb4d93d67bfcbb5dc35077814b266
> Author: Vlad Poenaru <vlad.wing@gmail.com>
>
> bpf, lpm_trie: Allow lookups from sleepable BPF programs
>
> This commit fixes a lockdep warning caused by sleepable BPF programs
> accessing LPM tries. It updates the RCU dereference checks in
> trie_lookup_elem() to use bpf_rcu_lock_held() instead of
> rcu_read_lock_bh_held().
>
>> diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c
>> index 0f57608b385d4..ac36063cb7e62 100644
>> --- a/kernel/bpf/lpm_trie.c
>> +++ b/kernel/bpf/lpm_trie.c
> [ ... ]
>> @@ -280,7 +280,7 @@ static void *trie_lookup_elem(struct bpf_map *map, void *_key)
>>  		 */
>>  		next_bit = extract_bit(key->data, node->prefixlen);
>>  		node = rcu_dereference_check(node->child[next_bit],
>> -					     rcu_read_lock_bh_held());
>> +					     bpf_rcu_lock_held());
>>  	}
>>  
>>  	if (!found)
>
> [Severity: High]
> This is a pre-existing issue, but does this patch leave the fix incomplete?
>
> While this patch updates the lookup path to avoid lockdep splats from sleepable
> BPF programs, sleepable BPF programs can also trigger map updates and deletes.
> The functions trie_update_elem() and trie_delete_elem() acquire the map's
> spinlock (trie->lock) but traverse the tree using rcu_dereference():
>
> kernel/bpf/lpm_trie.c:trie_update_elem() {
> ...
>         while ((node = rcu_dereference(*slot))) {
>                 matchlen = longest_prefix_match(trie, node, key);
> ...
> }
>
> kernel/bpf/lpm_trie.c:trie_delete_elem() {
> ...
>         while ((node = rcu_dereference(*trim))) {
>                 matchlen = longest_prefix_match(trie, node, key);
> ...
> }
>
> Because rcu_dereference() strictly asserts that rcu_read_lock_held() is true,
> and holding a spinlock does not satisfy the classic RCU read lock check, won't
> calling map updates or deletes from sleepable programs still trigger the exact
> same suspicious rcu_dereference_check() usage lockdep splats?
>
> Should these paths be updated to use rcu_dereference_protected() since the
> trie->lock is held?

Fair point by the bot