linux-kernel - Re: [PATCH v4 0/4] Add lightweight memory barriers for coherent memory access

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: <CA+55aFwHUQv+zBxyN41Y4MDyRXbQ84H8zc01O6O_eg9ZvoqYiQ@mail.gmail.com>
Date:	Tue, 18 Nov 2014 15:06:49 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alexander Duyck <alexander.h.duyck@...hat.com>
Cc:	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Peter Zijlstra <peterz@...radead.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Ingo Molnar <mingo@...nel.org>,
	Michael Neuling <mikey@...ling.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	donald.c.skidmore@...el.com, matthew.vick@...el.com,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Francois Romieu <romieu@...zoreil.com>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	nic_swsd@...ltek.com, Will Deacon <will.deacon@....com>,
	Michael Ellerman <michael@...erman.id.au>,
	Tony Luck <tony.luck@...el.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH v4 0/4] Add lightweight memory barriers for coherent
 memory access

On Tue, Nov 18, 2014 at 2:47 PM, Alexander Duyck
<alexander.h.duyck@...hat.com> wrote:
>
> The problem is DMA is a broad brush.  There are multiple cases I can think
> of where DMA does not represent coherent memory.

.. and I already addressed that, in the thing you even included:

>> about what is actually the important issue. All sane memory is
>> coherent, after all (and if it isn't, you have other issues than
>> memory ordering).

The thing is, if the DMA isn't coherent, nobody is going to care about
the memory barriers anyway. You have bigger issues.

And your argument is that "dma" is bigger than this issue. *MY*
argument is that "coherent" is bigger than this issue. There's tons of
coherent memory that is not about DMA, the same way that there is DMA
memory that isn't coherent.

See? The two are 100% equivalent. Except "dma" is just three letters,
and matches "smp" both visually and in use (SMP memory is "coherent"
too - yes, you can - and crap architectures do - have incoherent
caches due to virtual aliases etc, but exactly as with DMA, if you
have incoherent SMP, you have bigger issues than the barriers).

And yes, you could call it "coherent_dma_read_memory_barrier()", and
it would be very descriptive. It would also drive everybody crazy.

So I argue for "dma_mb()" pairing with "smp_mb()" from a naming
standpoint. It just *describes* the problem better. Look at the
drivers, it's very much about the devices doing DMA to memory, and our
ordering.

To be even more clear: nobody sane cares about the "coherent" part,
because only insane horrible crap architectures have incoherent memory
in the first place, and sane people run away screaming from that
steaming pile of sh*t.

Just look at some of the drivers you actually *use* this in. They are
for intel hardware, they presumably would never even work in the first
place without cache-coherent DMA. Why do you think that "coherent" is
so important?

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