Bug#402876: [fuse-devel] FUSE not working on ARM? Hangs during stat64
On Thu, Dec 21, 2006 at 11:05:49AM +0100, Miklos Szeredi wrote:
> > On Thu, Dec 21, 2006 at 09:24:56AM +0100, Martin Michlmayr wrote:
> > > * Miklos Szeredi <miklos@szeredi.hu> [2006-12-20 19:37]:
> > > > > We at Debian received the following bug report saying that FUSE is not
> > > > > working on ARM. I've verified this on two ARM platforms (IXP4xx and
> > > > > IOP32x) and also checked that it's working fine on MIPS. The problem
> > > > > seems that it hangs in stat64.
> > > >
> > > > Can you please try the out-of-tree kernel module from the fuse-2.6.x
> > > > package (use 'configure --enable-kernel-module). That contains a
> > > > workaround for a bug in the ARM architecture code.
> > > >
> > > > If this fixes the problem for you, then I would advise you to remind
> > > > the ARM maintainer (Russel King) about this issue.
> > >
> > > The bug reporter confirms that it works with the modules from the
> > > fuse-2.6.1 package. Russell, have you addressed this problem recently
> > > or is this still an open issue? I've only tried 2.6.17 and 2.6.18 so
> > > far, nothing newer. If there's a fix available, I can put it in
> > > Debian's 2.6.18 package that will ship with our next release.
> >
> > This is the first I've heard of a problem.
> >
> > What _exactly_ is the problem and can you provide a test case or
> > instructions to reproduce it?
>
> This is the dcache aliasing issue in get_user_pages() for anonymous
> pages:
>
> http://lkml.org/lkml/2006/10/7/80
>
> The reason why this only shows with FUSE is that ptrace() does it's
> own redundant cache flushing, and other users of get_user_pages() like
> SCSI and NFS direct-IO probably get less exposure on ARM than FUSE.
>
> To reproduce, build a kernel with CONFIG_FUSE_FS, build the fuse
> package (http://downloads.sourceforge.net/fuse/fuse-2.6.1.tar.gz) and
> run one of the example filesystems.
This may be a silly question, but why is fuse attempting to use the
kernel mapping to read/write the current processes userspace?
Most normal device drivers use the user accessor functions in
asm/uaccess.h and this would entirely avoid the cache aliasing issues.
To get fuse to work on ARM, we would need to flush the dcache (at I
hasten to add 32 byte intervals) over the area you wish to read, both
for the kernel _and_ userspace mappings of that page. So, to read an
entire page this way, what you're looking at is:
- 128 flush instructions to flush the kernel mapping.
- 128 flush instructions to flush the user mapping.
- memcpy overhead.
whereas to use the standard uaccess functions, you're looking at just
the memcpy overhead.
Therefore, I suggest that James' flush_anon_page() stuff just papers over
what is actually a fuse bug - it should not be using get_user_pages()
to access the current processes memory space.
--
Russell King
Reply to: