lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 19 Sep 2020 13:26:53 +0800 From: Muchun Song <songmuchun@...edance.com> To: Song Liu <song@...nel.org> Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Martin KaFai Lau <kafai@...com>, Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>, Andrii Nakryiko <andriin@...com>, John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...omium.org>, Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org> Subject: Re: [External] Re: [RFC PATCH] bpf: Fix potential call bpf_link_free() in atomic context On Fri, Sep 18, 2020 at 6:37 AM Song Liu <song@...nel.org> wrote: > > On Thu, Sep 17, 2020 at 12:46 AM Muchun Song <songmuchun@...edance.com> wrote: > > > > The in_atomic macro cannot always detect atomic context. In particular, > > it cannot know about held spinlocks in non-preemptible kernels. Although, > > there is no user call bpf_link_put() with holding spinlock now. Be the > > safe side, we can avoid this in the feature. > > > > Signed-off-by: Muchun Song <songmuchun@...edance.com> > > Acked-by: Song Liu <songliubraving@...com> > > This is a little weird, but I guess that is OK, as bpf_link_put() is > not in the critical Yeah, bpf_link_put() is OK now because there is no user call it with a holding spinlock. > path. Is the plan to eliminate in_atomic() (as much as possible)? Most other users of in_atomic() just for WARN_ON. It seems there is no problem :). -- Yours, Muchun
Powered by blists - more mailing lists