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 <[email protected]>
CC: Davidlohr Bueso <[email protected]>
CC: "Paul E. McKenney" <[email protected]>
CC: Josh Triplett <[email protected]>
CC: [email protected]
---
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
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 <[email protected]>
> CC: Davidlohr Bueso <[email protected]>
> CC: "Paul E. McKenney" <[email protected]>
> CC: Josh Triplett <[email protected]>
> CC: [email protected]
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
>
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 <[email protected]>
> > CC: Davidlohr Bueso <[email protected]>
> > CC: "Paul E. McKenney" <[email protected]>
> > CC: Josh Triplett <[email protected]>
> > CC: [email protected]
>
> 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.
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.
* Peter Zijlstra <[email protected]> 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 <[email protected]>
> > > CC: Davidlohr Bueso <[email protected]>
> > > CC: "Paul E. McKenney" <[email protected]>
> > > CC: Josh Triplett <[email protected]>
> > > CC: [email protected]
> >
> > 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
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
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.
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