mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: David Miller <davem@davemloft.net>,
	miklos@szeredi.hu, arjan@infradead.org, torvalds@osdl.org,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	akpm@osdl.org
Subject: Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
Date: Wed, 03 Jan 2007 09:00:58 -0600	[thread overview]
Message-ID: <1167836458.2789.6.camel@mulgrave.il.steeleye.com> (raw)
In-Reply-To: <20070103141655.GA25434@flint.arm.linux.org.uk>

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@SteelEye.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



  reply	other threads:[~2007-01-03 15:01 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-21 15:26 Russell King
2006-12-21 15:53 ` Miklos Szeredi
2006-12-21 16:57   ` Russell King
2006-12-21 17:51     ` Miklos Szeredi
2006-12-21 21:04       ` Jan Engelhardt
2006-12-21 21:30         ` Miklos Szeredi
2007-01-01 15:04     ` James Bottomley
2006-12-21 17:17   ` Russell King
2006-12-21 17:55     ` Miklos Szeredi
2006-12-21 18:11       ` Russell King
2006-12-21 18:30         ` Miklos Szeredi
2006-12-21 18:55           ` Russell King
2006-12-21 19:05             ` Miklos Szeredi
2006-12-21 23:51               ` Randolph Chung
2006-12-22  8:43                 ` Russell King
2006-12-22 14:45                   ` Randolph Chung
2006-12-30 16:39     ` Russell King
2006-12-30 16:50       ` Russell King
2006-12-30 18:26         ` Linus Torvalds
2006-12-30 22:46           ` Russell King
2006-12-31  5:23             ` David Miller
2006-12-31  9:10               ` Miklos Szeredi
2006-12-31  9:45                 ` David Miller
2006-12-31  9:23               ` Russell King
2006-12-31  9:27                 ` Arjan van de Ven
2006-12-31  9:47                   ` David Miller
2006-12-31 10:00                     ` Russell King
2006-12-31 10:04                       ` David Miller
2006-12-31 12:24                       ` Miklos Szeredi
2006-12-31 17:37                         ` Russell King
2007-01-01 22:15                           ` Miklos Szeredi
2007-01-01 23:45                             ` Russell King
2007-01-02 19:40                               ` Dan Williams
2007-01-02 22:53                               ` James Bottomley
2007-01-02 23:19                                 ` David Miller
2007-01-02 23:34                                   ` James Bottomley
2007-01-03  0:20                                     ` David Miller
2007-01-03 14:16                                       ` Russell King
2007-01-03 15:00                                         ` James Bottomley [this message]
2007-01-03 15:09                                           ` Russell King
2007-01-07 16:09                                             ` James Bottomley
2007-01-07 16:30                                               ` Russell King
2006-12-31 20:40                         ` David Miller
2006-12-31 20:58                           ` Linus Torvalds
2006-12-31 21:12                             ` David Miller
2007-01-01 16:44                               ` James Bottomley
2007-01-01 23:04                                 ` David Miller
2007-01-01 23:23                                   ` James Bottomley
     [not found]                     ` <1167669252.5302.57.camel@mulgrave.il.steeleye.com>
2007-01-01 23:01                       ` David Miller
2007-01-01 23:17                         ` Russell King
2006-12-31  9:55                   ` Russell King
2006-12-31  9:46                 ` David Miller
2007-01-01 14:35           ` James Bottomley
2007-01-01 16:21             ` Russell King
2006-12-30 18:21       ` Linus Torvalds
2006-12-21 16:29 ` Arjan van de Ven
2006-12-21 17:35   ` Russell King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1167836458.2789.6.camel@mulgrave.il.steeleye.com \
    --to=james.bottomley@steeleye.com \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=davem@davemloft.net \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®