public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Mc Guire <der.herr@hofr.at>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Nicholas Mc Guire <hofrat@osadl.org>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] rcu: change return type to bool
Date: Sun, 24 May 2015 09:27:11 +0200	[thread overview]
Message-ID: <20150524072711.GA17508@opentech.at> (raw)
In-Reply-To: <20150523185820.13b5ad82@gandalf.local.home>

On Sat, 23 May 2015, Steven Rostedt wrote:

> On Sat, 23 May 2015 16:47:52 +0200
> Nicholas Mc Guire <hofrat@osadl.org> wrote:
> 
> > Type-checking coccinelle spatches are being used to locate type mismatches
> > between function signatures and return values in this case this produced:
> > ./kernel/rcu/srcu.c:271 WARNING: return of wrong type
> >         int != unsigned long,
> > 
> > srcu_readers_active() returns an int that is the sum of per_cpu unsigned
> > long but the only user is cleanup_srcu_struct() which is using it as a
> > boolean (condition) to see if there is any readers rather than actually
> > using the approximate number of readers. The theoretically possible
> > unsigned long overflow case does not need to be handled explicitly - if
> > we had 4G++ readers then something else went wrong a long time ago.
> > 
> > proposal: change the return type to boolean. The function name is left
> >           unchanged as it fits the naming expectation for a boolean.
> > 
> > patch was compile teseted for x86_64_defconfig (implies CONFIG_SRCU=y)
> > 
> > patch is against 4.1-rc4 (localversion-next is -next-20150522)
> > 
> > Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> > ---
> >  kernel/rcu/srcu.c |    7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/rcu/srcu.c b/kernel/rcu/srcu.c
> > index fb33d35..7c4fbeb 100644
> > --- a/kernel/rcu/srcu.c
> > +++ b/kernel/rcu/srcu.c
> > @@ -252,14 +252,15 @@ static bool srcu_readers_active_idx_check(struct srcu_struct *sp, int idx)
> >  }
> >  
> >  /**
> > - * srcu_readers_active - returns approximate number of readers.
> > + * srcu_readers_active - returns true if there are readers. and false
> > + *                       otherwise
> >   * @sp: which srcu_struct to count active readers (holding srcu_read_lock).
> >   *
> >   * Note that this is not an atomic primitive, and can therefore suffer
> >   * severe errors when invoked on an active srcu_struct.  That said, it
> >   * can be useful as an error check at cleanup time.
> >   */
> > -static int srcu_readers_active(struct srcu_struct *sp)
> > +static bool srcu_readers_active(struct srcu_struct *sp)
> >  {
> >  	int cpu;
> >  	unsigned long sum = 0;
> > @@ -268,7 +269,7 @@ static int srcu_readers_active(struct srcu_struct *sp)
> >  		sum += READ_ONCE(per_cpu_ptr(sp->per_cpu_ref, cpu)->c[0]);
> >  		sum += READ_ONCE(per_cpu_ptr(sp->per_cpu_ref, cpu)->c[1]);
> >  	}
> > -	return sum;
> > +	return !!sum;
> 
> Hmm I wonder if gcc is smart enough to do the above without the need
> for !!? That is, will it turn to !! because the return of the function
> is bool, or does gcc complain about it not being bool without the !!?
> Not a criticism of the patch, just a curiosity.
>
gcc will not complain if you assign a unsigned long to a boolean
as I understand it it is a macro and is not doing any type 
checking/promotion at all - so anything can be assigned to a bool
without warning (including double and pointers).
The !! will though always make the type compatible with int so it is 
a well defined type atleast as far as __builtin_types_compatible_p()
goes, and !! also makes static code checkers happy (that are maybe not
as smart as gcc) and it does make the intent of sum being treated 
as boolean here clear.

thx!
hofrat 

  reply	other threads:[~2015-05-24  7:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-23 14:47 [PATCH RFC] rcu: change return type to bool Nicholas Mc Guire
2015-05-23 22:58 ` Steven Rostedt
2015-05-24  7:27   ` Nicholas Mc Guire [this message]
2015-05-24  7:41     ` Joe Perches
2015-05-24  8:10       ` Nicholas Mc Guire
2015-05-24  8:38         ` Joe Perches
2015-05-24  8:46           ` Nicholas Mc Guire
2015-05-26 18:30             ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150524072711.GA17508@opentech.at \
    --to=der.herr@hofr.at \
    --cc=hofrat@osadl.org \
    --cc=josh@joshtriplett.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox