Re: [PATCH RFC -rt] updated synchronize_all_irqs implementation

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Wed, Sep 26, 2007 at 01:19:05PM -0400, Dmitry Torokhov wrote:
> On 9/26/07, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > On Wed, Sep 26, 2007 at 09:16:55AM -0400, Dmitry Torokhov wrote:
> >
> > > No, I don't think synchronize_irq() will work for me. While in i8042 I
> > > know there are 2 possible IRQs (so I'd need 2 calls to
> > > synchronize_irq()) other drivers may not know what IRQ triggered their
> > > handler (or whether it was an IRQ at all).
> > >
> > > Actually, I need clarifucation on what you mean by "interrupt
> > > handlers" in sync_all_irqs(). Right now (if I understand it correctly)
> > > synchronize_sched() in mainline will wait for completion of all
> > > IRQ-like contexts. By IRQ-like context I mean code guardede by
> > > spinlock + IRQ off. Serio (input) drivers have their "interrupt"
> > > routines run in that IRQ-like context. They may be invoked as a result
> > > of real IRQ being raised but they also be invoked as a result of
> > > userspace action of some sort. It all depends on implementation of
> > > underlying serio port. So if sync_all_irqs() only waits for real IRQ
> > > handlers to complete it is not sufficient in my case...
> >
> > The synchronize_all_irqs() will not return until:
> >
> > 1.      All pre-existing hardirqs have completed.
> >
> > 2.      All pre-existing threaded irqs have completed.
> >
> > 3.      All preempt_disable() regions of code have completed.
> >
> > 4.      All irq-disable regions of code have completed.
> >
> > It will not necessarily wait for all softirqs to complete, but
> > then again, synchronize_sched() in non-rt might not wait for all
> > softirqs either, for example, if ksoftirqd is handling softirqs.
> >
> > Does that do what you need, or am I missing a case that needs
> > to be covered?
> 
> As long as the list includes code guarded by
> spin_lock_irqsave()/spin_unlock_irqrestore() I am happy. Does this
> count as an irq-disable region? Peter said earlier that in -rt such
> code still runs with IRQs enabled...

If I remember correctly, it depends on whether the underlying spinlock
is spinlock_t or raw_spinlock_t.

However, doesn't spin_lock_irqsave() disable preemption in both cases
(either explicitly for the spinlock_t case or implicitly via irq
disable in the raw_spinlock_t case)?  If so, synchronize_all_irqs()
should do what you want in both cases.

						Thanx, Paul