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: <4505DB10.7080807@pobox.com>
Date:	Mon, 11 Sep 2006 17:54:24 -0400
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
CC:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Paul Mackerras <paulus@...ba.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>,
	Segher Boessenkool <segher@...nel.crashing.org>
Subject: Re: [RFC] MMIO accessors & barriers documentation

Benjamin Herrenschmidt wrote:
> Ah ? What about the comment in e1000 saying that it needs a wmb()
> between descriptor updates in memory and the mmio to kick them ? That
> would typically be a memory_to_io_wb(). Or are your MMIOs ordered cs.
> your cacheable stores ?

That's likely just following existing practice found in many network 
drivers.  The following two design patterns have been copied across a 
great many network drivers:

1) When in a loop, reading through a DMA ring, put an "rmb()" at the top 
of the loop, to ensure that the compiler does not optimize out all 
memory loads after the first.

2) Use "wmb()" to ensure that just-written-to memory is visible to a PCI 
device that will be reading said memory region via DMA.

I don't claim that either of these is correct, just that's existing 
practice, perhaps in some case perpetuated by my own arch ignorance.

So, in a perfect world where I was designing my own API, I would create 
two new API functions:

prepare_to_read_dma_memory()
	and
make_memory_writes_visible_to_dmaing_devices()

and leave the existing APIs untouched.  Those are the two fundamental 
operations that are needed.

	Jeff


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ