linux/fs, branch v3.15.7

aio: protect reqs_available updates from changes in interrupt handlers

2014-07-28T15:08:28Z

commit 263782c1c95bbddbb022dc092fd89a36bb8d5577 upstream. As of commit f8567a3845ac05bb28f3c1b478ef752762bd39ef it is now possible to have put_reqs_available() called from irq context. While put_reqs_available() is per cpu, it did not protect itself from interrupts on the same CPU. This lead to aio_complete() corrupting the available io requests count when run under a heavy O_DIRECT workloads as reported by Robert Elliott. Fix this by disabling irq updates around the per cpu batch updates of reqs_available. Many thanks to Robert and folks for testing and tracking this down. Reported-by: Robert Elliot Tested-by: Robert Elliot Signed-off-by: Benjamin LaHaise Cc: Jens Axboe , Christoph Hellwig Signed-off-by: Greg Kroah-Hartman

quota: missing lock in dqcache_shrink_scan()

2014-07-28T15:08:21Z

commit d68aab6b8f572406aa93b45ef6483934dd3b54a6 upstream. Commit 1ab6c4997e04 (fs: convert fs shrinkers to new scan/count API) accidentally removed locking from quota shrinker. Fix it - dqcache_shrink_scan() should use dq_list_lock to protect the scan on free_dquots list. Fixes: 1ab6c4997e04a00c50c6d786c2f046adc0d1f5de Signed-off-by: Niu Yawei Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman

fuse: ignore entry-timeout on LOOKUP_REVAL

2014-07-28T15:08:20Z

commit 154210ccb3a871e631bf39fdeb7a8731d98af87b upstream. The following test case demonstrates the bug: sh# mount -t glusterfs localhost:meta-test /mnt/one sh# mount -t glusterfs localhost:meta-test /mnt/two sh# echo stuff > /mnt/one/file; rm -f /mnt/two/file; echo stuff > /mnt/one/file bash: /mnt/one/file: Stale file handle sh# echo stuff > /mnt/one/file; rm -f /mnt/two/file; sleep 1; echo stuff > /mnt/one/file On the second open() on /mnt/one, FUSE would have used the old nodeid (file handle) trying to re-open it. Gluster is returning -ESTALE. The ESTALE propagates back to namei.c:filename_lookup() where lookup is re-attempted with LOOKUP_REVAL. The right behavior now, would be for FUSE to ignore the entry-timeout and and do the up-call revalidation. Instead FUSE is ignoring LOOKUP_REVAL, succeeding the revalidation (because entry-timeout has not passed), and open() is again retried on the old file handle and finally the ESTALE is going back to the application. Fix: if revalidation is happening with LOOKUP_REVAL, then ignore entry-timeout and always do the up-call. Signed-off-by: Anand Avati Reviewed-by: Niels de Vos Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

fuse: handle large user and group ID

2014-07-28T15:08:20Z

commit 233a01fa9c4c7c41238537e8db8434667ff28a2f upstream. If the number in "user_id=N" or "group_id=N" mount options was larger than INT_MAX then fuse returned EINVAL. Fix this to handle all valid uid/gid values. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

fuse: avoid scheduling while atomic

2014-07-28T15:08:20Z

commit c55a01d360afafcd52bc405c044a6ebf5de436d5 upstream. As reported by Richard Sharpe, an attempt to use fuse_notify_inval_entry() triggers complains about scheduling while atomic: BUG: scheduling while atomic: fuse.hf/13976/0x10000001 This happens because fuse_notify_inval_entry() attempts to allocate memory with GFP_KERNEL, holding "struct fuse_copy_state" mapped by kmap_atomic(). Introduced by commit 58bda1da4b3c "fuse/dev: use atomic maps" Fix by moving the map/unmap to just cover the actual memcpy operation. Original patch from Maxim Patlasov Reported-by: Richard Sharpe Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

fuse: timeout comparison fix

2014-07-28T15:08:20Z

commit 126b9d4365b110c157bc4cbc32540dfa66c9c85a upstream. As suggested by checkpatch.pl, use time_before64() instead of direct comparison of jiffies64 values. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

f2fs: check bdi->dirty_exceeded when trying to skip data writes

2014-07-17T23:23:19Z

commit 2743f865543c0c4a5e12fc13edb2bf89a6e9687c upstream. If we don't check the current backing device status, balance_dirty_pages can fall into infinite pausing routine. This can be occurred when a lot of directories make a small number of dirty dentry pages including files. Reported-by: Brian Chadwick Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman

f2fs: adjust free mem size to flush dentry blocks

2014-07-17T23:23:19Z

commit 6fb03f3a40805a412c9b285010ffdc2e7563f81b upstream. If so many dirty dentry blocks are cached, not reached to the flush condition, we should fall into livelock in balance_dirty_pages. So, let's consider the mem size for the condition. Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman

kernfs: introduce kernfs_pin_sb()

2014-07-17T23:23:19Z

commit 4e26445faad366d67d7723622bf6a60a6f0f5993 upstream. kernfs_pin_sb() tries to get a refcnt of the superblock. This will be used by cgroupfs. v2: - make kernfs_pin_sb() return the superblock. - drop kernfs_drop_sb(). tj: Updated the comment a bit. [ This is a prerequisite for a bugfix. ] Acked-by: Greg Kroah-Hartman Signed-off-by: Li Zefan Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman

kernfs: implement kernfs_root->supers list

2014-07-17T23:23:19Z

commit 7d568a8383bbb9c1f5167781075906acb2bb1550 upstream. Currently, there's no way to find out which super_blocks are associated with a given kernfs_root. Let's implement it - the planned inotify extension to kernfs_notify() needs it. Make kernfs_super_info point back to the super_block and chain it at kernfs_root->supers. Signed-off-by: Tejun Heo [lizf: Backported to 3.15: Adjust context] Signed-off-by: Li Zefan Signed-off-by: Greg Kroah-Hartman