* [PATCH bpf-next] bpf, sockmap: fix deadlocks in the sockhash and sockmap
@ 2023-04-06 12:26 Xin Liu
2023-04-06 21:13 ` John Fastabend
2023-04-12 23:40 ` patchwork-bot+netdevbpf
0 siblings, 2 replies; 3+ messages in thread
From: Xin Liu @ 2023-04-06 12:26 UTC (permalink / raw)
To: andrii, ast, daniel, martin.lau, song, yhs, john.fastabend,
kpsingh, sdf, haoluo, jolsa
Cc: bpf, hsinweih, linux-kernel, yanan, wuchangye, xiesongyang,
kongweibin2, liuxin350, zhangmingyi5
When huang uses sched_switch tracepoint, the tracepoint
does only one thing in the mounted ebpf program, which
deletes the fixed elements in sockhash ([0])
It seems that elements in sockhash are rarely actively
deleted by users or ebpf program. Therefore, we do not
pay much attention to their deletion. Compared with hash
maps, sockhash only provides spin_lock_bh protection.
This causes it to appear to have self-locking behavior
in the interrupt context.
[0]:https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/
Reported-by: Hsin-Wei Hung <hsinweih@uci.edu>
Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Xin Liu <liuxin350@huawei.com>
---
net/core/sock_map.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 7c189c2e2fbf..66305b7bf8b7 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -414,8 +414,9 @@ static int __sock_map_delete(struct bpf_stab *stab, struct sock *sk_test,
{
struct sock *sk;
int err = 0;
+ unsigned long flags;
- raw_spin_lock_bh(&stab->lock);
+ raw_spin_lock_irqsave(&stab->lock, flags);
sk = *psk;
if (!sk_test || sk_test == sk)
sk = xchg(psk, NULL);
@@ -425,7 +426,7 @@ static int __sock_map_delete(struct bpf_stab *stab, struct sock *sk_test,
else
err = -EINVAL;
- raw_spin_unlock_bh(&stab->lock);
+ raw_spin_unlock_irqrestore(&stab->lock, flags);
return err;
}
@@ -932,11 +933,12 @@ static long sock_hash_delete_elem(struct bpf_map *map, void *key)
struct bpf_shtab_bucket *bucket;
struct bpf_shtab_elem *elem;
int ret = -ENOENT;
+ unsigned long flags;
hash = sock_hash_bucket_hash(key, key_size);
bucket = sock_hash_select_bucket(htab, hash);
- raw_spin_lock_bh(&bucket->lock);
+ raw_spin_lock_irqsave(&bucket->lock, flags);
elem = sock_hash_lookup_elem_raw(&bucket->head, hash, key, key_size);
if (elem) {
hlist_del_rcu(&elem->node);
@@ -944,7 +946,7 @@ static long sock_hash_delete_elem(struct bpf_map *map, void *key)
sock_hash_free_elem(htab, elem);
ret = 0;
}
- raw_spin_unlock_bh(&bucket->lock);
+ raw_spin_unlock_irqrestore(&bucket->lock, flags);
return ret;
}
--
2.33.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* RE: [PATCH bpf-next] bpf, sockmap: fix deadlocks in the sockhash and sockmap
2023-04-06 12:26 [PATCH bpf-next] bpf, sockmap: fix deadlocks in the sockhash and sockmap Xin Liu
@ 2023-04-06 21:13 ` John Fastabend
2023-04-12 23:40 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 3+ messages in thread
From: John Fastabend @ 2023-04-06 21:13 UTC (permalink / raw)
To: Xin Liu, andrii, ast, daniel, martin.lau, song, yhs,
john.fastabend, kpsingh, sdf, haoluo, jolsa
Cc: bpf, hsinweih, linux-kernel, yanan, wuchangye, xiesongyang,
kongweibin2, liuxin350, zhangmingyi5
Xin Liu wrote:
> When huang uses sched_switch tracepoint, the tracepoint
> does only one thing in the mounted ebpf program, which
> deletes the fixed elements in sockhash ([0])
>
> It seems that elements in sockhash are rarely actively
> deleted by users or ebpf program. Therefore, we do not
> pay much attention to their deletion. Compared with hash
> maps, sockhash only provides spin_lock_bh protection.
> This causes it to appear to have self-locking behavior
> in the interrupt context.
>
> [0]:https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/
>
> Reported-by: Hsin-Wei Hung <hsinweih@uci.edu>
> Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
> Signed-off-by: Xin Liu <liuxin350@huawei.com>
Yeah even if we delete entries we do it from a sockops. Thanks for the
fix.
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH bpf-next] bpf, sockmap: fix deadlocks in the sockhash and sockmap
2023-04-06 12:26 [PATCH bpf-next] bpf, sockmap: fix deadlocks in the sockhash and sockmap Xin Liu
2023-04-06 21:13 ` John Fastabend
@ 2023-04-12 23:40 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 3+ messages in thread
From: patchwork-bot+netdevbpf @ 2023-04-12 23:40 UTC (permalink / raw)
To: Xin Liu
Cc: andrii, ast, daniel, martin.lau, song, yhs, john.fastabend,
kpsingh, sdf, haoluo, jolsa, bpf, hsinweih, linux-kernel, yanan,
wuchangye, xiesongyang, kongweibin2, zhangmingyi5
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:
On Thu, 6 Apr 2023 20:26:22 +0800 you wrote:
> When huang uses sched_switch tracepoint, the tracepoint
> does only one thing in the mounted ebpf program, which
> deletes the fixed elements in sockhash ([0])
>
> It seems that elements in sockhash are rarely actively
> deleted by users or ebpf program. Therefore, we do not
> pay much attention to their deletion. Compared with hash
> maps, sockhash only provides spin_lock_bh protection.
> This causes it to appear to have self-locking behavior
> in the interrupt context.
>
> [...]
Here is the summary with links:
- [bpf-next] bpf, sockmap: fix deadlocks in the sockhash and sockmap
https://git.kernel.org/bpf/bpf-next/c/ed17aa92dc56
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-04-12 23:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-06 12:26 [PATCH bpf-next] bpf, sockmap: fix deadlocks in the sockhash and sockmap Xin Liu
2023-04-06 21:13 ` John Fastabend
2023-04-12 23:40 ` patchwork-bot+netdevbpf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).