The variable 'cpu' is defined as unsigned int.
However in the for_each_possible_cpu, its values is assigned to -1.
That doesn't make sense and in the cpumask_next() it is implicitly
type conversed to int.
It is universally accepted that the implicit type conversion is
terrible.
Also, having the good programming custom will set an example for
others.
Thus, it might be better to change the definition of 'cpu' from
unsigned int to int.
Fixes: 10fad5e ("percpu, module: implement and use is_kernel/module_percpu_address()")
Signed-off-by: Jiasheng Jiang <redacted>
---
kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Miroslav Benes <mbenes@suse.cz> Date: 2021-11-08 18:31:14
[CCing Luis]
Hi,
On Fri, 29 Oct 2021, Jiasheng Jiang wrote:
The variable 'cpu' is defined as unsigned int.
However in the for_each_possible_cpu, its values is assigned to -1.
That doesn't make sense and in the cpumask_next() it is implicitly
type conversed to int.
It is universally accepted that the implicit type conversion is
terrible.
Also, having the good programming custom will set an example for
others.
Thus, it might be better to change the definition of 'cpu' from
unsigned int to int.
Frankly, I don't see a benefit of changing this. It seems fine to me.
Moreover this is not, by far, the only place in the kernel with the same
pattern.
Miroslav
From: Luis Chamberlain <mcgrof@kernel.org> Date: 2021-11-09 20:57:05
On Mon, Nov 08, 2021 at 07:31:05PM +0100, Miroslav Benes wrote:
[CCing Luis]
Hi,
On Fri, 29 Oct 2021, Jiasheng Jiang wrote:
quoted
The variable 'cpu' is defined as unsigned int.
However in the for_each_possible_cpu, its values is assigned to -1.
That doesn't make sense and in the cpumask_next() it is implicitly
type conversed to int.
It is universally accepted that the implicit type conversion is
terrible.
Also, having the good programming custom will set an example for
others.
Thus, it might be better to change the definition of 'cpu' from
unsigned int to int.
Frankly, I don't see a benefit of changing this. It seems fine to me.
Moreover this is not, by far, the only place in the kernel with the same
pattern.
Miroslav
From: Peter Zijlstra <peterz@infradead.org> Date: 2021-11-09 21:32:48
On Tue, Nov 09, 2021 at 12:56:38PM -0800, Luis Chamberlain wrote:
If we're going to do this we we must ask, is it really worth it and
moving forward then add a semantic patch rule which will pick up on
misuses.
Please, no!
This guy has been going around sending silly patches on his own, but the
moment you add this script all the robots will join him, adding to the
pile of useless crap we get to wade through each day.
I've yet to see one of these patches fix an actual problem.
From: Luis Chamberlain <mcgrof@kernel.org> Date: 2021-11-10 00:05:11
On Tue, Nov 09, 2021 at 10:25:56PM +0100, Peter Zijlstra wrote:
On Tue, Nov 09, 2021 at 12:56:38PM -0800, Luis Chamberlain wrote:
quoted
If we're going to do this we we must ask, is it really worth it and
moving forward then add a semantic patch rule which will pick up on
misuses.
Please, no!
This guy has been going around sending silly patches on his own, but the
moment you add this script all the robots will join him, adding to the
pile of useless crap we get to wade through each day.
I've yet to see one of these patches fix an actual problem.