netdev - Re: [PATCH net-next] test_bpf: fix sparse warnings

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: <5554D8E4.50500@plumgrid.com>
Date:	Thu, 14 May 2015 10:18:28 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	Daniel Borkmann <daniel@...earbox.net>,
	"David S. Miller" <davem@...emloft.net>
CC:	Michael Holzheu <holzheu@...ux.vnet.ibm.com>,
	Fengguang Wu <fengguang.wu@...el.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] test_bpf: fix sparse warnings

On 5/14/15 9:10 AM, Daniel Borkmann wrote:
> On 05/14/2015 05:40 AM, Alexei Starovoitov wrote:
>> From: Michael Holzheu <holzheu@...ux.vnet.ibm.com>
>>
>> Fix several sparse warnings like:
>> lib/test_bpf.c:1824:25: sparse: constant 4294967295 is so big it is long
>> lib/test_bpf.c:1878:25: sparse: constant 0x0000ffffffff0000 is so big
>> it is long
>>
>> Fixes: cffc642d93f9 ("test_bpf: add 173 new testcases for eBPF")
>> Reported-by: Fengguang Wu <fengguang.wu@...el.com>
>> Signed-off-by: Michael Holzheu <holzheu@...ux.vnet.ibm.com>
>> Signed-off-by: Alexei Starovoitov <ast@...mgrid.com>
>> ---
>>   lib/test_bpf.c |  122
>> ++++++++++++++++++++++++++++----------------------------
>>   1 file changed, 61 insertions(+), 61 deletions(-)
>>
> ...
>>       {
>>           "ALU_MOV_K: 0x0000ffffffff0000 = 0x00000000ffffffff",
>>           .u.insns_int = {
>> -            BPF_LD_IMM64(R2, 0x0000ffffffff0000),
>> -            BPF_LD_IMM64(R3, 0x00000000ffffffff),
>> +            BPF_LD_IMM64(R2, 0x0000ffffffff0000LL),
>> +            BPF_LD_IMM64(R3, 0x00000000ffffffffLL),
>
> Should have been ULL, no?

why? The data type is derived from the value.
0xffff0000ffffffffLL is unsigned. GCC does the right thing. Here
we're just shutting up sparse.
I actually most of the time use LL as well since it's one character
shorter.

Ex:
  printf("%llx\n", 0xffff0000ffffffffLL >> 32);
  printf("%llx\n", 0xffff0000ffffffffULL >> 32);
  printf("%llx\n", ((long long)0xffff0000ffffffff) >> 32);
  printf("%llx\n", ((unsigned long long)0xffff0000ffffffff) >> 32);
will print:
  ffff0000
  ffff0000
  ffffffffffff0000
  ffff0000

I also think that sparse shouldn't be complaining about this.
The suffix is redundant.

> Anyway, the BPF_LD_IMM64() macro will cast it
> correctly anyway.

it's correct even without LL.
It's not a bugfix. It's 'mute the sparse' patch :)

> Other than that:
>
> Acked-by: Daniel Borkmann <daniel@...earbox.net>

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html