[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070103141655.GA25434@flint.arm.linux.org.uk>
Date: Wed, 3 Jan 2007 14:16:55 +0000
From: Russell King <rmk+lkml@....linux.org.uk>
To: David Miller <davem@...emloft.net>
Cc: James.Bottomley@...elEye.com, 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 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.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
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