netdev - Re: [External] Re: [RFC PATCH] bpf: Fix potential call bpf_link

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMZfGtWVgZ9CojskbN5bnex-z4=NLux0BrODVk6eG+=kfYjfBw@mail.gmail.com>
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