linux-kernel - Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic

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: <1305783242.7481.42.camel@pasglop>
Date:	Thu, 19 May 2011 15:34:02 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Roland Dreier <roland@...nel.org>
Cc:	Milton Miller <miltonm@....com>,
	Hitoshi Mitake <h.mitake@...il.com>,
	Sam Ravnborg <sam@...nborg.org>, Ingo Molnar <mingo@...e.hu>,
	Ingo Molnar <mingo@...hat.com>,
	"Desai, Kashyap" <Kashyap.Desai@....com>,
	"Prakash, Sathya" <Sathya.Prakash@....com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Matthew Wilcox <matthew@....cx>,
	linux scsi dev <linux-scsi@...r.kernel.org>,
	"paulus@...ba.org" <paulus@...ba.org>,
	linux powerpc dev <linuxppc-dev@...ts.ozlabs.org>,
	linux pci <linux-pci@...r.kernel.org>,
	linux kernel <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is
 not atomic

On Wed, 2011-05-18 at 21:16 -0700, Roland Dreier wrote:
> On Wed, May 18, 2011 at 11:31 AM, Milton Miller <miltonm@....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.

Cheers,
Ben.


--
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/