All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Cc: Roland Dreier <roland@kernel.org>,
	"Prakash, Sathya" <Sathya.Prakash@lsi.com>,
	linux-arch <linux-arch@vger.kernel.org>,
	"Desai, Kashyap" <Kashyap.Desai@lsi.com>,
	linux scsi dev <linux-scsi@vger.kernel.org>,
	Matthew Wilcox <matthew@wil.cx>,
	Hitoshi Mitake <h.mitake@gmail.com>,
	linux powerpc dev <linuxppc-dev@lists.ozlabs.org>,
	Milton Miller <miltonm@bga.com>,
	linux kernel <linux-kernel@vger.kernel.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Ingo Molnar <mingo@redhat.com>,
	"paulus@samba.org" <paulus@samba.org>,
	linux pci <linux-pci@vger.kernel.org>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic
Date: Thu, 19 May 2011 20:15:00 +0200	[thread overview]
Message-ID: <20110519181500.GF6139@elte.hu> (raw)
In-Reply-To: <1305783242.7481.42.camel@pasglop>


* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Wed, 2011-05-18 at 21:16 -0700, Roland Dreier wrote:
> > On Wed, May 18, 2011 at 11:31 AM, Milton Miller <miltonm@bga.com> wrote:
> > > So the real question should be why is x86-32 supplying a broken writeq
> > > instead of letting drivers work out what to do it when needed?
> > 
> > Sounds a lot like what I was asking a couple of years ago :)
> > http://lkml.org/lkml/2009/4/19/164
> > 
> > But Ingo insisted that non-atomic writeq would be fine:
> > http://lkml.org/lkml/2009/4/19/167
> 
> Yuck... Ingo, I think that was very wrong.
> 
> Those are for MMIO, which must almost ALWAYS know precisely what the
> resulting access size is going to be. It's not even about atomicity
> between multiple CPUs. I have seen plenty of HW for which a 64-bit
> access to a register is -not- equivalent to two 32-bit ones. In fact, in
> some case, you can get the side effects twice ... or none at all.
> 
> The only case where you can be lax is when you explicitely know that
> there is no side effects -and- the HW cope with different access sizes.
> This is not the general case and drivers need at the very least a way to
> know what the behaviour will be.

Ok, that's pretty convincing.

Unless hpa or tglx disagrees with reverting this, could any of you send a patch 
with a proper changelog etc. that applies cleanly to v2.6.39?

Thanks,

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Cc: Roland Dreier <roland@kernel.org>,
	Milton Miller <miltonm@bga.com>,
	Hitoshi Mitake <h.mitake@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>, Ingo Molnar <mingo@redhat.com>,
	"Desai, Kashyap" <Kashyap.Desai@lsi.com>,
	"Prakash, Sathya" <Sathya.Prakash@lsi.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Matthew Wilcox <matthew@wil.cx>,
	linux scsi dev <linux-scsi@vger.kernel.org>,
	"paulus@samba.org" <paulus@samba.org>,
	linux powerpc dev <linuxppc-dev@lists.ozlabs.org>,
	linux pci <linux-pci@vger.kernel.org>,
	linux kernel <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic
Date: Thu, 19 May 2011 20:15:00 +0200	[thread overview]
Message-ID: <20110519181500.GF6139@elte.hu> (raw)
Message-ID: <20110519181500.8J9rexFxMDclVoLf5MLiBlRj7RryvdRknTLPIdp8PCQ@z> (raw)
In-Reply-To: <1305783242.7481.42.camel@pasglop>


* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Wed, 2011-05-18 at 21:16 -0700, Roland Dreier wrote:
> > On Wed, May 18, 2011 at 11:31 AM, Milton Miller <miltonm@bga.com> wrote:
> > > So the real question should be why is x86-32 supplying a broken writeq
> > > instead of letting drivers work out what to do it when needed?
> > 
> > Sounds a lot like what I was asking a couple of years ago :)
> > http://lkml.org/lkml/2009/4/19/164
> > 
> > But Ingo insisted that non-atomic writeq would be fine:
> > http://lkml.org/lkml/2009/4/19/167
> 
> Yuck... Ingo, I think that was very wrong.
> 
> Those are for MMIO, which must almost ALWAYS know precisely what the
> resulting access size is going to be. It's not even about atomicity
> between multiple CPUs. I have seen plenty of HW for which a 64-bit
> access to a register is -not- equivalent to two 32-bit ones. In fact, in
> some case, you can get the side effects twice ... or none at all.
> 
> The only case where you can be lax is when you explicitely know that
> there is no side effects -and- the HW cope with different access sizes.
> This is not the general case and drivers need at the very least a way to
> know what the behaviour will be.

Ok, that's pretty convincing.

Unless hpa or tglx disagrees with reverting this, could any of you send a patch 
with a proper changelog etc. that applies cleanly to v2.6.39?

Thanks,

	Ingo

  reply	other threads:[~2011-05-19 18:15 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-04 11:53 [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic Kashyap, Desai
2011-05-17  7:16 ` James Bottomley
2011-05-18  4:07   ` Desai, Kashyap
2011-05-18  4:15     ` Matthew Wilcox
2011-05-18  4:15       ` Matthew Wilcox
2011-05-18  4:23       ` James Bottomley
2011-05-18  4:23         ` James Bottomley
2011-05-18  7:00         ` Benjamin Herrenschmidt
2011-05-18  7:00           ` Benjamin Herrenschmidt
2011-05-18  8:23           ` Milton Miller
2011-05-18  8:23             ` Milton Miller
2011-05-18 15:35             ` Moore, Eric
2011-05-18 15:35               ` Moore, Eric
2011-05-18 18:31               ` Milton Miller
2011-05-18 18:31                 ` Milton Miller
2011-05-18 18:31                 ` Milton Miller
2011-05-18 19:11                 ` Moore, Eric
2011-05-18 19:11                   ` Moore, Eric
2011-05-18 19:11                   ` Moore, Eric
2011-05-19  4:08                   ` Hitoshi Mitake
2011-05-19  4:08                     ` Hitoshi Mitake
2011-05-19  4:46                     ` James Bottomley
2011-05-19  4:46                       ` James Bottomley
2011-05-19  5:36                       ` Benjamin Herrenschmidt
2011-05-19  5:36                         ` Benjamin Herrenschmidt
2011-05-19  8:35                       ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq isnot atomic David Laight
2011-05-19  8:35                         ` David Laight
2011-05-19  8:35                         ` David Laight
2011-05-19  4:16                 ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic Roland Dreier
2011-05-19  4:16                   ` Roland Dreier
2011-05-19  5:34                   ` Benjamin Herrenschmidt
2011-05-19  5:34                     ` Benjamin Herrenschmidt
2011-05-19 18:15                     ` Ingo Molnar [this message]
2011-05-19 18:15                       ` Ingo Molnar
2011-05-19 23:54                       ` [PATCH] x86: Remove 32-bit versions of readq()/writeq() Roland Dreier
2011-05-20  1:15                         ` Hitoshi Mitake
2011-05-20  8:05                           ` Desai, Kashyap
2011-05-20 11:44                         ` Ingo Molnar
2011-05-20 12:03                           ` James Bottomley
2011-05-18 21:30               ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic Benjamin Herrenschmidt
2011-05-18 22:05                 ` Moore, Eric
2011-05-18 22:05                   ` Moore, Eric
2011-05-18  8:04         ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq isnot atomic David Laight
2011-05-18  8:04           ` David Laight
2011-05-18  5:45       ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic Benjamin Herrenschmidt
2011-05-18  5:45         ` Benjamin Herrenschmidt

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=20110519181500.GF6139@elte.hu \
    --to=mingo@elte.hu \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=Kashyap.Desai@lsi.com \
    --cc=Sathya.Prakash@lsi.com \
    --cc=benh@kernel.crashing.org \
    --cc=h.mitake@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=matthew@wil.cx \
    --cc=miltonm@bga.com \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=roland@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.