linux-kernel - Re: [PATCH 2/3] dma: override "dma_flags_set

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]

Date:	Wed, 22 Aug 2007 10:17:11 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	Jes Sorensen <jes@....com>, akepner@....com,
	Randy Dunlap <randy.dunlap@...cle.com>,
	linux-kernel <linux-kernel@...r.kernel.org>, rdreier@...co.com,
	linux-ia64 <linux-ia64@...r.kernel.org>
Subject: Re: [PATCH 2/3] dma: override "dma_flags_set_dmaflush" for sn-ia64

On Wednesday, August 22, 2007 10:04:32 am James Bottomley wrote:
> The spec isn't ambiguous ... it says if the device and bridge agree on
> relaxed ordering, then it *may* be observed in the transaction.  If
> there's a disagreement or neither wishes to support relaxed ordering
> then the transaction *must* be strict.

Arg, don't make me dig out my spec, I don't have it handy...

> I really don't think a work around for a PCI spec violation belongs in
> the generic DMA code, do you?  The correct fix for this should be to set
> the device hints to strict ordering, which presumably altix respects?

Well, the Altix hw by itself won't honor device hints (I'm not even sure if 
there are devices that honor order hints like you outline above).  However, 
Altix could track per-device ordering as long as arch code was called from 
such a hook.

> In which case, it sounds like what needs exposing are access to the PCI
> device hints.  I believe both PCI-X and PCIe have these hints as
> optional specifiers in the bridges, so it should be in a current Rev of
> the PCI spec.  Or are you proposing adding an additional PCI API that
> allows transaction flushes to be inserted into the stream for devices
> and bridges that have already negotiated relaxed ordering? ... in which
> case we need to take this to the PCI list.

I think it would have to be the latter, since otherwise it would be hard to 
setup just completion queue requests to be ordered.

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/