linux-stable.git/fs, branch v4.20.2

ceph: don't update importing cap's mseq when handing cap export

2019-01-13T08:24:08+00:00

commit 3c1392d4c49962a31874af14ae9ff289cb2b3851 upstream.

Updating mseq makes client think importer mds has accepted all prior
cap messages and importer mds knows what caps client wants. Actually
some cap messages may have been dropped because of mseq mismatch.

If mseq is left untouched, importing cap's mds_wanted later will get
reset by cap import message.

Cc: stable@vger.kernel.org
Signed-off-by: "Yan, Zheng" 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Greg Kroah-Hartman

nfsd4: zero-length WRITE should succeed

2019-01-13T08:24:07+00:00

commit fdec6114ee1f0f43b1ad081ad8d46b23ba126d70 upstream.

Zero-length writes are legal; from 5661 section 18.32.3: "If the count
is zero, the WRITE will succeed and return a count of zero subject to
permissions checking".

This check is unnecessary and is causing zero-length reads to return
EINVAL.

Cc: stable@vger.kernel.org
Fixes: 3fd9557aec91 "NFSD: Refactor the generic write vector fill helper"
Cc: Chuck Lever 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

lockd: Show pid of lockd for remote locks

2019-01-13T08:24:06+00:00

commit b8eee0e90f9797b747113638bc75e739b192ad38 upstream.

Commit 9d5b86ac13c5 ("fs/locks: Remove fl_nspid and use fs-specific l_pid
for remote locks") specified that the l_pid returned for F_GETLK on a local
file that has a remote lock should be the pid of the lock manager process.
That commit, while updating other filesystems, failed to update lockd, such
that locks created by lockd had their fl_pid set to that of the remote
process holding the lock.  Fix that here to be the pid of lockd.

Also, fix the client case so that the returned lock pid is negative, which
indicates a remote lock on a remote file.

Fixes: 9d5b86ac13c5 ("fs/locks: Remove fl_nspid and use fs-specific...")
Cc: stable@vger.kernel.org

Signed-off-by: Benjamin Coddington 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

gfs2: Fix loop in gfs2_rbm_find

2019-01-13T08:24:06+00:00

commit 2d29f6b96d8f80322ed2dd895bca590491c38d34 upstream.

Fix the resource group wrap-around logic in gfs2_rbm_find that commit
e579ed4f44 broke.  The bug can lead to unnecessary repeated scanning of the
same bitmaps; there is a risk that future changes will turn this into an
endless loop.

Fixes: e579ed4f44 ("GFS2: Introduce rbm field bii")
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Bob Peterson 
Signed-off-by: Greg Kroah-Hartman

gfs2: Get rid of potential double-freeing in gfs2_create_inode

2019-01-13T08:24:06+00:00

commit 6ff9b09e00a441599f3aacdf577254455a048bc9 upstream.

In gfs2_create_inode, after setting and releasing the acl / default_acl, the
acl / default_acl pointers are not set to NULL as they should be.  In that
state, when the function reaches label fail_free_acls, gfs2_create_inode will
try to release the same acls again.

Fix that by setting the pointers to NULL after releasing the acls.  Slightly
simplify the logic.  Also, posix_acl_release checks for NULL already, so
there is no need to duplicate those checks here.

Fixes: e01580bf9e4d ("gfs2: use generic posix ACL infrastructure")
Reported-by: Pan Bian 
Cc: Christoph Hellwig 
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Bob Peterson 
Signed-off-by: Greg Kroah-Hartman

dlm: memory leaks on error path in dlm_user_request()

2019-01-13T08:24:06+00:00

commit d47b41aceeadc6b58abc9c7c6485bef7cfb75636 upstream.

According to comment in dlm_user_request() ua should be freed
in dlm_free_lkb() after successful attach to lkb.

However ua is attached to lkb not in set_lock_args() but later,
inside request_lock().

Fixes 597d0cae0f99 ("[DLM] dlm: user locks")
Cc: stable@kernel.org # 2.6.19

Signed-off-by: Vasily Averin 
Signed-off-by: David Teigland 
Signed-off-by: Greg Kroah-Hartman

dlm: lost put_lkb on error path in receive_convert() and receive_unlock()

2019-01-13T08:24:06+00:00

commit c0174726c3976e67da8649ac62cae43220ae173a upstream.

Fixes 6d40c4a708e0 ("dlm: improve error and debug messages")
Cc: stable@kernel.org # 3.5

Signed-off-by: Vasily Averin 
Signed-off-by: David Teigland 
Signed-off-by: Greg Kroah-Hartman

dlm: possible memory leak on error path in create_lkb()

2019-01-13T08:24:06+00:00

commit 23851e978f31eda8b2d01bd410d3026659ca06c7 upstream.

Fixes 3d6aa675fff9 ("dlm: keep lkbs in idr")
Cc: stable@kernel.org # 3.1

Signed-off-by: Vasily Averin 
Signed-off-by: David Teigland 
Signed-off-by: Greg Kroah-Hartman

dlm: fixed memory leaks after failed ls_remove_names allocation

2019-01-13T08:24:05+00:00

commit b982896cdb6e6a6b89d86dfb39df489d9df51e14 upstream.

If allocation fails on last elements of array need to free already
allocated elements.

v2: just move existing out_rsbtbl label to right place

Fixes 789924ba635f ("dlm: fix race between remove and lookup")
Cc: stable@kernel.org # 3.6

Signed-off-by: Vasily Averin 
Signed-off-by: David Teigland 
Signed-off-by: Greg Kroah-Hartman

CIFS: use the correct length when pinning memory for direct I/O for write

2019-01-09T16:46:03+00:00

commit b6bc8a7b993e62f82415a5e3e4a6469e80fea19c upstream.

The current code attempts to pin memory using the largest possible wsize
based on the currect SMB credits. This doesn't cause kernel oops but this
is not optimal as we may pin more pages then actually needed.

Fix this by only pinning what are needed for doing this write I/O.

Signed-off-by: Long Li 
Cc: stable@vger.kernel.org
Signed-off-by: Steve French 
Reviewed-by: Joey Pabalinas 
Signed-off-by: Greg Kroah-Hartman