All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	Andrew Morton <akpm@osdl.org>
Subject: Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
Date: Sat, 30 Dec 2006 22:46:04 +0000	[thread overview]
Message-ID: <20061230224604.GA3350@flint.arm.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.64.0612301022200.4473@woody.osdl.org>

On Sat, Dec 30, 2006 at 10:26:20AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 30 Dec 2006, Russell King wrote:
> > 
> > And here's the flush_anon_page() part.
> > 
> > Add flush_anon_page() for ARM, to avoid data corruption issues when using
> > fuse or other subsystems using get_user_pages().
> 
> Btw, since this doesn't actually change any code for anybody but ARM, just 
> adds a parameter that is obviously unused by everybody else, and if it 
> actually fixes a real bug for ARM, I'll obviously happily take it even 
> before 2.6.20. So go ahead put it in your ARM tree, and we'll get some 
> testing through that. And just ask me to pull at some point.
> 
> I wonder why nobody else seems to have a "flush_anon_page()"? This would 
> seem to be a potential issue for architectures like sparc too.. Although 
> maybe sparc can do a flush by physical index with "flush_dcache_page()".

Well...

iirc, flush_anon_page() was introduced to fix non-working fuse on parisc,
which occurs because fuse wants to use get_user_pages() to read data from
the current processes memory space.

get_user_pages() contains a call to flush_dcache_page(), whose behaviour
is defined for shared mappings.  Anonymous pages are unspecified.  It
appears that flush_anon_page() was introduced to correct this oversight.

Looking at some of the other users of get_user_pages() which want to
access the current processes memory space, one finds the following:

some use flush_cache_page():
- binfmt_elf coredump
- ptrace (in arch code)

others don't:
- aio
- bio
- block (block_dev::blk_get_page seems to be for direct-io, there's problems
   reported with this on ARM)
- direct-io
- fuse
- vmsplice

So, anything except coredumps and ptrace are currently unsafe on ARM
without something being added to get_user_pages() to ensure coherency
of anonymous pages.

Given that we have reported corruption with direct-io, and debian bug
#402876 for nonworking fuse, it seems the correct thing to do is to
implement this function.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

  reply	other threads:[~2006-12-30 22:46 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-21 15:26 fuse, get_user_pages, flush_anon_page, aliasing caches and all that again 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 [this message]
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
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=20061230224604.GA3350@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=akpm@osdl.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.