linux-kernel - Re: USB mass storage and ARM cache coherency

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:	Tue, 2 Feb 2010 13:24:02 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	Matthew Dharm <mdharm-kernel@...-eyed-alien.net>,
	Sergei Shtylyov <sshtylyov@...mvista.com>,
	Ming Lei <tom.leiming@...il.com>, linux-usb@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Sebastian Siewior <bigeasy@...utronix.de>,
	Greg KH <greg@...ah.com>
Subject: Re: USB mass storage and ARM cache coherency

On Mon, Feb 01, 2010 at 03:14:04PM -0500, Alan Stern wrote:
> On Mon, 1 Feb 2010, Catalin Marinas wrote:
> 
> > On Fri, 2010-01-29 at 18:54 +0000, Matthew Dharm wrote:
> > > HOWEVER, I firmly believe that the cache-management functions belong with
> > > the driver that actually talks to the low-level hardware, as that's the
> > > only place where you can be 100% certain of what cache operations are
> > > needed.  After all, I think someone is working on a USB-over-IP transport,
> > > and trying to manage cache at the usb-storage level in that scenario is
> > > just silly.
> > > 
> > > So, let's put this in the HCD drivers and be done with it.
> > 
> > The patch below is what fixes the I-D cache incoherency issues on ARM. I
> > don't particularly like the solution but it seems to be the only one
> > available.
> > 
> > IMHO, Linux should have functions similar to the DMA API but for PIO
> > drivers (e.g. pio_map_single/pio_unmap_single) that non-coherent
> > architectures can define, otherwise being no-ops. Any thoughts?
> 
> You should bring this up on the linux-arm-kernel mailing list and CC:  
> the ARM maintainer.  They are the ones most directly affected.
> 
No, this belongs on linux-arch, as it's something that impacts a lot of
people besides ARM.
--
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/