Re: [PATCH RFC -rt] updated synchronize_all_irqs implementation

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

On Tue, 25 Sep 2007 18:11:39 -0700 "Paul E. McKenney"
<paulmck@linux.vnet.ibm.com> wrote:

> On Wed, Sep 26, 2007 at 01:24:47AM +0200, Peter Zijlstra wrote:
> > On Tue, 25 Sep 2007 16:02:45 -0400 (EDT) Steven Rostedt
> > <rostedt@goodmis.org> wrote:
> > 
> > > > This would of course require that synchronize_all_irqs() be in the
> > > > RCU code rather than the irq code so that it could access the static
> > > > wakeme_after_rcu() definition and the rcu_synchronize structure.
> > > >
> > > > Thoughts?
> > > 
> > > I do like this better. Anyone else care to comment?
> > 
> > I'm still wondering why the IRQ users cannot user proper RCU as it
> > stands:
> 
> Well, that was my initial proposal.  ;-)

handler: 
> >   rcu_read_lock();
> >   foo = rcu_dereference(bar);
> >   if (foo)
> >     foo();
> >   rcu_read_unlock();
>

control routine (!handler)
> > vs
> > 
> >   rcu_assign(foo, NULL);
> >   synchronize_rcu();

> > The implicit rcu_read_lock() as placed in handle_IRQ_event() seems
> > misplaced.
> 
> OK -- where would you put them instead?  I have them covering the
> call to the handler, so what am I missing here?

in do_hardirq() (-rt) that is specific to threaded interrupts.

That said, I'm wondering if we need this whole extra sync_all_irqs()
thing. I'm just not getting why IRQ handlers should be an implicit RCU
safe context.