* [PATCH bpf-next] libbpf: fix probe code to return EPERM if encountered @ 2020-04-30 10:23 Eelco Chaudron 2020-04-30 10:49 ` Toke Høiland-Jørgensen 2020-04-30 18:12 ` Andrii Nakryiko 0 siblings, 2 replies; 6+ messages in thread From: Eelco Chaudron @ 2020-04-30 10:23 UTC (permalink / raw) To: bpf; +Cc: davem, netdev, ast, daniel, kafai, songliubraving, yhs, andriin, toke 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@redhat.com> --- tools/lib/bpf/libbpf.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index 8f480e29a6b0..a62388a151d4 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -3381,8 +3381,13 @@ bpf_object__probe_caps(struct bpf_object *obj) for (i = 0; i < ARRAY_SIZE(probe_fn); i++) { ret = probe_fn[i](obj); - if (ret < 0) + if (ret < 0) { pr_debug("Probe #%d failed with %d.\n", i, ret); + if (ret == -EPERM) { + pr_perm_msg(ret); + return ret; + } + } } return 0; ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next] libbpf: fix probe code to return EPERM if encountered 2020-04-30 10:23 [PATCH bpf-next] libbpf: fix probe code to return EPERM if encountered Eelco Chaudron @ 2020-04-30 10:49 ` Toke Høiland-Jørgensen 2020-04-30 18:12 ` Andrii Nakryiko 1 sibling, 0 replies; 6+ messages in thread From: Toke Høiland-Jørgensen @ 2020-04-30 10:49 UTC (permalink / raw) To: Eelco Chaudron, bpf Cc: davem, netdev, ast, daniel, kafai, songliubraving, yhs, andriin Eelco Chaudron <echaudro@redhat.com> writes: > 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@redhat.com> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com> For context - we ran into this in xdp-tools where we've implemented "fiddle rlimit and retry" logic in response to EPERM errors, and suddenly we were seeing ENOTSUP errors instead. See discussion here: https://github.com/xdp-project/xdp-tools/pull/16 -Toke ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next] libbpf: fix probe code to return EPERM if encountered 2020-04-30 10:23 [PATCH bpf-next] libbpf: fix probe code to return EPERM if encountered Eelco Chaudron 2020-04-30 10:49 ` Toke Høiland-Jørgensen @ 2020-04-30 18:12 ` Andrii Nakryiko 2020-05-01 9:56 ` Eelco Chaudron 1 sibling, 1 reply; 6+ messages in thread From: Andrii Nakryiko @ 2020-04-30 18:12 UTC (permalink / raw) To: Eelco Chaudron Cc: bpf, David S. Miller, Networking, Alexei Starovoitov, Daniel Borkmann, Martin Lau, Song Liu, Yonghong Song, Andrii Nakryiko, Toke Høiland-Jørgensen On Thu, Apr 30, 2020 at 3:24 AM Eelco Chaudron <echaudro@redhat.com> 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@redhat.com> > --- > tools/lib/bpf/libbpf.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > index 8f480e29a6b0..a62388a151d4 100644 > --- a/tools/lib/bpf/libbpf.c > +++ b/tools/lib/bpf/libbpf.c > @@ -3381,8 +3381,13 @@ bpf_object__probe_caps(struct bpf_object *obj) > > for (i = 0; i < ARRAY_SIZE(probe_fn); i++) { > ret = probe_fn[i](obj); > - if (ret < 0) > + if (ret < 0) { > pr_debug("Probe #%d failed with %d.\n", i, ret); > + if (ret == -EPERM) { > + pr_perm_msg(ret); > + return ret; I think this is dangerous to do. This detection loop is not supposed to return error to user if any of the features are missing. I'd feel more comfortable if we split bpf_object__probe_name() into two tests: one testing trivial program and another testing same program with name. If the first one fails with EPERM -- then we can return error to user. If anything else fails -- that's ok. Thoughts? > + } > + } > } > > return 0; > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next] libbpf: fix probe code to return EPERM if encountered 2020-04-30 18:12 ` Andrii Nakryiko @ 2020-05-01 9:56 ` Eelco Chaudron 2020-05-01 19:16 ` Andrii Nakryiko 0 siblings, 1 reply; 6+ messages in thread From: Eelco Chaudron @ 2020-05-01 9:56 UTC (permalink / raw) To: Andrii Nakryiko Cc: bpf, David S. Miller, Networking, Alexei Starovoitov, Daniel Borkmann, Martin Lau, Song Liu, Yonghong Song, Andrii Nakryiko, Toke Høiland-Jørgensen On 30 Apr 2020, at 20:12, Andrii Nakryiko wrote: > On Thu, Apr 30, 2020 at 3:24 AM Eelco Chaudron <echaudro@redhat.com> > 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@redhat.com> >> --- >> tools/lib/bpf/libbpf.c | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c >> index 8f480e29a6b0..a62388a151d4 100644 >> --- a/tools/lib/bpf/libbpf.c >> +++ b/tools/lib/bpf/libbpf.c >> @@ -3381,8 +3381,13 @@ bpf_object__probe_caps(struct bpf_object *obj) >> >> for (i = 0; i < ARRAY_SIZE(probe_fn); i++) { >> ret = probe_fn[i](obj); >> - if (ret < 0) >> + if (ret < 0) { >> pr_debug("Probe #%d failed with %d.\n", i, >> ret); >> + if (ret == -EPERM) { >> + pr_perm_msg(ret); >> + return ret; > > I think this is dangerous to do. This detection loop is not supposed > to return error to user if any of the features are missing. I'd feel > more comfortable if we split bpf_object__probe_name() into two tests: > one testing trivial program and another testing same program with > name. If the first one fails with EPERM -- then we can return error to > user. If anything else fails -- that's ok. Thoughts? Before sending the patch I briefly checked the existing probes and did not see any other code path that could lead to EPERM. But you are right that this might not be the case for previous kernels. So you suggest something like this? diff --git a/src/libbpf.c b/src/libbpf.c index ff91742..fd5fdee 100644 --- a/src/libbpf.c +++ b/src/libbpf.c @@ -3130,7 +3130,7 @@ int bpf_map__resize(struct bpf_map *map, __u32 max_entries) } static int -bpf_object__probe_name(struct bpf_object *obj) +bpf_object__probe_loading(struct bpf_object *obj) { struct bpf_load_program_attr attr; char *cp, errmsg[STRERR_BUFSIZE]; @@ -3157,8 +3157,26 @@ bpf_object__probe_name(struct bpf_object *obj) } close(ret); - /* now try the same program, but with the name */ + return 0; +} +static int +bpf_object__probe_name(struct bpf_object *obj) +{ + struct bpf_load_program_attr attr; + struct bpf_insn insns[] = { + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + }; + int ret; + + /* make sure loading with name works */ + + memset(&attr, 0, sizeof(attr)); + attr.prog_type = BPF_PROG_TYPE_SOCKET_FILTER; + attr.insns = insns; + attr.insns_cnt = ARRAY_SIZE(insns); + attr.license = "GPL"; attr.name = "test"; ret = bpf_load_program_xattr(&attr, NULL, 0); if (ret >= 0) { @@ -3328,6 +3346,11 @@ bpf_object__probe_caps(struct bpf_object *obj) }; int i, ret; + if (bpf_object__probe_loading(obj) == -EPERM) { + pr_perm_msg(-EPERM); + return -EPERM; + } + for (i = 0; i < ARRAY_SIZE(probe_fn); i++) { ret = probe_fn[i](obj); if (ret < 0) Let me know, and I sent out a v2. Cheers, Eelco ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next] libbpf: fix probe code to return EPERM if encountered 2020-05-01 9:56 ` Eelco Chaudron @ 2020-05-01 19:16 ` Andrii Nakryiko 2020-05-04 8:57 ` Eelco Chaudron 0 siblings, 1 reply; 6+ messages in thread From: Andrii Nakryiko @ 2020-05-01 19:16 UTC (permalink / raw) To: Eelco Chaudron Cc: bpf, David S. Miller, Networking, Alexei Starovoitov, Daniel Borkmann, Martin Lau, Song Liu, Yonghong Song, Andrii Nakryiko, Toke Høiland-Jørgensen On Fri, May 1, 2020 at 2:56 AM Eelco Chaudron <echaudro@redhat.com> wrote: > > > > On 30 Apr 2020, at 20:12, Andrii Nakryiko wrote: > > > On Thu, Apr 30, 2020 at 3:24 AM Eelco Chaudron <echaudro@redhat.com> > > 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@redhat.com> > >> --- > >> tools/lib/bpf/libbpf.c | 7 ++++++- > >> 1 file changed, 6 insertions(+), 1 deletion(-) > >> > >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > >> index 8f480e29a6b0..a62388a151d4 100644 > >> --- a/tools/lib/bpf/libbpf.c > >> +++ b/tools/lib/bpf/libbpf.c > >> @@ -3381,8 +3381,13 @@ bpf_object__probe_caps(struct bpf_object *obj) > >> > >> for (i = 0; i < ARRAY_SIZE(probe_fn); i++) { > >> ret = probe_fn[i](obj); > >> - if (ret < 0) > >> + if (ret < 0) { > >> pr_debug("Probe #%d failed with %d.\n", i, > >> ret); > >> + if (ret == -EPERM) { > >> + pr_perm_msg(ret); > >> + return ret; > > > > I think this is dangerous to do. This detection loop is not supposed > > to return error to user if any of the features are missing. I'd feel > > more comfortable if we split bpf_object__probe_name() into two tests: > > one testing trivial program and another testing same program with > > name. If the first one fails with EPERM -- then we can return error to > > user. If anything else fails -- that's ok. Thoughts? > > Before sending the patch I briefly checked the existing probes and did > not see any other code path that could lead to EPERM. But you are right > that this might not be the case for previous kernels. So you suggest > something like this? It both previous as well as future kernel version. We can never be 100% sure. While the idea of probe_caps() is to detect optional features. > > diff --git a/src/libbpf.c b/src/libbpf.c > index ff91742..fd5fdee 100644 > --- a/src/libbpf.c > +++ b/src/libbpf.c > @@ -3130,7 +3130,7 @@ int bpf_map__resize(struct bpf_map *map, __u32 > max_entries) > } > > static int > -bpf_object__probe_name(struct bpf_object *obj) > +bpf_object__probe_loading(struct bpf_object *obj) > { > struct bpf_load_program_attr attr; > char *cp, errmsg[STRERR_BUFSIZE]; > @@ -3157,8 +3157,26 @@ bpf_object__probe_name(struct bpf_object *obj) > } > close(ret); > > - /* now try the same program, but with the name */ > + return 0; > +} > > +static int > +bpf_object__probe_name(struct bpf_object *obj) > +{ > + struct bpf_load_program_attr attr; > + struct bpf_insn insns[] = { > + BPF_MOV64_IMM(BPF_REG_0, 0), > + BPF_EXIT_INSN(), > + }; > + int ret; > + > + /* make sure loading with name works */ > + > + memset(&attr, 0, sizeof(attr)); > + attr.prog_type = BPF_PROG_TYPE_SOCKET_FILTER; > + attr.insns = insns; > + attr.insns_cnt = ARRAY_SIZE(insns); > + attr.license = "GPL"; > attr.name = "test"; > ret = bpf_load_program_xattr(&attr, NULL, 0); > if (ret >= 0) { > @@ -3328,6 +3346,11 @@ bpf_object__probe_caps(struct bpf_object *obj) > }; > int i, ret; > > + if (bpf_object__probe_loading(obj) == -EPERM) { > + pr_perm_msg(-EPERM); > + return -EPERM; > + } > + > for (i = 0; i < ARRAY_SIZE(probe_fn); i++) { > ret = probe_fn[i](obj); > if (ret < 0) > > Let me know, and I sent out a v2. Yes, that's the split I had in mind, but I'd move bpf_object__probe_loading() call directly into bpf_object__load() to be the first thing to check. probe_caps() should still be non-failing if any feature is missing. Does it make sense? > > Cheers, > > Eelco > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next] libbpf: fix probe code to return EPERM if encountered 2020-05-01 19:16 ` Andrii Nakryiko @ 2020-05-04 8:57 ` Eelco Chaudron 0 siblings, 0 replies; 6+ messages in thread From: Eelco Chaudron @ 2020-05-04 8:57 UTC (permalink / raw) To: Andrii Nakryiko Cc: bpf, David S. Miller, Networking, Alexei Starovoitov, Daniel Borkmann, Martin Lau, Song Liu, Yonghong Song, Andrii Nakryiko, Toke Høiland-Jørgensen On 1 May 2020, at 21:16, Andrii Nakryiko wrote: > On Fri, May 1, 2020 at 2:56 AM Eelco Chaudron <echaudro@redhat.com> wrote: <SNIP> >> >> Let me know, and I sent out a v2. > > Yes, that's the split I had in mind, but I'd move > bpf_object__probe_loading() call directly into bpf_object__load() to > be the first thing to check. probe_caps() should still be non-failing > if any feature is missing. Does it make sense? I think I got it :) I’ll send out a v2 soon… //Eelco ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-05-04 8:57 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-04-30 10:23 [PATCH bpf-next] libbpf: fix probe code to return EPERM if encountered Eelco Chaudron 2020-04-30 10:49 ` Toke Høiland-Jørgensen 2020-04-30 18:12 ` Andrii Nakryiko 2020-05-01 9:56 ` Eelco Chaudron 2020-05-01 19:16 ` Andrii Nakryiko 2020-05-04 8:57 ` Eelco Chaudron
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox