linux-kernel - Re: 3.0-git15 Atomic scheduling in pidmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 10 Aug 2011 08:45:29 -0400
From:	Josh Boyer <jwboyer@...hat.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Josh Boyer <jwboyer@...hat.com>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: 3.0-git15 Atomic scheduling in pidmap_init

On Tue, Aug 09, 2011 at 01:35:18PM +0200, Frederic Weisbecker wrote:
> > > > > > > > diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> > > > > > > > index ba06207..8c6cb6e 100644
> > > > > > > > --- a/kernel/rcutree.c
> > > > > > > > +++ b/kernel/rcutree.c
> > > > > > > > @@ -1681,8 +1681,14 @@ static int __rcu_pending(struct rcu_state *rsp, struct rcu_data *rdp)
> > > > > > > >  		rdp->n_rp_qs_pending++;
> > > > > > > >  		if (!rdp->preemptible &&
> > > > > > > >  		    ULONG_CMP_LT(ACCESS_ONCE(rsp->jiffies_force_qs) - 1,
> > > > > > > > -				 jiffies))
> > > > > > > > -			set_need_resched();
> > > > > > > > +				 jiffies)) {
> > > > > > > > +			/* Make sure we're ready to mark the task as needing
> > > > > > > > + 			 * rescheduling otherwise we can trigger oopes early
> > > > > > > > + 			 * in the init path
> > > > > > > > + 			 */
> > > > > > > > +			if (rcu_scheduler_active)
> > > > > > > > +				set_need_resched();
> > > > > > > 

<snip>

> > > > The first time we take a scheduling-clock interrupt on a CPU with a
> > > > callback queued, we will also set qs_pending.  Hence the need to also
> > > > suppress the assignment in __note_new_gpnum().  Or better yet, just
> > > > prevent new grace periods in cpu_needs_another_gp().  I believe that doing
> > > > this will make it unnecessary to do anything in rcu_init_percpu_data().
> > > 
> > > Yeah if we have callbacks enqueued during the boot then we need to have
> > > a check in cpu_needs_another_gp().
> > > 
> > > Now rcu_init_percpu_data() still sets rdp->qs_pending to 1, and that
> > > is going to stay as is as long as preemption is disabled.
> > 
> > But setting rdp->qs_pending to 1 in rcu_init_percpu_data() has no effect
> > until a grace period starts.  So, if grace periods are prevented from

Er... really?  Because it gets set and __rcu_pending looks at it
unconditionally in the case that is calling set_need_resched.  It
doesn't check if there is anything about a grace period going on or not.

> > starting, no need to mess with rcu_init_percpu_data().  Especially given
> > that rcu_init_percpu_data() is also used at late boot and runtime for
> > CPU hotplug.
> 
> Ok.
> 
> > 
> > So I believe that it is sufficient to change cpu_needs_another_gp()
> > to check for boot being far enough along to allow grace periods.
> 
> Yep, sounds good.

I looked at doing this but got lost as to 1) how it would help the
situtation I've reported, and 2) exactly how to do that.

I'd be happy to test, but at the moment the proposed solution is
confusing to me.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/