On 9/21/20 8:31 PM, Andrii Nakryiko wrote:
On Mon, Sep 21, 2020 at 10:29 AM Andrii Nakryiko
<andrii.nakry...@gmail.com> wrote:
On Thu, Sep 17, 2020 at 12:46 AM Muchun Song <songmuc...@bytedance.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 <songmuc...@bytedance.com>
---
This change seems unnecessary (or at least premature), as if we ever
get a use case that does bpf_link_put() from under held spinlock, we
should see a warning about that (and in that case I bet code can be
rewritten to not hold spinlock during bpf_link_put()). But on the
other hand it makes bpf_link_put() to follow the pattern of
bpf_map_put(), which always defers the work, so I'm ok with this. As
Song mentioned, this is not called from a performance-critical hot
path, so doesn't matter all that much.
Acked-by: Andrii Nakryiko <andr...@fb.com>
Agree, SGTM.
btw, you probably need to resubmit this patch as a non-RFC one for it
to be applied?..
Given first time BPF contributor & it has already several ACKs, I took it
into bpf-next, thanks!
