[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ttkuber7.fsf@cloudflare.com>
Date: Mon, 25 Mar 2024 14:49:19 +0100
From: Jakub Sitnicki <jakub@...udflare.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>, Edward Adam Davis
<eadavis@...com>, John Fastabend <john.fastabend@...il.com>
Cc: syzbot+c4f4d25859c2e5859988@...kaller.appspotmail.com,
42.hyeyoo@...il.com, andrii@...nel.org, ast@...nel.org,
bpf@...r.kernel.org, daniel@...earbox.net, davem@...emloft.net,
edumazet@...gle.com, kafai@...com, kpsingh@...nel.org, kuba@...nel.org,
linux-kernel@...r.kernel.org, namhyung@...nel.org, netdev@...r.kernel.org,
pabeni@...hat.com, peterz@...radead.org, songliubraving@...com,
syzkaller-bugs@...glegroups.com, yhs@...com
Subject: Re: [PATCH] bpf, sockmap: fix deadlock in rcu_report_exp_cpu_mult
On Mon, Mar 25, 2024 at 01:23 PM +01, Jakub Sitnicki wrote:
[...]
> But we also need to cover sock_map_unref->sock_sock_map_del_link called
> from sock_hash_delete_elem. It also grabs a spin lock.
On second look, no need to disable interrupts in
sock_map_unref->sock_sock_map_del_link. Call is enclosed in the critical
section in sock_hash_delete_elem that has been updated.
I have a question, though, why are we patching sock_hash_free? It
doesn't get called unless there are no more existing users of the BPF
map. So nothing can mutate it from interrupt context.
[...]
Powered by blists - more mailing lists