linux-kernel - Re: [PATCH] bpftool: optimize if statement code

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 for Android: free password hash cracker in your pocket

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

Message-ID: <fe9261d8-1e1d-4060-9a7e-1902d75cff7a@kernel.org>
Date: Tue, 15 Oct 2024 13:11:48 +0100
From: Quentin Monnet <qmo@...nel.org>
To: Liu Jing <liujing@...s.chinamobile.com>
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
 martin.lau@...ux.dev, eddyz87@...il.com, song@...nel.org,
 yonghong.song@...ux.dev, john.fastabend@...il.com, kpsingh@...nel.org,
 sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org, bpf@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bpftool: optimize if statement code

2024-10-15 19:09 UTC+0800 ~ Liu Jing <liujing@...s.chinamobile.com>
> Since both conditions are used to check whether len is valid, we can combine the two conditions into a single if statement
> Signed-off-by: Liu Jing <liujing@...s.chinamobile.com>
> ---
>   tools/bpf/bpftool/feature.c | 5 ++---
>   1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c
> index 4dbc4fcdf473..0121e0fd6949 100644
> --- a/tools/bpf/bpftool/feature.c
> +++ b/tools/bpf/bpftool/feature.c
> @@ -158,10 +158,9 @@ static int get_vendor_id(int ifindex)
>   
>   	len = read(fd, buf, sizeof(buf));
>   	close(fd);
> -	if (len < 0)
> -		return -1;
> -	if (len >= (ssize_t)sizeof(buf))
> +	if ((len < 0) || (len >= (ssize_t)sizeof(buf)))
>   		return -1;
> +
>   	buf[len] = '\0';
>   
>   	return strtol(buf, NULL, 0);


Thanks. I'm not strictly opposed to the change, but it doesn't bring 
much value in my opinion. I don't think this will "optimize" the 
statement beyond what the compiler does already.

Quentin