All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boqun Feng <boqun.feng@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Colin King <colin.king@canonical.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rcu: shift by 1UL rather than 1 to fix sign extension error
Date: Wed, 14 Dec 2016 09:40:02 +0800	[thread overview]
Message-ID: <20161214014002.GI9728@tardis.cn.ibm.com> (raw)
In-Reply-To: <20161214004755.GG9728@tardis.cn.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 3496 bytes --]

On Wed, Dec 14, 2016 at 08:47:55AM +0800, Boqun Feng wrote:
> On Tue, Dec 13, 2016 at 10:36:47AM -0800, Paul E. McKenney wrote:
> > On Wed, Dec 14, 2016 at 02:09:27AM +0800, Boqun Feng wrote:
> > > 2016年12月14日 上午1:17,"Mark Rutland" <mark.rutland@arm.com>写道:
> > > >
> > > > Hi,
> > > >
> > > > On Tue, Dec 13, 2016 at 10:56:46AM +0000, Colin King wrote:
> > > > > From: Colin Ian King <colin.king@canonical.com>
> > > > >
> > > > > mask and bit are unsigned longs, so if bit is 31 we end up sign
> > > > > extending the 1 and mask ends up as 0xffffffff80000000. Fix this
> > > > > by explicitly adding integer suffix UL ensure 1 is a unsigned long
> > > > > rather than an signed int.
> > > > >
> > > > > Issue found with static analysis with CoverityScan, CID 1388564
> > > > >
> > > > > Fixes: 8965c3ce4718754db ("rcu: Use
> > > leaf_node_for_each_mask_possible_cpu() in force_qs_rnp()")
> > > > > Signed-off-by: Colin Ian King <colin.king@canonical.com>
> > > > > ---
> > > > >  kernel/rcu/tree.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > > index 10162ac..6ecedd8 100644
> > > > > --- a/kernel/rcu/tree.c
> > > > > +++ b/kernel/rcu/tree.c
> > > > > @@ -3051,7 +3051,7 @@ static void force_qs_rnp(struct rcu_state *rsp,
> > > > >
> > > > >               leaf_node_for_each_mask_possible_cpu(rnp, rnp->qsmask,
> > > bit, cpu)
> > > > >                       if (f(per_cpu_ptr(rsp->rda, cpu), isidle, maxj))
> > > > > -                             mask |= 1 << bit;
> > > > > +                             mask |= 1UL << bit;
> > > >
> > > > So as to match the rest of the code altered in commit bc75e99983df1efd
> > > > ("rcu: Correctly handle sparse possible cpus"), and regardless of
> > > > naming, I think it'd be nicer to use leaf_node_cpu_bit(), e.g.
> > > >
> > > >         leaf_node_for_each_mask_possible_cpu(rnp, rnp->qsmask, bit, cpu)
> > > >                 if (f(per_cpu_ptr(rsp->rda, cpu), isidle, maxj))
> > > >                         mask |= leaf_node_cpu_bit(rnp, cpu);
> > > >
> > > > IMO, it would be nice to hide the iterator bit somehow, to match
> > > > for_each_leaf_node_possible_cpu(), which this largely looks similar to
> > > > otherwise.
> > > 
> > > Good point. ;-)
> > > 
> > > We can
> > > 
> > > #define for_each_leaf_node_cpu(rnp, mask, cpu) \
> > >         for((cpu) = (rnp)->grplo + find _first_bit(mask, MASK_BITS(mask)); \
> > >             (cpu) >= (rnp)->grplo && (cpu) <= (rnp)->grphi; \
> > >             (cpu) = (rnp)->grplo + find _next_bit(mask, ...,
> > > leaf_node_cpu_bit(rnp, cpu) + 1))) \
> > >                 if (!cpu_possible(cpu)) \
> > >                         continue; \
> > >                 else
> > 
> > What is the purpose of the cpu_possible() check?
> > 
> 
> To filter out CPUs in range [grplo, grphi] but not in cpu_possible_mask.
> 

Hmm.. if rcu_cpu_starting(cpu) is never called with "impossible" cpu,
IOW, ->qsmask and ->expmask never mask "impossible" cpus, then this is
just an over-care check.

I think I probably will remove this check eventually, let me audit the
code a little more for safety ;-)

Regards,
Boqun

> Regards,
> Boqun
> 
> > 							Thanx, Paul
> > 
> > > Typing from my cellphone, plz ignore the bad formatting ;-)
> > > 
> > > Regards,
> > > Boqun
> > > 
> > > > Thanks,
> > > > Mark.
> > 



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2016-12-14  1:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-13 10:56 [PATCH] rcu: shift by 1UL rather than 1 to fix sign extension error Colin King
2016-12-13 11:21 ` Boqun Feng
2016-12-13 11:33   ` Colin Ian King
2016-12-13 15:00     ` Paul E. McKenney
2016-12-14 14:42     ` Boqun Feng
2016-12-14 14:54       ` Colin Ian King
2016-12-13 12:25   ` Boqun Feng
2016-12-13 15:05     ` Paul E. McKenney
2016-12-13 17:16 ` Mark Rutland
     [not found]   ` <CAL0jBu8ackxPrOALVnx96FSyD_-sZAAMySikqYw2uf8LEezr9g@mail.gmail.com>
2016-12-13 18:36     ` Paul E. McKenney
2016-12-14  0:47       ` Boqun Feng
2016-12-14  1:40         ` Boqun Feng [this message]
2016-12-14  4:13           ` Paul E. McKenney
2016-12-14 10:55           ` Mark Rutland
2016-12-14 13:03             ` Boqun Feng
2016-12-14  1:06     ` Boqun Feng

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=20161214014002.GI9728@tardis.cn.ibm.com \
    --to=boqun.feng@gmail.com \
    --cc=colin.king@canonical.com \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.