Re: [patch 00/21] 2.6.19-stable review

[ebiederm@xmission.com (Eric W. Biederman)]

Hmm..  I seem to have failed to send out this reply a few days ago :(

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Wed, 21 Feb 2007, Andrew Morton wrote:
>> > 
>> >
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch
>> >
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch
>> 
>> That's mainly an Andi decision.  Let's cc him.
>
> Would be good to have Eric also ack them as safe and obvious.
>
> Btw, that latter one has corrupted sign-offs from Andi (it's in the middle 
> of the text, very confusing).

There are two questions.
1) What can we do to make the situation better.
2) Is the hole completely plugged.

When I wrote the patch I had the local apic priorities backwards in my
head.  So apic_in_service_vector can return the wrong value if two
irqs are in service.  Now I don't think we allows ourselves to enable
interrupts in an interrupt service routing until after we have acked
the local apic so this should be harmless.  The fix is also trivial
of just having apic_in_service_vector return: "~get_irq_regs()->orig_rax".

Except for that one possible problem everything I can think of are
just theoretical cracks at this point, and they don't make the
situation any worse.

Given that this patch has appears to have undergone a noticeable
amount of testing, by people other than myself, and clears up the
symptoms.  I have no problem 


Eric