user/sven/linux.git/fs/fuse, branch v3.0.76

fuse: fix retrieve length

2012-09-14T17:00:50Z

commit c9e67d483776d8d2a5f3f70491161b205930ffe1 upstream. In some cases fuse_retrieve() would return a short byte count if offset was non-zero. The data returned was correct, though. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

fuse: verify all ioctl retry iov elements

2012-08-26T22:12:11Z

commit fb6ccff667712c46b4501b920ea73a326e49626a upstream. Commit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 attempted to verify that the total iovec from the client doesn't overflow iov_length() but it only checked the first element. The iovec could still overflow by starting with a small element. The obvious fix is to check all the elements. The overflow case doesn't look dangerous to the kernel as the copy is limited by the length after the overflow. This fix restores the intention of returning an error instead of successfully copying less than the iovec represented. I found this by code inspection. I built it but don't have a test case. I'm cc:ing stable because the initial commit did as well. Signed-off-by: Zach Brown Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

fuse: fix stat call on 32 bit platforms

2012-06-17T18:23:12Z

commit 45c72cd73c788dd18c8113d4a404d6b4a01decf1 upstream. Now we store attr->ino at inode->i_ino, return attr->ino at the first time and then return inode->i_ino if the attribute timeout isn't expired. That's wrong on 32 bit platforms because attr->ino is 64 bit and inode->i_ino is 32 bit in this case. Fix this by saving 64 bit ino in fuse_inode structure and returning it every time we call getattr. Also squash attr->ino into inode->i_ino explicitly. Signed-off-by: Pavel Shilovsky Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

fuse: fix fuse_retrieve

2011-12-21T20:57:44Z

commit 48706d0a91583d08c56e7ef2a7602d99c8d4133f upstream. Fix two bugs in fuse_retrieve(): - retrieving more than one page would yield repeated instances of the first page - if more than FUSE_MAX_PAGES_PER_REQ pages were requested than the request page array would overflow fuse_retrieve() was added in 2.6.36 and these bugs had been there since the beginning. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

fuse: fix memory leak

2011-10-25T05:10:14Z

commit 5dfcc87fd79dfb96ed155b524337dbd0da4f5993 upstream. kmemleak is reporting that 32 bytes are being leaked by FUSE: unreferenced object 0xe373b270 (size 32): comm "fusermount", pid 1207, jiffies 4294707026 (age 2675.187s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemleak_alloc+0x27/0x50 [] kmem_cache_alloc+0xc5/0x180 [] fuse_alloc_forget+0x1e/0x20 [] fuse_alloc_inode+0xb0/0xd0 [] alloc_inode+0x1c/0x80 [] iget5_locked+0x8f/0x1a0 [] fuse_iget+0x72/0x1a0 [] fuse_get_root_inode+0x8a/0x90 [] fuse_fill_super+0x3ef/0x590 [] mount_nodev+0x3f/0x90 [] fuse_mount+0x15/0x20 [] mount_fs+0x1c/0xc0 [] vfs_kern_mount+0x41/0x90 [] do_kern_mount+0x39/0xd0 [] do_mount+0x2e5/0x660 [] sys_mount+0x66/0xa0 This leak report is consistent and happens once per boot on 3.1.0-rc5-dirty. This happens if a FORGET request is queued after the fuse device was released. Reported-by: Sitsofe Wheeler Signed-off-by: Miklos Szeredi Tested-by: Sitsofe Wheeler Signed-off-by: Linus Torvalds Cc: Josh Boyer Signed-off-by: Greg Kroah-Hartman

fuse: check size of FUSE_NOTIFY_INVAL_ENTRY message

2011-08-29T20:29:15Z

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

more conservative S_NOSEC handling

2011-06-03T22:24:58Z

Caching "we have already removed suid/caps" was overenthusiastic as merged. On network filesystems we might have had suid/caps set on another client, silently picked by this client on revalidate, all of that *without* clearing the S_NOSEC flag. AFAICS, the only reasonably sane way to deal with that is * new superblock flag; unless set, S_NOSEC is not going to be set. * local block filesystems set it in their ->mount() (more accurately, mount_bdev() does, so does btrfs ->mount(), users of mount_bdev() other than local block ones clear it) * if any network filesystem (or a cluster one) wants to use S_NOSEC, it'll need to set MS_NOSEC in sb->s_flags *AND* take care to clear S_NOSEC when inode attribute changes are picked from other clients. It's not an earth-shattering hole (anybody that can set suid on another client will almost certainly be able to write to the file before doing that anyway), but it's a bug that needs fixing. Signed-off-by: Al Viro

fuse: remove unnecessary dentry_unhash on rmdir, dir rename

2011-05-28T05:02:53Z

Fuse has no problems with references to unlinked directories. CC: Miklos Szeredi CC: fuse-devel@lists.sourceforge.net Signed-off-by: Sage Weil Signed-off-by: Al Viro

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6

2011-05-26T16:52:14Z

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6: (25 commits) cifs: remove unnecessary dentry_unhash on rmdir/rename_dir ocfs2: remove unnecessary dentry_unhash on rmdir/rename_dir exofs: remove unnecessary dentry_unhash on rmdir/rename_dir nfs: remove unnecessary dentry_unhash on rmdir/rename_dir ext2: remove unnecessary dentry_unhash on rmdir/rename_dir ext3: remove unnecessary dentry_unhash on rmdir/rename_dir ext4: remove unnecessary dentry_unhash on rmdir/rename_dir btrfs: remove unnecessary dentry_unhash in rmdir/rename_dir ceph: remove unnecessary dentry_unhash calls vfs: clean up vfs_rename_other vfs: clean up vfs_rename_dir vfs: clean up vfs_rmdir vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems libfs: drop unneeded dentry_unhash vfs: update dentry_unhash() comment vfs: push dentry_unhash on rename_dir into file systems vfs: push dentry_unhash on rmdir into file systems vfs: remove dget() from dentry_unhash() vfs: dentry_unhash immediately prior to rmdir vfs: Block mmapped writes while the fs is frozen ...

vfs: push dentry_unhash on rename_dir into file systems

2011-05-26T11:26:48Z

Only a few file systems need this. Start by pushing it down into each rename method (except gfs2 and xfs) so that it can be dealt with on a per-fs basis. Acked-by: Christoph Hellwig Signed-off-by: Sage Weil Signed-off-by: Al Viro