On Tue, May 16, 2023 at 10:26 PM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> 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?
Is struct file_operations.release() callback guaranteed to be called
from user context? If yes, then perhaps the most straightforward way
to guarantee synchronous bpf_link cleanup on close(link_fd) is to have
a bpf_link_put() variant that will be only called from user-context
and will just do bpf_link_free(link) directly, without checking
in_atomic().
