On Wed, May 10, 2023 at 12:19 AM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Tue, May 9, 2023 at 6:24 AM Sebastian Andrzej Siewior
> <bigeasy@xxxxxxxxxxxxx> wrote:
> >
> > bpf_free_inode() is invoked as a RCU callback. Usually RCU callbacks are
> > invoked within softirq context. By setting rcutree.use_softirq=0 boot
> > option the RCU callbacks will be invoked in a per-CPU kthread with
> > bottom halves disabled which implies a RCU read section.
> >
> > On PREEMPT_RT the context remains fully preemptible. The RCU read
> > section however does not allow schedule() invocation. The latter happens
> > in mutex_lock() performed by bpf_trampoline_unlink_prog() originated
> > from bpf_link_put().
> >
> > Remove the context checks and use the workqueue unconditionally.
> >
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
> > ---
>
> Please see [0] and corresponding revert commit. We do want
> bpf_link_free() to happen synchronously if it's caused by close()
> syscall.
>
> f00f2f7fe860 ("Revert "bpf: Fix potential call bpf_link_free() in
> atomic context"")
>
> [0] https://lore.kernel.org/bpf/CAEf4BzZ9zwA=SrLTx9JT50OeM6fVPg0Py0Gx+K9ah2we8YtCRA@xxxxxxxxxxxxxx/
Sebastian,
Andrii is correct. We cannot do this unconditionally,
but we can do it for IS_ENABLED(CONFIG_PREEMPT_RT)
if it's causing issues on RT, but BPF users won't be happy
with non deterministic prog detach.
Do you see a different way of solving it?
