linux-kernel - Re: [PATCH 0/2] Kill unused parameter to smp_call

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080529114717.GA25504@kernel.dk>
Date:	Thu, 29 May 2008 13:47:18 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org, peterz@...radead.org,
	npiggin@...e.de, linux-arch@...r.kernel.org, jeremy@...p.org,
	mingo@...e.hu, paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH 0/2] Kill unused parameter to smp_call_function and  friends

On Thu, May 29 2008, Alan Cox wrote:
> On Thu, 29 May 2008 11:00:59 +0200
> Jens Axboe <jens.axboe@...cle.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/