Messages in this thread |  | | Date | Wed, 6 Jul 2022 17:40:49 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH v2 bpf-next 5/5] bpf: trampoline: support FTRACE_OPS_FL_SHARE_IPMODIFY |
| |
On Wed, 6 Jul 2022 21:37:52 +0000 Song Liu <songliubraving@fb.com> wrote:
> > Can you comment here that returning -EAGAIN will not cause this to repeat. > > That it will change things where the next try will not return -EGAIN? > > Hmm.. this is not the guarantee here. This conflict is a real race condition > that an IPMODIFY function (i.e. livepatch) is being registered at the same time > when something else, for example bpftrace, is updating the BPF trampoline. > > This EAGAIN will propagate to the user of the IPMODIFY function (i.e. livepatch), > and we need to retry there. In the case of livepatch, the retry is initiated > from user space.
We need to be careful here then. If there's a userspace application that runs at real-time and does a:
do { errno = 0; regsiter_bpf(); } while (errno != -EAGAIN);
it could in theory preempt the owner of the lock and never make any progress.
-- Steve
|  |