[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <642f35f3881ee_6e3a2085@john.notmuch>
Date: Thu, 06 Apr 2023 14:13:23 -0700
From: John Fastabend <john.fastabend@...il.com>
To: Xin Liu <liuxin350@...wei.com>, andrii@...nel.org, ast@...nel.org,
daniel@...earbox.net, martin.lau@...ux.dev, song@...nel.org,
yhs@...com, john.fastabend@...il.com, kpsingh@...nel.org,
sdf@...gle.com, haoluo@...gle.com, jolsa@...nel.org
Cc: bpf@...r.kernel.org, hsinweih@....edu,
linux-kernel@...r.kernel.org, yanan@...wei.com,
wuchangye@...wei.com, xiesongyang@...wei.com,
kongweibin2@...wei.com, liuxin350@...wei.com,
zhangmingyi5@...wei.com
Subject: RE: [PATCH bpf-next] bpf, sockmap: fix deadlocks in the sockhash and
sockmap
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@....edu>
> Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
> Signed-off-by: Xin Liu <liuxin350@...wei.com>
Yeah even if we delete entries we do it from a sockops. Thanks for the
fix.
Acked-by: John Fastabend <john.fastabend@...il.com>
Powered by blists - more mailing lists