On 1/29/2021 2:18 PM, Colin Ian King wrote:
Hi,
Static analysis with Coverity has detected an issue with the following
commit:
commit 0aa128475d33d2d0095947eeab6b3e4d22dbd578
Author: Daniel Jurgens <danielj@xxxxxxxxxx>
Date: Fri Jan 22 23:13:53 2021 +0200
net/mlx5: Maintain separate page trees for ECPF and PF functions
The analysis is as follows:
77 static u32 get_function(u16 func_id, bool ec_function)
78 {
Operands don't affect result (CONSTANT_EXPRESSION_RESULT)
result_independent_of_operands: func_id & (ec_function << 16) is always
0 regardless of the values of its operands. This occurs as a return value.
79 return func_id & (ec_function << 16);
80 }
boolean ec_function is shifted 16 places to the left, so the result is
going to be 0x10000 or 0x00000. Bit-wise and'ing this with the 16 bit
unsigned int func_id will always result in a zero. Not sure what the
intention is, so I can't fix it.
Either the & operator should be |, or func_id should be wider than a u16
Hi, thanks for the report.
The u32 return value was supposed to be a concatenation of 16-bit
func_id and ec flag.
Hence, indeed there is a bug here.
it should be
return (u32)func_id | (ec_function << 16);
Please update if you want to post this fix patch or prefer Me/Daniel to
take it.
Eran
Colin
