Re: [PATCH] nft_set_pipapo: remove unused pointer lt

[Colin Ian King]

On 07/04/2020 00:39, Stefano Brivio wrote:
> Hi Colin,
> 
> On Tue,  7 Apr 2020 00:20:31 +0100
> Colin King <colin.king@xxxxxxxxxxxxx> wrote:
> 
>> From: Colin Ian King <colin.king@xxxxxxxxxxxxx>
>>
>> Pointer lt being assigned with a value that is never read and
>> the pointer is redundant and can be removed.
>>
>> Addresses-Coverity: ("Unused value")
>> Signed-off-by: Colin Ian King <colin.king@xxxxxxxxxxxxx>
>> ---
>>  net/netfilter/nft_set_pipapo_avx2.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/net/netfilter/nft_set_pipapo_avx2.c b/net/netfilter/nft_set_pipapo_avx2.c
>> index d65ae0e23028..9458c6b6ea04 100644
>> --- a/net/netfilter/nft_set_pipapo_avx2.c
>> +++ b/net/netfilter/nft_set_pipapo_avx2.c
>> @@ -1049,11 +1049,9 @@ static int nft_pipapo_avx2_lookup_slow(unsigned long *map, unsigned long *fill,
>>  					struct nft_pipapo_field *f, int offset,
>>  					const u8 *pkt, bool first, bool last)
>>  {
>> -	unsigned long *lt = f->lt, bsize = f->bsize;
>> +	unsigned long bsize = f->bsize;
>>  	int i, ret = -1, b;
>>  
>> -	lt += offset * NFT_PIPAPO_LONGS_PER_M256;
>> -
>>  	if (first)
>>  		memset(map, 0xff, bsize * sizeof(*map));
>>  
>         for (i = offset; i < bsize; i++) {
>                 if (f->bb == 8)
>                         pipapo_and_field_buckets_8bit(f, map, pkt);
>                 else
>                         pipapo_and_field_buckets_4bit(f, map, pkt);
> 
> Now, this function should never be called, it's provided as a safety net
> in case this algorithm is ever run with some strange packet field size,
> still, your clean-up shows another "issue" here: as
> pipapo_and_field_buckets_*() functions use the full buckets in lookup
> tables, not just starting from an offset, there's no need to repeat
> those operations starting from offset up to bsize.
> 
> It's fine to ignore the offset (which is just a "hint" here for faster
> lookups) -- this function isn't supposed to be optimised in any way.

Ah, OK, thanks for the detailed explanation.

> 
> That is, this for loop should go away altogether, and the 'offset'
> argument should be dropped as well. Let me know if you're comfortable
> taking care of that as well, or if you prefer that I send a patch.

Probably at this point I think I'll pass the baton over to you to fix
this up as you understand the code more than I do.

> 

Cheers,

Colin