Since commit c3494801cd1785e2 ("bpf: check pending signals while
verifying programs", bpf() may also fail with EAGAIN if the verifier
detects pending signals.
This was triggered in the cmld of GyroidOS when loading a cgroups
device program during container start. We had a look in the man page
and where confused that EAGAIN was not listed as possible error.
Digging in the kernel source revealed the EAGAIN in the verifier
introduced by the commit above. Further investigation showed that
libbpf already wraps that case, by a retry loop.
Since GyroidOS uses the system call directly and not libbpf, we missed
to handle this error correctly. Thus, this hint in the man page for
the bpf() system call should be helpful for others who implement on
the low-level interface, too.
Signed-off-by: Michael Weiß <michael.weiss@xxxxxxxxxxxxxxxxxxx>
---
man2/bpf.2 | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/man2/bpf.2 b/man2/bpf.2
index d32435a1d..7cef7f24d 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
@@ -991,6 +991,16 @@ and examine
.I log_buf
for the specific reason provided by the verifier.
.TP
+.B EAGAIN
+For
+.BR BPF_PROG_LOAD ,
+indicates that needed resources are blocked.
+This is due to the verifier detects pending signals while it is checking
+the bpf program about its validity.
+In this case, just call
+.BR bpf ()
+again with the same parameters.
+.TP
.B EBADF
.I fd
is not an open file descriptor.
--
2.30.2
