linux-stable.git/fs/fuse, branch linux-2.6.33.y

fuse: check size of FUSE_NOTIFY_INVAL_ENTRY message

2011-08-29T21:33:03+00:00

commit c2183d1e9b3f313dd8ba2b1b0197c8d9fb86a7ae upstream.

FUSE_NOTIFY_INVAL_ENTRY didn't check the length of the write so the
message processing could overrun and result in a "kernel BUG at
fs/fuse/dev.c:629!"

Reported-by: Han-Wen Nienhuys 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse: fix hang of single threaded fuseblk filesystem

2011-03-21T19:45:24+00:00

commit 5a18ec176c934ca1bc9dc61580a5e0e90a9b5733 upstream.

Single threaded NTFS-3G could get stuck if a delayed RELEASE reply
triggered a DESTROY request via path_put().

Fix this by

 a) making RELEASE requests synchronous, whenever possible, on fuseblk
 filesystems

 b) if not possible (triggered by an asynchronous read/write) then do
 the path_put() in a separate thread with schedule_work().

Reported-by: Oliver Neukum 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse: fix ioctl when server is 32bit

2011-03-21T19:44:19+00:00

commit d9d318d39dd5cb686660504a3565aac453709ccc upstream.

If a 32bit CUSE server is run on 64bit this results in EIO being
returned to the caller.

The reason is that FUSE_IOCTL_RETRY reply was defined to use 'struct
iovec', which is different on 32bit and 64bit archs.

Work around this by looking at the size of the reply to determine
which struct was used.  This is only needed if CONFIG_COMPAT is
defined.

A more permanent fix for the interface will be to use the same struct
on both 32bit and 64bit.

Reported-by: "ccmail111" 
Signed-off-by: Miklos Szeredi 
CC: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

fuse: verify ioctl retries

2011-03-21T19:44:19+00:00

commit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 upstream.

Verify that the total length of the iovec returned in FUSE_IOCTL_RETRY
doesn't overflow iov_length().

Signed-off-by: Miklos Szeredi 
CC: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

fuse: fix attributes after open(O_TRUNC)

2011-03-21T19:44:06+00:00

commit a0822c55779d9319939eac69f00bb729ea9d23da upstream.

The attribute cache for a file was not being cleared when a file is opened
with O_TRUNC.

If the filesystem's open operation truncates the file ("atomic_o_trunc"
feature flag is set) then the kernel should invalidate the cached st_mtime
and st_ctime attributes.

Also i_size should be explicitly be set to zero as it is used sometimes
without refreshing the cache.

Signed-off-by: Ken Sumrall 
Cc: Anfei 
Cc: "Anand V. Avati" 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm: flush dcache before writing into page to avoid alias

2010-02-03T02:11:21+00:00

The cache alias problem will happen if the changes of user shared mapping
is not flushed before copying, then user and kernel mapping may be mapped
into two different cache line, it is impossible to guarantee the coherence
after iov_iter_copy_from_user_atomic.  So the right steps should be:

	flush_dcache_page(page);
	kmap_atomic(page);
	write to page;
	kunmap_atomic(page);
	flush_dcache_page(page);

More precisely, we might create two new APIs flush_dcache_user_page and
flush_dcache_kern_page to replace the two flush_dcache_page accordingly.

Here is a snippet tested on omap2430 with VIPT cache, and I think it is
not ARM-specific:

	int val = 0x11111111;
	fd = open("abc", O_RDWR);
	addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
	*(addr+0) = 0x44444444;
	tmp = *(addr+0);
	*(addr+1) = 0x77777777;
	write(fd, &val, sizeof(int));
	close(fd);

The results are not always 0x11111111 0x77777777 at the beginning as expected.  Sometimes we see 0x44444444 0x77777777.

Signed-off-by: Anfei 
Cc: Russell King 
Cc: Miklos Szeredi 
Cc: Nick Piggin 
Cc: 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fuse: reject O_DIRECT flag also in fuse_create

2009-11-27T15:37:13+00:00

The comment in fuse_open about O_DIRECT:

  "VFS checks this, but only _after_ ->open()"

also holds for fuse_create, however, the same kind of check was missing there.

As an impact of this bug, open(newfile, O_RDWR|O_CREAT|O_DIRECT) fails, but a
stub newfile will remain if the fuse server handled the implied FUSE_CREATE
request appropriately.

Other impact: in the above situation ima_file_free() will complain to open/free
imbalance if CONFIG_IMA is set.

Signed-off-by: Csaba Henk 
Signed-off-by: Miklos Szeredi 
Cc: Harshavardhana 
Cc: stable@kernel.org

fuse: invalidate target of rename

2009-11-04T09:24:52+00:00

Invalidate the target's attributes, which may have changed (such as
nlink, change time) so that they are refreshed on the next getattr().

Signed-off-by: Miklos Szeredi

fuse: fix kunmap in fuse_ioctl_copy_user

2009-11-04T09:24:51+00:00

Looks like another victim of the confusing kmap() vs kmap_atomic() API
differences.

Reported-by: Todor Gyumyushev 
Signed-off-by: Jens Axboe 
Signed-off-by: Miklos Szeredi 
Cc: Tejun Heo 
Cc: stable@kernel.org

fuse: prevent fuse_put_request on invalid pointer

2009-11-04T09:24:50+00:00

fuse_direct_io() has a loop where requests are allocated in each
iteration. if allocation fails, the loop is broken out and follows
into an unconditional fuse_put_request() on that invalid pointer.

Signed-off-by: Anand V. Avati 
Signed-off-by: Miklos Szeredi 
Cc: stable@kernel.org