public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
	npiggin@suse.de, linux-arch@vger.kernel.org, jeremy@goop.org,
	mingo@elte.hu, paulmck@linux.vnet.ibm.com
Subject: Re: [PATCH 0/2] Kill unused parameter to smp_call_function and  friends
Date: Thu, 29 May 2008 13:47:18 +0200	[thread overview]
Message-ID: <20080529114717.GA25504@kernel.dk> (raw)
In-Reply-To: <20080529114132.663eff4b@core>

On Thu, May 29 2008, Alan Cox wrote:
> On Thu, 29 May 2008 11:00:59 +0200
> Jens Axboe <jens.axboe@oracle.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

  reply	other threads:[~2008-05-29 11:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-29  9:00 [PATCH 0/2] Kill unused parameter to smp_call_function and friends Jens Axboe
2008-05-29  9:01 ` [PATCH 1/2] smp_call_function: get rid of the unused nonatomic/retry argument Jens Axboe
2008-05-29  9:01 ` [PATCH 2/2] on_each_cpu(): kill unused 'retry' parameter Jens Axboe
2008-05-29 12:51   ` Carlos R. Mafra
2008-05-29 12:54     ` Jens Axboe
2008-05-29 13:14       ` Carlos R. Mafra
2008-05-30 11:27   ` Paul E. McKenney
2008-05-29 10:09 ` [PATCH 0/2] Kill unused parameter to smp_call_function and friends Jeremy Fitzhardinge
2008-05-29 11:49   ` Jens Axboe
2008-05-29 10:41 ` Alan Cox
2008-05-29 11:47   ` Jens Axboe [this message]
2008-05-31 20:45   ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080529114717.GA25504@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jeremy@goop.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox