linux-kernel - Re: [PATCH 1/3 v3] dma: document dma_{un}map_{single|sg}

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: <200802291911.33646.jbarnes@virtuousgeek.org>
Date:	Fri, 29 Feb 2008 19:11:32 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	benh@...nel.crashing.org
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	Grant Grundler <grundler@...isc-linux.org>,
	Michael Ellerman <michael@...erman.id.au>, akepner@....com,
	Tony Luck <tony.luck@...el.com>, Jes Sorensen <jes@....com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Roland Dreier <rdreier@...co.com>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3 v3] dma: document dma_{un}map_{single|sg}_attrs() interface

On Friday, February 29, 2008 6:56 pm Benjamin Herrenschmidt wrote:
> On Fri, 2008-02-29 at 12:37 -0600, James Bottomley wrote:
> > To be honest, I still don't like the name.  SYNC_ON_WRITE is the SN2
> > implementation.  What it's actually doing is implementing strict
> > ordering semantics.  I think it should really be
> > DMA_ATTR_STRICT_ORDERING (with a corresponding
> > DMA_ATTR_RELAXED_ORDERING).
> >
> > This means that if ever anyone sets a PCIe bridge to relaxed ordering
> > by
> > default, this attribute will also work for them.
>
> But that would be asking for trouble no ? I would expect pretty much
> everything to break appart with relaxed by default no ? Or I don't fully
> understand what your arch calls "relaxed"...

Depends on how the device completes commands and what the driver does to check 
for completion.  It would probably work fine in many cases.

> I do agree that we should aim for simple semantics, they should cover
> 99% of the needs, and leave some bit space or attribute space for archs
> to define private ones when really needed.
>
> In our case, I suspect that the two main thing we could define here for
> DMA that would be useful generally would be relaxed ordering (strict
> being the default) and maybe read prefetching (though that would be the
> default, maybe no prefetch). We -might- have use of separating relaxed
> ordering for read vs. writes, but that's pretty much it.

Sounds about right.  I've got to poke the PCIe 3.0 folks again about some of 
the potential ordering changes there; hopefully we can cover that stuff too 
with Arthur's approach.

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