netdev - Re: [PATCH v2 bpf-next 1/2] bpftool: Use print_entry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44958814-3145-717f-366e-ecc52f2145b9@netronome.com>
Date:   Fri, 12 Apr 2019 11:28:37 +0100
From:   Quentin Monnet <quentin.monnet@...ronome.com>
To:     Benjamin Poirier <bpoirier@...e.com>,
        Daniel Borkmann <daniel@...earbox.net>
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org,
        David Ahern <dsahern@...il.com>
Subject: Re: [PATCH v2 bpf-next 1/2] bpftool: Use print_entry_error() in case
 of ENOENT when dumping

2019-04-12 12:03 UTC+0900 ~ Benjamin Poirier <bpoirier@...e.com>
> Commit bf598a8f0f77 ("bpftool: Improve handling of ENOENT on map dumps")
> used print_entry_plain() in case of ENOENT because that function provided
> the desired formatting. However, that commit actually introduces dead code.
> Per-cpu maps are zero-filled. When reading them, it's all or nothing. There
> will never be a case where some cpus have an entry and others don't.
> 
> The truth is that ENOENT is an error case. So rework print_entry_error() to
> provide the desired formatting.
> 
> Note that this commit changes the output format in case of errors other
> than ENOENT.
> 
> example before:
> key:
> 00 00 00 00
> value:
> No space left on device
> [...]
> 
> example after:
> key: 00 00 00 00
> value:
> No space left on device
> [...]
> 
> The ENOENT case is unchanged:
> key: 00 00 00 00  value: 14 5b 00 00 00 00 00 00
> key: 01 00 00 00  value: <no entry>
> [...]
> 
> Signed-off-by: Benjamin Poirier <bpoirier@...e.com>
> ---
>   tools/bpf/bpftool/map.c | 34 ++++++++++++++--------------------
>   1 file changed, 14 insertions(+), 20 deletions(-)
> 
> diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
> index e96903078991..71840faaeab5 100644
> --- a/tools/bpf/bpftool/map.c
> +++ b/tools/bpf/bpftool/map.c
> @@ -261,20 +261,19 @@ static void print_entry_json(struct bpf_map_info *info, unsigned char *key,
>   }
>   
>   static void print_entry_error(struct bpf_map_info *info, unsigned char *key,
> -			      const char *value)
> +			      const char *value, bool single_line)

Nit: if you respin the series, could you rename "value" into "error_msg" 
or something like this to better indicate we never pass an actual map 
value to the function?

>   {
> -	int value_size = strlen(value);
> -	bool single_line, break_names;
> +	bool break_names;
>   
> -	break_names = info->key_size > 16 || value_size > 16;
> -	single_line = info->key_size + value_size <= 24 && !break_names;
> +	break_names = info->key_size > 16;
> +	single_line = single_line && !break_names;

If I understand correctly, this will also change formatting when error 
message is short (shorter than 16 characters: the "value" line will now 
be unconditionally split, even for short error messages (other than "<no 
entry>")). Why removing the condition on value_size > 16? (This is just 
a remark, I am not against changing it.)

>   
>   	printf("key:%c", break_names ? '\n' : ' ');
>   	fprint_hex(stdout, key, info->key_size, " ");
>   
>   	printf(single_line ? "  " : "\n");
>   
> -	printf("value:%c%s", break_names ? '\n' : ' ', value);
> +	printf("value:%c%s", single_line ? ' ' : '\n', value);
>   
>   	printf("\n");
>   }

[...]