linux-kernel - Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again

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, 03 Jan 2007 09:00:58 -0600
From:	James Bottomley <James.Bottomley@...elEye.com>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	David Miller <davem@...emloft.net>, miklos@...redi.hu,
	arjan@...radead.org, torvalds@...l.org,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	akpm@...l.org
Subject: Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all
	that again

On Wed, 2007-01-03 at 14:16 +0000, Russell King wrote:
> On Tue, Jan 02, 2007 at 04:20:58PM -0800, David Miller wrote:
> > From: James Bottomley <James.Bottomley@...elEye.com>
> > Date: Tue, 02 Jan 2007 17:34:18 -0600
> > 
> > > Erm ... for a device driver, if we're preparing to do I/O on the page
> > > something must have made the user caches coherent ... that can't be
> > > kmap, because the driver might elect to DMA on the page ... unless
> > > another component of this API is going to be to make dma_map_... also
> > > flush the user cache?
> > 
> > The DMA map/unmap/sync performs the necessary cache flushes.
> 
> Even on ARM, we doesn't do that - we rely on flush_dcache_page() to catch
> those where necessary.
> 
> The locking to walk the shared VMA list is already rather disgusting.
> Trying to do that in IRQ context is not going to be fun.  The locking
> to walk the anon_vma list is not public outside of mm/rmap.c - in my
> ARM flushing-anonymous-caches v2 patch I'm duplicating a couple of
> functions from mm/rmap.c (page_lock_anon_vma() and vma_address()) to
> be able to sanely walk the anonymous vma list.
> 
> I'd rather avoid fiddling around in VMA lists from within the DMA API;
> the DMA API implementation is already fairly complex on ARM what with
> this silly DMA bounce buffer implementation (which exists because the
> Linux VM is unable to properly honor dma_masks).  (Incidentally, I
> don't like this, but because of that problem it's required to get
> various ARM platforms working.)

Yes, this mirrors my concern on parisc too.  We had awful problems with
the locking in flush_dcache_page() as well.

However, I was wondering if there might be a different way around this.
We can't really walk all the user mappings because of the locks, but
could we store the user flush hints in the page (or a related
structure)?  On parisc we don't care about the process id (called space
in our architecture) because we've turned off the pieces of the cache
that match on space id.  Thus, all we care about is flushing with the
physical address and virtual address (and only about 10 bits of this are
significant for matching).  We go to great lengths to ensure that every
mapping in user space all has the same 10 bits of virtual address, so if
we just new what they were we could flush the whole of the user spaces
for the page without having to walk any VMA lists.  Could arm do this as
well?

James


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/