BMC/Intel-BMC/linux.git/fs, branch v4.4.22

fuse: direct-io: don't dirty ITER_BVEC pages

2016-09-24T08:07:41+00:00

commit 8fba54aebbdf1f999738121922e74bf796ad60ee upstream. When reading from a loop device backed by a fuse file it deadlocks on lock_page(). This is because the page is already locked by the read() operation done on the loop device. In this case we don't want to either lock the page or dirty it. So do what fs/direct-io.c does: only dirty the page for ITER_IOVEC vectors. Reported-by: Sheng Yang Fixes: aa4d86163e4e ("block: loop: switch to VFS ITER_BVEC") Signed-off-by: Miklos Szeredi Reviewed-by: Sheng Yang Reviewed-by: Ashish Samant Tested-by: Sheng Yang Tested-by: Ashish Samant Signed-off-by: Greg Kroah-Hartman

Btrfs: remove root_log_ctx from ctx list before btrfs_sync_log returns

2016-09-24T08:07:41+00:00

commit cbd60aa7cd17d81a434234268c55192862147439 upstream. We use a btrfs_log_ctx structure to pass information into the tree log commit, and get error values out. It gets added to a per log-transaction list which we walk when things go bad. Commit d1433debe added an optimization to skip waiting for the log commit, but didn't take root_log_ctx out of the list. This patch makes sure we remove things before exiting. Signed-off-by: Chris Mason Fixes: d1433debe7f4346cf9fc0dafc71c3137d2a97bc4 Signed-off-by: Greg Kroah-Hartman

mm: introduce get_task_exe_file

2016-09-24T08:07:36+00:00

commit cd81a9170e69e018bbaba547c1fd85a585f5697a upstream. For more convenient access if one has a pointer to the task. As a minor nit take advantage of the fact that only task lock + rcu are needed to safely grab ->exe_file. This saves mm refcount dance. Use the helper in proc_exe_link. Signed-off-by: Mateusz Guzik Acked-by: Konstantin Khlebnikov Acked-by: Richard Guy Briggs Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman

NFSv4.1: Fix the CREATE_SESSION slot number accounting

2016-09-24T08:07:36+00:00

commit b519d408ea32040b1c7e10b155a3ee9a36660947 upstream. Ensure that we conform to the algorithm described in RFC5661, section 18.36.4 for when to bump the sequence id. In essence we do it for all cases except when the RPC call timed out, or in case of the server returning NFS4ERR_DELAY or NFS4ERR_STALE_CLIENTID. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman

pNFS: Ensure LAYOUTGET and LAYOUTRETURN are properly serialised

2016-09-24T08:07:36+00:00

commit bf0291dd2267a2b9a4cd74d65249553d11bb45d6 upstream. According to RFC5661, the client is responsible for serialising LAYOUTGET and LAYOUTRETURN to avoid ambiguity. Consider the case where we send both in parallel. Client Server ====== ====== LAYOUTGET(seqid=X) LAYOUTRETURN(seqid=X) LAYOUTGET return seqid=X+1 LAYOUTRETURN return seqid=X+2 Process LAYOUTRETURN Forget layout stateid Process LAYOUTGET Set seqid=X+1 The client processes the layoutget/layoutreturn in the wrong order, and since the result of the layoutreturn was to clear the only existing layout segment, the client forgets the layout stateid. When the LAYOUTGET comes in, it is treated as having a completely new stateid, and so the client sets the wrong sequence id... Fix is to check if there are outstanding LAYOUTGET requests before we send the LAYOUTRETURN (note that LAYOUGET will already wait if it sees an outstanding LAYOUTRETURN). Signed-off-by: Trond Myklebust Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman

nfsd: Close race between nfsd4_release_lockowner and nfsd4_lock

2016-09-24T08:07:36+00:00

commit 885848186fbc2d1d8fb6d2fdc2156638ae289a46 upstream. nfsd4_release_lockowner finds a lock owner that has no lock state, and drops cl_lock. Then release_lockowner picks up cl_lock and unhashes the lock owner. During the window where cl_lock is dropped, I don't see anything preventing a concurrent nfsd4_lock from finding that same lock owner and adding lock state to it. Move release_lockowner() into nfsd4_release_lockowner and hang onto the cl_lock until after the lock owner's state cannot be found again. Found by inspection, we don't currently have a reproducer. Fixes: 2c41beb0e5cf ("nfsd: reduce cl_lock thrashing in ... ") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

NFSv4.x: Fix a refcount leak in nfs_callback_up_net

2016-09-24T08:07:36+00:00

commit 98b0f80c2396224bbbed81792b526e6c72ba9efa upstream. On error, the callers expect us to return without bumping nn->cb_users[]. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman

pNFS: The client must not do I/O to the DS if it's lease has expired

2016-09-24T08:07:36+00:00

commit b88fa69eaa8649f11828158c7b65c4bcd886ebd5 upstream. Ensure that the client conforms to the normative behaviour described in RFC5661 Section 12.7.2: "If a client believes its lease has expired, it MUST NOT send I/O to the storage device until it has validated its lease." So ensure that we wait for the lease to be validated before using the layout. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman

kernfs: don't depend on d_find_any_alias() when generating notifications

2016-09-24T08:07:36+00:00

commit df6a58c5c5aa8ecb1e088ecead3fa33ae70181f1 upstream. kernfs_notify_workfn() sends out file modified events for the scheduled kernfs_nodes. Because the modifications aren't from userland, it doesn't have the matching file struct at hand and can't use fsnotify_modify(). Instead, it looked up the inode and then used d_find_any_alias() to find the dentry and used fsnotify_parent() and fsnotify() directly to generate notifications. The assumption was that the relevant dentries would have been pinned if there are listeners, which isn't true as inotify doesn't pin dentries at all and watching the parent doesn't pin the child dentries even for dnotify. This led to, for example, inotify watchers not getting notifications if the system is under memory pressure and the matching dentries got reclaimed. It can also be triggered through /proc/sys/vm/drop_caches or a remount attempt which involves shrinking dcache. fsnotify_parent() only uses the dentry to access the parent inode, which kernfs can do easily. Update kernfs_notify_workfn() so that it uses fsnotify() directly for both the parent and target inodes without going through d_find_any_alias(). While at it, supply the target file name to fsnotify() from kernfs_node->name. Signed-off-by: Tejun Heo Reported-by: Evgeny Vereshchagin Fixes: d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events too") Cc: John McCutchan Cc: Robert Love Cc: Eric Paris Signed-off-by: Greg Kroah-Hartman

fscrypto: require write access to mount to set encryption policy

2016-09-24T08:07:35+00:00

commit ba63f23d69a3a10e7e527a02702023da68ef8a6d upstream. Since setting an encryption policy requires writing metadata to the filesystem, it should be guarded by mnt_want_write/mnt_drop_write. Otherwise, a user could cause a write to a frozen or readonly filesystem. This was handled correctly by f2fs but not by ext4. Make fscrypt_process_policy() handle it rather than relying on the filesystem to get it right. Signed-off-by: Eric Biggers Cc: stable@vger.kernel.org # 4.1+; check fs/{ext4,f2fs} Signed-off-by: Theodore Ts'o Acked-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman