On Mon, May 4, 2020 at 2:13 AM Eelco Chaudron <echaudro@xxxxxxxxxx> wrote: > > When the probe code was failing for any reason ENOTSUP was returned, even > if this was due to no having enough lock space. This patch fixes this by > returning EPERM to the user application, so it can respond and increase > the RLIMIT_MEMLOCK size. > > Signed-off-by: Eelco Chaudron <echaudro@xxxxxxxxxx> > --- > v2: Split bpf_object__probe_name() in two functions as suggested by Andrii Yeah, looks good, and this is good enough, so consider you have my ack. But I think we can further improve the experience by: 1. Changing existing "Couldn't load basic 'r0 = 0' BPF program." message to be something more meaningful and actionable for user. E.g., "Couldn't load trivial BPF program. Make sure your kernel supports BPF (CONFIG_BPF_SYSCALL=y) and/or that RLIMIT_MEMLOCK is set to big enough value." Then even complete kernel newbies can search for CONFIG_BPF_SYSCALL or RLIMIT_MEMLOCK and hopefully find useful discussions. We can/should add RLIMIT_MEMLOCK examples to some FAQ, probably as well (if it's not there already). 2. I'd do bpf_object__probe_loading() before obj->loaded is set, so that user can have a loop of bpf_object__load() that bump RLIMIT_MEMLOCK in steps. After setting obj->loaded = true, user won't be able to attemp loading again and will get "object should not be loaded twice\n". [...]
