| Message ID | 20220731181007.3130320-1-chantr4@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | [bpf-next,v2] bpftool: Remove BPF_OBJ_NAME_LEN restriction when looking up bpf program by name | expand |
On 31/07/2022 19:10, Manu Bretelle wrote: > bpftool was limiting the length of names to BPF_OBJ_NAME_LEN in prog_parse > fds. > > Since commit b662000aff84 ("bpftool: Adding support for BTF program names") > we can get the full program name from BTF. > > This patch removes the restriction of name length when running `bpftool > prog show name ${name}`. > > Test: > Tested against some internal program names that were longer than > `BPF_OBJ_NAME_LEN`, here a redacted example of what was ran to test. > > # previous behaviour > $ sudo bpftool prog show name some_long_program_name > Error: can't parse name > # with the patch > $ sudo ./bpftool prog show name some_long_program_name > 123456789: tracing name some_long_program_name tag taghexa gpl .... > ... > ... > ... > # too long > sudo ./bpftool prog show name $(python3 -c 'print("A"*128)') > Error: can't parse name > # not too long but no match > $ sudo ./bpftool prog show name $(python3 -c 'print("A"*127)') > > Signed-off-by: Manu Bretelle <chantr4@gmail.com> > > --- > > v1 -> v2: > * Fix commit message to follow patch submission guidelines > * use strncmp instead of strcmp > * reintroduce arg length check against MAX_PROG_FULL_NAME > > > tools/bpf/bpftool/common.c | 15 ++++++++++++--- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/tools/bpf/bpftool/common.c b/tools/bpf/bpftool/common.c > index 067e9ea59e3b..3ea747b3b194 100644 > --- a/tools/bpf/bpftool/common.c > +++ b/tools/bpf/bpftool/common.c > @@ -722,6 +722,7 @@ print_all_levels(__maybe_unused enum libbpf_print_level level, > > static int prog_fd_by_nametag(void *nametag, int **fds, bool tag) > { > + char prog_name[MAX_PROG_FULL_NAME]; > unsigned int id = 0; > int fd, nb_fds = 0; > void *tmp; > @@ -754,12 +755,20 @@ static int prog_fd_by_nametag(void *nametag, int **fds, bool tag) > goto err_close_fd; > } > > - if ((tag && memcmp(nametag, info.tag, BPF_TAG_SIZE)) || > - (!tag && strncmp(nametag, info.name, BPF_OBJ_NAME_LEN))) { > + if (tag && memcmp(nametag, info.tag, BPF_TAG_SIZE)) { > close(fd); > continue; > } > > + if (!tag) { > + get_prog_full_name(&info, fd, prog_name, > + sizeof(prog_name)); Nit: This line should be aligned with the opening parenthesis from the line above, checkpatch.pl complains about it. Probably not worth sending a new version just for that, though. > + if (strncmp(nametag, prog_name, sizeof(prog_name))) { > + close(fd); > + continue; > + } > + } > + > if (nb_fds > 0) { > tmp = realloc(*fds, (nb_fds + 1) * sizeof(int)); > if (!tmp) { > @@ -820,7 +829,7 @@ int prog_parse_fds(int *argc, char ***argv, int **fds) > NEXT_ARGP(); > > name = **argv; > - if (strlen(name) > BPF_OBJ_NAME_LEN - 1) { > + if (strlen(name) > MAX_PROG_FULL_NAME - 1) { > p_err("can't parse name"); > return -1; > } Looks good, thank you! Reviewed-by: Quentin Monnet <quentin@isovalent.com>
On Mon, Aug 1, 2022 at 5:18 AM Quentin Monnet <quentin@isovalent.com> wrote: > > On 31/07/2022 19:10, Manu Bretelle wrote: > > bpftool was limiting the length of names to BPF_OBJ_NAME_LEN in prog_parse > > fds. > > > > Since commit b662000aff84 ("bpftool: Adding support for BTF program names") > > we can get the full program name from BTF. > > > > This patch removes the restriction of name length when running `bpftool > > prog show name ${name}`. > > > > Test: > > Tested against some internal program names that were longer than > > `BPF_OBJ_NAME_LEN`, here a redacted example of what was ran to test. > > > > # previous behaviour > > $ sudo bpftool prog show name some_long_program_name > > Error: can't parse name > > # with the patch > > $ sudo ./bpftool prog show name some_long_program_name > > 123456789: tracing name some_long_program_name tag taghexa gpl .... > > ... > > ... > > ... > > # too long > > sudo ./bpftool prog show name $(python3 -c 'print("A"*128)') > > Error: can't parse name > > # not too long but no match > > $ sudo ./bpftool prog show name $(python3 -c 'print("A"*127)') > > > > Signed-off-by: Manu Bretelle <chantr4@gmail.com> > > > > --- > > > > v1 -> v2: > > * Fix commit message to follow patch submission guidelines > > * use strncmp instead of strcmp > > * reintroduce arg length check against MAX_PROG_FULL_NAME > > > > > > tools/bpf/bpftool/common.c | 15 ++++++++++++--- > > 1 file changed, 12 insertions(+), 3 deletions(-) > > > > diff --git a/tools/bpf/bpftool/common.c b/tools/bpf/bpftool/common.c > > index 067e9ea59e3b..3ea747b3b194 100644 > > --- a/tools/bpf/bpftool/common.c > > +++ b/tools/bpf/bpftool/common.c > > @@ -722,6 +722,7 @@ print_all_levels(__maybe_unused enum libbpf_print_level level, > > > > static int prog_fd_by_nametag(void *nametag, int **fds, bool tag) > > { > > + char prog_name[MAX_PROG_FULL_NAME]; > > unsigned int id = 0; > > int fd, nb_fds = 0; > > void *tmp; > > @@ -754,12 +755,20 @@ static int prog_fd_by_nametag(void *nametag, int **fds, bool tag) > > goto err_close_fd; > > } > > > > - if ((tag && memcmp(nametag, info.tag, BPF_TAG_SIZE)) || > > - (!tag && strncmp(nametag, info.name, BPF_OBJ_NAME_LEN))) { > > + if (tag && memcmp(nametag, info.tag, BPF_TAG_SIZE)) { > > close(fd); > > continue; > > } > > > > + if (!tag) { > > + get_prog_full_name(&info, fd, prog_name, > > + sizeof(prog_name)); > > Nit: This line should be aligned with the opening parenthesis from the > line above, checkpatch.pl complains about it. Probably not worth sending > a new version just for that, though. Yeah, I saw that on patchwork. For some reason, the `checkpatch.pl` version I had from bpf-next tree did not catch this. Originally, I was getting an error because it was more than 75 char long. Eventually found out that shiftwidth should have been set to 8 (mine was 4). I am happy to provide a corrected version if you want, this is really just a matter of a minute now that I have the right vim indentation setting. > > > + if (strncmp(nametag, prog_name, sizeof(prog_name))) { > > + close(fd); > > + continue; > > + } > > + } > > + > > if (nb_fds > 0) { > > tmp = realloc(*fds, (nb_fds + 1) * sizeof(int)); > > if (!tmp) { > > @@ -820,7 +829,7 @@ int prog_parse_fds(int *argc, char ***argv, int **fds) > > NEXT_ARGP(); > > > > name = **argv; > > - if (strlen(name) > BPF_OBJ_NAME_LEN - 1) { > > + if (strlen(name) > MAX_PROG_FULL_NAME - 1) { > > p_err("can't parse name"); > > return -1; > > } > > Looks good, thank you! > > Reviewed-by: Quentin Monnet <quentin@isovalent.com>
On 01/08/2022 13:39, Manu Bretelle wrote: > On Mon, Aug 1, 2022 at 5:18 AM Quentin Monnet <quentin@isovalent.com> wrote: >> >> On 31/07/2022 19:10, Manu Bretelle wrote: >>> bpftool was limiting the length of names to BPF_OBJ_NAME_LEN in prog_parse >>> fds. >>> >>> Since commit b662000aff84 ("bpftool: Adding support for BTF program names") >>> we can get the full program name from BTF. >>> >>> This patch removes the restriction of name length when running `bpftool >>> prog show name ${name}`. >>> >>> Test: >>> Tested against some internal program names that were longer than >>> `BPF_OBJ_NAME_LEN`, here a redacted example of what was ran to test. >>> >>> # previous behaviour >>> $ sudo bpftool prog show name some_long_program_name >>> Error: can't parse name >>> # with the patch >>> $ sudo ./bpftool prog show name some_long_program_name >>> 123456789: tracing name some_long_program_name tag taghexa gpl .... >>> ... >>> ... >>> ... >>> # too long >>> sudo ./bpftool prog show name $(python3 -c 'print("A"*128)') >>> Error: can't parse name >>> # not too long but no match >>> $ sudo ./bpftool prog show name $(python3 -c 'print("A"*127)') >>> >>> Signed-off-by: Manu Bretelle <chantr4@gmail.com> >>> >>> --- >>> >>> v1 -> v2: >>> * Fix commit message to follow patch submission guidelines >>> * use strncmp instead of strcmp >>> * reintroduce arg length check against MAX_PROG_FULL_NAME >>> >>> >>> tools/bpf/bpftool/common.c | 15 ++++++++++++--- >>> 1 file changed, 12 insertions(+), 3 deletions(-) >>> >>> diff --git a/tools/bpf/bpftool/common.c b/tools/bpf/bpftool/common.c >>> index 067e9ea59e3b..3ea747b3b194 100644 >>> --- a/tools/bpf/bpftool/common.c >>> +++ b/tools/bpf/bpftool/common.c >>> @@ -722,6 +722,7 @@ print_all_levels(__maybe_unused enum libbpf_print_level level, >>> >>> static int prog_fd_by_nametag(void *nametag, int **fds, bool tag) >>> { >>> + char prog_name[MAX_PROG_FULL_NAME]; >>> unsigned int id = 0; >>> int fd, nb_fds = 0; >>> void *tmp; >>> @@ -754,12 +755,20 @@ static int prog_fd_by_nametag(void *nametag, int **fds, bool tag) >>> goto err_close_fd; >>> } >>> >>> - if ((tag && memcmp(nametag, info.tag, BPF_TAG_SIZE)) || >>> - (!tag && strncmp(nametag, info.name, BPF_OBJ_NAME_LEN))) { >>> + if (tag && memcmp(nametag, info.tag, BPF_TAG_SIZE)) { >>> close(fd); >>> continue; >>> } >>> >>> + if (!tag) { >>> + get_prog_full_name(&info, fd, prog_name, >>> + sizeof(prog_name)); >> >> Nit: This line should be aligned with the opening parenthesis from the >> line above, checkpatch.pl complains about it. Probably not worth sending >> a new version just for that, though. > > Yeah, I saw that on patchwork. For some reason, the `checkpatch.pl` > version I had from bpf-next tree did not catch this. It's because it's a low-level issue: a “check” for checkpatch, not a “warning” or an “error”. Checkpatch will only report this if you run it with "--strict", which the CI does. > Originally, I was getting an error because it was more than 75 char > long. Eventually found out that shiftwidth should have been set to 8 > (mine was 4). > I am happy to provide a corrected version if you want, this is really > just a matter of a minute now that I have the right vim indentation > setting. OK let's do this. Please keep my Reviewed-by on v3.
diff --git a/tools/bpf/bpftool/common.c b/tools/bpf/bpftool/common.c index 067e9ea59e3b..3ea747b3b194 100644 --- a/tools/bpf/bpftool/common.c +++ b/tools/bpf/bpftool/common.c @@ -722,6 +722,7 @@ print_all_levels(__maybe_unused enum libbpf_print_level level, static int prog_fd_by_nametag(void *nametag, int **fds, bool tag) { + char prog_name[MAX_PROG_FULL_NAME]; unsigned int id = 0; int fd, nb_fds = 0; void *tmp; @@ -754,12 +755,20 @@ static int prog_fd_by_nametag(void *nametag, int **fds, bool tag) goto err_close_fd; } - if ((tag && memcmp(nametag, info.tag, BPF_TAG_SIZE)) || - (!tag && strncmp(nametag, info.name, BPF_OBJ_NAME_LEN))) { + if (tag && memcmp(nametag, info.tag, BPF_TAG_SIZE)) { close(fd); continue; } + if (!tag) { + get_prog_full_name(&info, fd, prog_name, + sizeof(prog_name)); + if (strncmp(nametag, prog_name, sizeof(prog_name))) { + close(fd); + continue; + } + } + if (nb_fds > 0) { tmp = realloc(*fds, (nb_fds + 1) * sizeof(int)); if (!tmp) { @@ -820,7 +829,7 @@ int prog_parse_fds(int *argc, char ***argv, int **fds) NEXT_ARGP(); name = **argv; - if (strlen(name) > BPF_OBJ_NAME_LEN - 1) { + if (strlen(name) > MAX_PROG_FULL_NAME - 1) { p_err("can't parse name"); return -1; }
bpftool was limiting the length of names to BPF_OBJ_NAME_LEN in prog_parse fds. Since commit b662000aff84 ("bpftool: Adding support for BTF program names") we can get the full program name from BTF. This patch removes the restriction of name length when running `bpftool prog show name ${name}`. Test: Tested against some internal program names that were longer than `BPF_OBJ_NAME_LEN`, here a redacted example of what was ran to test. # previous behaviour $ sudo bpftool prog show name some_long_program_name Error: can't parse name # with the patch $ sudo ./bpftool prog show name some_long_program_name 123456789: tracing name some_long_program_name tag taghexa gpl .... ... ... ... # too long sudo ./bpftool prog show name $(python3 -c 'print("A"*128)') Error: can't parse name # not too long but no match $ sudo ./bpftool prog show name $(python3 -c 'print("A"*127)') Signed-off-by: Manu Bretelle <chantr4@gmail.com> --- v1 -> v2: * Fix commit message to follow patch submission guidelines * use strncmp instead of strcmp * reintroduce arg length check against MAX_PROG_FULL_NAME tools/bpf/bpftool/common.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)