linux-kernel - Re: [PATCH v2 01/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section

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: <7ff812ec9c1e2a8b734b90f7480752dfd74cb8ad.camel@kernel.crashing.org>
Date:   Mon, 15 Apr 2019 14:05:30 +1000
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Will Deacon <will.deacon@....com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        "Paul E. McKenney" <paulmck@...ux.ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Arnd Bergmann <arnd@...db.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrea Parri <andrea.parri@...rulasolutions.com>,
        Palmer Dabbelt <palmer@...ive.com>,
        Daniel Lustig <dlustig@...dia.com>,
        David Howells <dhowells@...hat.com>,
        Alan Stern <stern@...land.harvard.edu>,
        "Maciej W. Rozycki" <macro@...ux-mips.org>,
        Paul Burton <paul.burton@...s.com>,
        Ingo Molnar <mingo@...nel.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>, Tony Luck <tony.luck@...el.com>,
        Mikulas Patocka <mpatocka@...hat.com>,
        Akira Yokosawa <akiyks@...il.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Nicholas Piggin <npiggin@...il.com>
Subject: Re: [PATCH v2 01/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O
 BARRIER EFFECTS" section

On Fri, 2019-04-12 at 14:17 +0100, Will Deacon wrote:
> 
> +	   the same CPU thread to a particular device will arrive in program
> +	   order.
> +
> +	2. A writeX() by a CPU thread to the peripheral will first wait for the
> +	   completion of all prior writes to memory either issued by the thread
> +	   or issued while holding a spinlock that was subsequently taken by the
> +	   thread. This ensures that writes by the CPU to an outbound DMA
> +	   buffer allocated by dma_alloc_coherent() will be visible to a DMA
> +	   engine when the CPU writes to its MMIO control register to trigger
> +	   the transfer.

Not particularily trying to be annoying here but I find the above
rather hard to parse :) I know what you're getting at but I'm not sure
somebody who doesn't will understand.

One way would be to instead prefix the whole thing with a blurb along
the lines of:

	readX() and writeX() provide some ordering guarantees versus
        each other and other memory accesses that are described below. 
	Those guarantees apply to accesses performed either by the same
        logical thread of execution, or by different threads but while 
        holding the same lock (spinlock or mutex).

Then have as simpler description of each case. No ?

> +	3. A readX() by a CPU thread from the peripheral will complete before
> +	   any subsequent reads from memory by the same thread can begin. This
> +	   ensures that reads by the CPU from an incoming DMA buffer allocated
> +	   by dma_alloc_coherent() will not see stale data after reading from
> +	   the DMA engine's MMIO status register to establish that the DMA
> +	   transfer has completed.
> +
> +	4. A readX() by a CPU thread from the peripheral will complete before
> +	   any subsequent delay() loop can begin execution on the same thread.
> +	   This ensures that two MMIO register writes by the CPU to a peripheral
> +	   will arrive at least 1us apart if the first write is immediately read
> +	   back with readX() and udelay(1) is called prior to the second
> +	   writeX():
>  
>  		writel(42, DEVICE_REGISTER_0); // Arrives at the device...
>  		readl(DEVICE_REGISTER_0);
> @@ -2600,8 +2604,10 @@ guarantees:
>  	These will perform appropriately for the type of access they're actually
>  	doing, be it inX()/outX() or readX()/writeX().
>  
> -All of these accessors assume that the underlying peripheral is little-endian,
> -and will therefore perform byte-swapping operations on big-endian architectures.
> +With the exception of the string accessors (insX(), outsX(), readsX() and
> +writesX()), all of the above assume that the underlying peripheral is
> +little-endian and will therefore perform byte-swapping operations on big-endian
> +architectures.
>  
>  
>  ========================================