Re: [PATCH 0/2] Kill unused parameter to smp_call_function and friends

From: Jens Axboe
Date: Thu May 29 2008 - 07:47:30 EST


On Thu, May 29 2008, Alan Cox wrote:
> On Thu, 29 May 2008 11:00:59 +0200
> Jens Axboe <jens.axboe@xxxxxxxxxx> wrote:
>
> > Hi,
> >
> > It bothers me how the smp call functions accept a 'nonatomic' or 'retry'
> > parameter (depending on who you ask), but don't do anything with it.
> > So kill that silly thing.
> >
> > Two patches here, one for smp_call_function*() and one for on_each_cpu().
> > This patchset applies on top of the generic-ipi patchset just sent out.
>
> Which leads to notice that we seem to have acquired a bug somewhere on
> the way. smp_call_function on x86 is it seems to me implemented as
> "smp_call_function and occasionally run it multiple times"
>
> One of the joys of the older x86 APIC setups is the APIC messaging
> bus. This can get checksum errors in which case the message is
> retransmitted:
>
> In the specific case a message is retransmitted and there are at least
> three parties on the bus (2 CPU APICs and an IOAPIC is enough) you can
> get a situation where one receiver gets the message the second
> receiver errors it and the retransmit causes the IPI to be repeated
> which causes the IPI to be redelivered.
>
> This used to turn up now and then - particularly on 440BX boards.

That's worrisome, but I would regard that as implementation detail
for the architecture, you really cannot expect the caller to
deal with such obscure behaviour.

Did the x86 code ever deal with this? Were the transmit errors
corner case errors, or could they occur during normal runtime
when everything is/was otherwise OK?

> Alan Gnome #331: Early SMP Implementation Archive Office

;-)

I suggest such behaviour be punished by way of catapult, old
clerk guy.

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/