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: <1195593015.17601.10.camel@localhost.localdomain>
Date:	Tue, 20 Nov 2007 15:10:15 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Roland Dreier <rdreier@...co.com>
Cc:	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	rmk@....linux.org.uk
Subject: Re: SCSI breakage on non-cache coherent architectures


On Tue, 2007-11-20 at 12:05 -0800, Roland Dreier wrote:
> > Actually, we already established on IRC that the lasi700 driver doesn't
>  > need this, principally because the parisc architecture doesn't do an
>  > invalidate for DMA_FROM_DEVICE but a flush and invalidate
>  > (architecturally, if you read our manuals, even pdc is entitled to write
>  > back dirty lines, so it's not clear there's actually an invalidate
>  > instruction we can use).   This is also one possible temporary fix for
>  > the other architectures if we can't get a different method to work
>  > nicely.
> 
> I think doing a writeback and invalidate is a very fragile way to deal
> with DMA into the middle of a data structure.  It may work OK for now,
> but you have to make sure forever into the future that no codepath
> anywhere else ever touches the cacheline that you're DMAing into while
> the DMA is pending.  It just leaves a hidden trap that is too easy to
> step on, because the architectures that get pretty much all testing
> all have cache-coherent DMA.
> 
> Reviving my ancient __dma_buffer patch seems far preferable to me.

We're talking about trying to fix this for 2.4; which is already at
-rc3 ... Is an entire arch change for dma alignment really a merge
candidate at this stage?

James


-
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