RE: x86/irq: Unbreak interrupt affinity setting

[David Laight]

From: Alexander Graf
> Sent: 26 August 2020 23:53
> 
> On 26.08.20 23:47, David Laight wrote:
> >
> > From: David Laight
> >> Sent: 26 August 2020 22:37
> >>
> >> From: Thomas Gleixner
> >>> Sent: 26 August 2020 21:22
> >> ...
> >>> Moving interrupts on x86 happens in several steps. A new vector on a
> >>> different CPU is allocated and the relevant interrupt source is
> >>> reprogrammed to that. But that's racy and there might be an interrupt
> >>> already in flight to the old vector. So the old vector is preserved until
> >>> the first interrupt arrives on the new vector and the new target CPU. Once
> >>> that happens the old vector is cleaned up, but this cleanup still depends
> >>> on the vector number being stored in pt_regs::orig_ax, which is now -1.
> >>
> >> I suspect that it is much more 'racy' than that for PCI-X interrupts.
> >> On the hardware side there is an interrupt disable bit, and address
> >> and a value.
> >> To raise an interrupt the hardware must write the value to the address.
> >>
> >> If the cpu needs to move an interrupt both the address and value
> >> need changing, but the cpu wont write the address and value using
> >> the same TLP, so the hardware could potentially write a value to
> >> the wrong address.
> >> Worse than that, the hardware could easily only look at the address
> >> and value in the clocks after checking the interrupt is enabled.
> >> So masking the interrupt immediately prior to changing the vector
> >> info may not be enough.
> >>
> >> It is likely that a read-back of the mask before updating the vector
> >> is enough.
> >
> > But not enough to assume you won't receive an interrupt after reading
> > back that interrupts are masked.
> >
> > (I've implemented the hardware side for an fpga ...)
> 
> Do we actually care in this context? All we want to know here is whether
> a device (or irqchip in between) has actually noticed that it should
> post to a new vector. If we get interrupts on random other vectors in
> between, they would simply show up as spurious, no?
> 
> So I don't quite see where this patch makes the situation any worse than
> before.

Oh, it won't make it any worse.
It just might be rather worse than anyone imagined.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)