On Wed, 13 Apr 2005, Andrew Morton wrote:
> Zwane Mwaikambo <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 13 Apr 2005, Luck, Tony wrote:
> >
> > > But my local cpu hotplug expert (Ashok) has this to say about
> > > the irq redirection part of the i386 code:
> > >
> > > On i386, the way they do in fixup_irqs() to
> > >
> > > Redirect interrupts
> > > Local_irq_enable() // hack to permit irq processing
> > > Mdelay();; hack to wait
> > > Local_irq_disable()
> > >
> > > Is totally not the right solution, there are easy cases that a race
> > > condition can be triggered, and chipsets can also lockup if you do
> > > programming the rte's without disabling them first.
> > >
> > > This really ought to be fixed before putting it into production
> > > kernels.
> > >
> > > They also need to change irq to deferred mode when we do proc/irq
> > > write handling like what we do for ia64.
> >
> > I'd prefer doing that change as a followup, but i'm fine with doing it
> > before, i'm just trying to avoid patches dependent on this backing up.
>
> That sounds reasonable at this stage, if the racy code is only used during
> "hotplugging". But I don't think that's the case, is it?
There is also the racy /proc/irq/$nr/smp_affinity interface, which
userspace daemons like irqbalanced would have trigger. This is a
longstanding bug.
Thanks,
Zwane
