[PATCH] locktorture: Fix assignment of boolean variables

[PATCH] locktorture: Fix assignment of boolean variables

[Wen Yang]

Fix the following warnings reported by coccinelle:

kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1
kernel/locking/locktorture.c:918:2-20: WARNING: Assignment of bool to 0/1
kernel/locking/locktorture.c:949:3-20: WARNING: Assignment of bool to 0/1
kernel/locking/locktorture.c:682:2-19: WARNING: Assignment of bool to 0/1
kernel/locking/locktorture.c:688:2-19: WARNING: Assignment of bool to 0/1
kernel/locking/locktorture.c:648:2-20: WARNING: Assignment of bool to 0/1
kernel/locking/locktorture.c:654:2-20: WARNING: Assignment of bool to 0/1

This patch also makes the code more readable.

Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
CC: Davidlohr Bueso <dave@stgolabs.net>
CC: "Paul E. McKenney" <paulmck@linux.ibm.com>
CC: Josh Triplett <josh@joshtriplett.org>
CC: linux-kernel@vger.kernel.org
---
 kernel/locking/locktorture.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index 7d0b0ed74404..cd95c01491d8 100644
--- a/kernel/locking/locktorture.c
+++ b/kernel/locking/locktorture.c
@@ -645,13 +645,13 @@ static int lock_torture_writer(void *arg)
 		cxt.cur_ops->writelock();
 		if (WARN_ON_ONCE(lock_is_write_held))
 			lwsp->n_lock_fail++;
-		lock_is_write_held = 1;
+		lock_is_write_held = true;
 		if (WARN_ON_ONCE(lock_is_read_held))
 			lwsp->n_lock_fail++; /* rare, but... */
 
 		lwsp->n_lock_acquired++;
 		cxt.cur_ops->write_delay(&rand);
-		lock_is_write_held = 0;
+		lock_is_write_held = false;
 		cxt.cur_ops->writeunlock();
 
 		stutter_wait("lock_torture_writer");
@@ -679,13 +679,13 @@ static int lock_torture_reader(void *arg)
 			schedule_timeout_uninterruptible(1);
 
 		cxt.cur_ops->readlock();
-		lock_is_read_held = 1;
+		lock_is_read_held = true;
 		if (WARN_ON_ONCE(lock_is_write_held))
 			lrsp->n_lock_fail++; /* rare, but... */
 
 		lrsp->n_lock_acquired++;
 		cxt.cur_ops->read_delay(&rand);
-		lock_is_read_held = 0;
+		lock_is_read_held = false;
 		cxt.cur_ops->readunlock();
 
 		stutter_wait("lock_torture_reader");
@@ -700,7 +700,7 @@ static int lock_torture_reader(void *arg)
 static void __torture_print_stats(char *page,
 				  struct lock_stress_stats *statp, bool write)
 {
-	bool fail = 0;
+	bool fail = false;
 	int i, n_stress;
 	long max = 0, min = statp ? statp[0].n_lock_acquired : 0;
 	long long sum = 0;
@@ -915,7 +915,7 @@ static int __init lock_torture_init(void)
 
 	/* Initialize the statistics so that each run gets its own numbers. */
 	if (nwriters_stress) {
-		lock_is_write_held = 0;
+		lock_is_write_held = false;
 		cxt.lwsa = kmalloc_array(cxt.nrealwriters_stress,
 					 sizeof(*cxt.lwsa),
 					 GFP_KERNEL);
@@ -946,7 +946,7 @@ static int __init lock_torture_init(void)
 		}
 
 		if (nreaders_stress) {
-			lock_is_read_held = 0;
+			lock_is_read_held = false;
 			cxt.lrsa = kmalloc_array(cxt.nrealreaders_stress,
 						 sizeof(*cxt.lrsa),
 						 GFP_KERNEL);
-- 
2.19.1

Re: [PATCH] locktorture: Fix assignment of boolean variables

[Paul E. McKenney]

On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote:
> Fix the following warnings reported by coccinelle:
> 
> kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1
> kernel/locking/locktorture.c:918:2-20: WARNING: Assignment of bool to 0/1
> kernel/locking/locktorture.c:949:3-20: WARNING: Assignment of bool to 0/1
> kernel/locking/locktorture.c:682:2-19: WARNING: Assignment of bool to 0/1
> kernel/locking/locktorture.c:688:2-19: WARNING: Assignment of bool to 0/1
> kernel/locking/locktorture.c:648:2-20: WARNING: Assignment of bool to 0/1
> kernel/locking/locktorture.c:654:2-20: WARNING: Assignment of bool to 0/1
> 
> This patch also makes the code more readable.
> 
> Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
> CC: Davidlohr Bueso <dave@stgolabs.net>
> CC: "Paul E. McKenney" <paulmck@linux.ibm.com>
> CC: Josh Triplett <josh@joshtriplett.org>
> CC: linux-kernel@vger.kernel.org

Adding the current maintainers on CC.

							Thanx, Paul

> ---
>  kernel/locking/locktorture.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> index 7d0b0ed74404..cd95c01491d8 100644
> --- a/kernel/locking/locktorture.c
> +++ b/kernel/locking/locktorture.c
> @@ -645,13 +645,13 @@ static int lock_torture_writer(void *arg)
>  		cxt.cur_ops->writelock();
>  		if (WARN_ON_ONCE(lock_is_write_held))
>  			lwsp->n_lock_fail++;
> -		lock_is_write_held = 1;
> +		lock_is_write_held = true;
>  		if (WARN_ON_ONCE(lock_is_read_held))
>  			lwsp->n_lock_fail++; /* rare, but... */
>  
>  		lwsp->n_lock_acquired++;
>  		cxt.cur_ops->write_delay(&rand);
> -		lock_is_write_held = 0;
> +		lock_is_write_held = false;
>  		cxt.cur_ops->writeunlock();
>  
>  		stutter_wait("lock_torture_writer");
> @@ -679,13 +679,13 @@ static int lock_torture_reader(void *arg)
>  			schedule_timeout_uninterruptible(1);
>  
>  		cxt.cur_ops->readlock();
> -		lock_is_read_held = 1;
> +		lock_is_read_held = true;
>  		if (WARN_ON_ONCE(lock_is_write_held))
>  			lrsp->n_lock_fail++; /* rare, but... */
>  
>  		lrsp->n_lock_acquired++;
>  		cxt.cur_ops->read_delay(&rand);
> -		lock_is_read_held = 0;
> +		lock_is_read_held = false;
>  		cxt.cur_ops->readunlock();
>  
>  		stutter_wait("lock_torture_reader");
> @@ -700,7 +700,7 @@ static int lock_torture_reader(void *arg)
>  static void __torture_print_stats(char *page,
>  				  struct lock_stress_stats *statp, bool write)
>  {
> -	bool fail = 0;
> +	bool fail = false;
>  	int i, n_stress;
>  	long max = 0, min = statp ? statp[0].n_lock_acquired : 0;
>  	long long sum = 0;
> @@ -915,7 +915,7 @@ static int __init lock_torture_init(void)
>  
>  	/* Initialize the statistics so that each run gets its own numbers. */
>  	if (nwriters_stress) {
> -		lock_is_write_held = 0;
> +		lock_is_write_held = false;
>  		cxt.lwsa = kmalloc_array(cxt.nrealwriters_stress,
>  					 sizeof(*cxt.lwsa),
>  					 GFP_KERNEL);
> @@ -946,7 +946,7 @@ static int __init lock_torture_init(void)
>  		}
>  
>  		if (nreaders_stress) {
> -			lock_is_read_held = 0;
> +			lock_is_read_held = false;
>  			cxt.lrsa = kmalloc_array(cxt.nrealreaders_stress,
>  						 sizeof(*cxt.lrsa),
>  						 GFP_KERNEL);
> -- 
> 2.19.1
> 

Re: [PATCH] locktorture: Fix assignment of boolean variables

[Peter Zijlstra]

On Sat, Dec 01, 2018 at 12:37:01PM -0800, Paul E. McKenney wrote:
> On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote:
> > Fix the following warnings reported by coccinelle:
> > 
> > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1
> > kernel/locking/locktorture.c:918:2-20: WARNING: Assignment of bool to 0/1
> > kernel/locking/locktorture.c:949:3-20: WARNING: Assignment of bool to 0/1
> > kernel/locking/locktorture.c:682:2-19: WARNING: Assignment of bool to 0/1
> > kernel/locking/locktorture.c:688:2-19: WARNING: Assignment of bool to 0/1
> > kernel/locking/locktorture.c:648:2-20: WARNING: Assignment of bool to 0/1
> > kernel/locking/locktorture.c:654:2-20: WARNING: Assignment of bool to 0/1
> > 
> > This patch also makes the code more readable.
> > 
> > Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
> > CC: Davidlohr Bueso <dave@stgolabs.net>
> > CC: "Paul E. McKenney" <paulmck@linux.ibm.com>
> > CC: Josh Triplett <josh@joshtriplett.org>
> > CC: linux-kernel@vger.kernel.org
> 
> Adding the current maintainers on CC.

So I strongly disagree with this. Anybody that has trouble with 0/1 vs
false/true needs to stay the heck away from C.

I would suggest we delete that stupid coccinelle scripts that generates
these pointless warns.

Re: [PATCH] locktorture: Fix assignment of boolean variables

[Peter Zijlstra]

On Mon, Dec 03, 2018 at 09:35:00AM +0100, Peter Zijlstra wrote:
> On Sat, Dec 01, 2018 at 12:37:01PM -0800, Paul E. McKenney wrote:
> > On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote:
> > > Fix the following warnings reported by coccinelle:
> > > 
> > > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1

Not to mention that WARN is gramatically incorrect. We're not assigning
'bool' to 0/1 but the other way around.

What crap..

> So I strongly disagree with this. Anybody that has trouble with 0/1 vs
> false/true needs to stay the heck away from C.
> 
> I would suggest we delete that stupid coccinelle scripts that generates
> these pointless warns.

Re: [PATCH] locktorture: Fix assignment of boolean variables

[Ingo Molnar]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Sat, Dec 01, 2018 at 12:37:01PM -0800, Paul E. McKenney wrote:
> > On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote:
> > > Fix the following warnings reported by coccinelle:
> > > 
> > > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1
> > > kernel/locking/locktorture.c:918:2-20: WARNING: Assignment of bool to 0/1
> > > kernel/locking/locktorture.c:949:3-20: WARNING: Assignment of bool to 0/1
> > > kernel/locking/locktorture.c:682:2-19: WARNING: Assignment of bool to 0/1
> > > kernel/locking/locktorture.c:688:2-19: WARNING: Assignment of bool to 0/1
> > > kernel/locking/locktorture.c:648:2-20: WARNING: Assignment of bool to 0/1
> > > kernel/locking/locktorture.c:654:2-20: WARNING: Assignment of bool to 0/1
> > > 
> > > This patch also makes the code more readable.
> > > 
> > > Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
> > > CC: Davidlohr Bueso <dave@stgolabs.net>
> > > CC: "Paul E. McKenney" <paulmck@linux.ibm.com>
> > > CC: Josh Triplett <josh@joshtriplett.org>
> > > CC: linux-kernel@vger.kernel.org
> > 
> > Adding the current maintainers on CC.
> 
> So I strongly disagree with this. Anybody that has trouble with 0/1 vs
> false/true needs to stay the heck away from C.

Indeed, and it's actually *worse* to read, as 0/1 stands out more and is 
more compact than false/true...

The only reasonable case where bool is recommended is when functions are 
returning it, to make sure there's no mishap returning something else.

But for a plain .c variable? Nope.

> I would suggest we delete that stupid coccinelle scripts that generates
> these pointless warns.

Ack.

Thanks,

	Ingo

Re: [PATCH] locktorture: Fix assignment of boolean variables

[Julia Lawall]

On Mon, 3 Dec 2018, Peter Zijlstra wrote:

> On Mon, Dec 03, 2018 at 09:35:00AM +0100, Peter Zijlstra wrote:
> > On Sat, Dec 01, 2018 at 12:37:01PM -0800, Paul E. McKenney wrote:
> > > On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote:
> > > > Fix the following warnings reported by coccinelle:
> > > >
> > > > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1
>
> Not to mention that WARN is gramatically incorrect. We're not assigning
> 'bool' to 0/1 but the other way around.
>
> What crap..
>
> > So I strongly disagree with this. Anybody that has trouble with 0/1 vs
> > false/true needs to stay the heck away from C.
> >
> > I would suggest we delete that stupid coccinelle scripts that generates
> > these pointless warns.

Personally, I would prefer that assignments involving boolean variables
use true or false.  It seems more readable.  Potentially better for tools
as well.  But if the community really prefers 0 and 1, then the test can
be deleted.

julia

Re: [PATCH] locktorture: Fix assignment of boolean variables

[Peter Zijlstra]

On Mon, Dec 03, 2018 at 10:20:42AM +0100, Julia Lawall wrote:
> Personally, I would prefer that assignments involving boolean variables
> use true or false.  It seems more readable.  Potentially better for tools
> as well.

Then those tools are broken per the C spec.

> But if the community really prefers 0 and 1, then the test can
> be deleted.

The C language spec, specifies _Bool as an integer type wide enough to
at least store 0 and 1.

IOW, 0 and 1 are perfectly valid valus to assign to a _Bool.

And fundamentally that has to be so. That's how computers work. 0 is
false, 1 is true.

The kernel is not the place to try and abstract such stuff, C is our
portable assembler. We muck with hardware, we'd better know how the heck
it works.

Re: [PATCH] locktorture: Fix assignment of boolean variables

[Julia Lawall]

On Mon, 3 Dec 2018, Peter Zijlstra wrote:

> On Mon, Dec 03, 2018 at 10:20:42AM +0100, Julia Lawall wrote:
> > Personally, I would prefer that assignments involving boolean variables
> > use true or false.  It seems more readable.  Potentially better for tools
> > as well.
>
> Then those tools are broken per the C spec.
>
> > But if the community really prefers 0 and 1, then the test can
> > be deleted.
>
> The C language spec, specifies _Bool as an integer type wide enough to
> at least store 0 and 1.
>
> IOW, 0 and 1 are perfectly valid valus to assign to a _Bool.
>
> And fundamentally that has to be so. That's how computers work. 0 is
> false, 1 is true.
>
> The kernel is not the place to try and abstract such stuff, C is our
> portable assembler. We muck with hardware, we'd better know how the heck
> it works.

How about it it were suggested only in files that already use true and
false somewhere?

julia