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 <[EMAIL PROTECTED]> [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
