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]
Message-ID: <20120926162649.GB2467@linux.vnet.ibm.com>
Date:	Wed, 26 Sep 2012 09:26:49 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Sasha Levin <levinsasha928@...il.com>,
	Michael Wang <wangyun@...ux.vnet.ibm.com>,
	Dave Jones <davej@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: RCU idle CPU detection is broken in linux-next

On Wed, Sep 26, 2012 at 04:56:55PM +0200, Frederic Weisbecker wrote:
> 2012/9/25 Paul E. McKenney <paulmck@...ux.vnet.ibm.com>:
> > On Tue, Sep 25, 2012 at 01:59:26PM +0200, Frederic Weisbecker wrote:
> >> Given that we have:
> >>
> >> rcu_irq_enter()
> >>       rcu_user_exit()
> >>       rcu_user_enter()
> >> rcu_irq_exit()
> >
> > Indeed, the code to deal with irq misnestings won't like that at all.
> > And we are in the kernel between rcu_user_exit() and rcu_user_enter()
> > (right?), so we could in fact see irq misnestings.
> 
> Exactly.
> 
> >> And we already have rcu_user_exit_after_irq(), this starts to be confusing
> >> if we allow that nesting. Although if we find a solution that, in the end,
> >> merge rcu_user_exit() with rcu_user_exit_after_irq() and same for the enter version,
> >> this would probably be a good thing. Provided this doesn't involve some more
> >> complicated rdtp->dyntick_nesting trickies nor more overhead.
> >>
> >> Otherwise we could avoid to call rcu_user_* when we are in an irq. When we'll have
> >> the user_hooks layer, we can perhaps manage that from that place. For
> >> now may be we can return after in_interrupt() in the rcu user apis.
> >
> > This last sounds best.
> 
> Ok.
> 
> > My main concern is irq misnesting.  We might need to do something ugly
> > like record the interrupt nesting level at rcu_user_exit() and restore
> > it at rcu_user_enter().  Sigh!!!
> 
> Right, but that doesn't seem to apply in x86? I suggest we start
> simple and think
> about some wider solution when more architecture implement this.

Fair enough -- for one thing, we will better understand what is required
when the problems are actually encountered.  Which will hopefully be
sooner rather than later.  ;-)

							Thanx, Paul

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ