Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 30 Apr 2003 21:07:07 -0700 | From | "Martin J. Bligh" <> | Subject | Re: [RFC] clustered apic irq affinity fix for i386 |
| |
>> This should be better. Thanks for the comments. > > Remind me again what the patch actually does? It seems to be purely > adding debug checks? > > Won't it just go BUG if someone boots the kernel and then tries to > manually set affinity?
Just ignoring the idiot caller would seem better, IMHO. BUG is a little extreme ;-) Personally I'm happy for clustered apic mode machines with irqbalance *disabled* to just fail the call. With it enabled, they can just fraggle the affinity for irqbalance, and be happy.
> Seems a bit racy too. setup_ioapic_dest() does: > > pending_irq_balance_apicid[irq] = mask; > ==> window here > set_ioapic_affinity(irq, mask); > > ioapic_lock is not held, so there is a window where > pending_irq_balance_apicid[irq] can be set to some other value and > io_apic_write_affinity() will accidentally go BUG. > > > Is it not possible to fix set_ioapic_affinity() for real for clustered > APIC mode? What is involved in that?
The hardware doesn't support arbitrary cpumasks. However, as long as we're running irqbalance, it doesn't matter - we only do one cpu at a time anyway.
The existing code in the mainline kernel is wrong for platforms other than clustered apic mode too. irqbalance is happily rotating us one cpu at a time, and then we go along and put our big masky foot in the thing, and splat it across multiple CPUs. If irqbalance is on, all we need to do is set up the irqbalance mask, then force a rebalance immediately.
M.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |