On Tue, Jan 22, 2019 at 10:39 PM Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > > On Thu, Jan 17, 2019 at 7:28 AM Quentin Monnet > <quentin.mon...@netronome.com> wrote: > > > > > > If the user does not have root privileges (or more precisely, the > > CAP_SYS_ADMIN capability) detection will be erroneous for most > > parameters. Therefore, forbid non-root users to run the command. > > > > v5: > > - Move exported symbols to a new LIBBPF_0.0.2 section in libbpf.map > > (patches 4 to 6). > > - Minor fixes on patches 3 and 4. > > I was about to apply the set, > but while testing on older kernels bpftool crashed the box. > It's a kernel bug, no doubt, but bpftool shouldn't be doing > dangerous operations if it can potentially crash it. > I'm debugging what went wrong. > It crashed after this message: > CONFIG_XFRM is set to y > dmesg was: > [1757577.380114] BUG: unable to handle kernel > [1757577.388476] NULL pointer dereference > [1757577.395957] at (null) > [1757577.402752] IP: (null) > [1757577.421265] Call Trace: > [1757577.421269] ? SyS_bpf+0x18b/0x16b0 > [1757577.421272] ? __audit_syscall_entry+0xb5/0x100 > [1757577.421277] do_syscall_64+0x53/0x150 > Not sure how that was possible. > I'm still debugging.
Changed my mind and applied to bpf-next. Turned out that one of the map types was defined in ops, but body was not backported due to large dependencies not suitable for backport. That caused map_create syscall to crash. Will send a separate fix to improve backport resilience.
