linux-stable.git/fs/nfs, branch linux-5.0.y

NFS: Fix a double unlock from nfs_match,get_client

2019-05-31T13:45:24+00:00

[ Upstream commit c260121a97a3e4df6536edbc2f26e166eff370ce ]

Now that nfs_match_client drops the nfs_client_lock, we should be
careful
to always return it in the same condition: locked.

Fixes: 950a578c6128 ("NFS: make nfs_match_client killable")
Reported-by: syzbot+228a82b263b5da91883d@syzkaller.appspotmail.com
Signed-off-by: Benjamin Coddington 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin

Fix nfs4.2 return -EINVAL when do dedupe operation

2019-05-31T13:44:59+00:00

[ Upstream commit ce96e888fe48ecfa868c9a39adc03292c78a80ff ]

dedupe_file_range operations is combiled into remap_file_range.
But in nfs42_remap_file_range, it's skiped for dedupe operations.
Before this patch:
  # dd if=/dev/zero of=nfs/file bs=1M count=1
  # xfs_io -c "dedupe nfs/file 4k 64k 4k" nfs/file
  XFS_IOC_FILE_EXTENT_SAME: Invalid argument
After this patch:
  # dd if=/dev/zero of=nfs/file bs=1M count=1
  # xfs_io -c "dedupe nfs/file 4k 64k 4k" nfs/file
  deduped 4096/4096 bytes at offset 65536
  4 KiB, 1 ops; 0.0046 sec (865.988 KiB/sec and 216.4971 ops/sec)

Signed-off-by: Xiaoli Feng 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin

NFS: make nfs_match_client killable

2019-05-31T13:44:51+00:00

[ Upstream commit 950a578c6128c2886e295b9c7ecb0b6b22fcc92b ]

    Actually we don't do anything with return value from
    nfs_wait_client_init_complete in nfs_match_client, as a
    consequence if we get a fatal signal and client is not
    fully initialised, we'll loop to "again" label

    This has been proven to cause soft lockups on some scenarios
    (no-carrier but configured network interfaces)

Signed-off-by: Roberto Bergantinos Corpas 
Reviewed-by: Benjamin Coddington 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin

PNFS fallback to MDS if no deviceid found

2019-05-25T16:22:07+00:00

commit b1029c9bc078a6f1515f55dd993b507dcc7e3440 upstream.

If we fail to find a good deviceid while trying to pnfs instead of
propogating an error back fallback to doing IO to the MDS. Currently,
code with fals the IO with EINVAL.

Signed-off-by: Olga Kornievskaia 
Fixes: 8d40b0f14846f ("NFS filelayout:call GETDEVICEINFO after pnfs_layout_process completes"
Cc: stable@vger.kernel.org # v4.11+
Signed-off-by: Anna Schumaker 
Signed-off-by: Greg Kroah-Hartman

NFS4: Fix v4.0 client state corruption when mount

2019-05-25T16:22:06+00:00

commit f02f3755dbd14fb935d24b14650fff9ba92243b8 upstream.

stat command with soft mount never return after server is stopped.

When alloc a new client, the state of the client will be set to
NFS4CLNT_LEASE_EXPIRED.

When the server is stopped, the state manager will work, and accord
the state to recover. But the state is NFS4CLNT_LEASE_EXPIRED, it
will drain the slot table and lead other task to wait queue, until
the client recovered. Then the stat command is hung.

When discover server trunking, the client will renew the lease,
but check the client state, it lead the client state corruption.

So, we need to call state manager to recover it when detect server
ip trunking.

Signed-off-by: ZhangXiaoxu 
Cc: stable@vger.kernel.org
Signed-off-by: Anna Schumaker 
Signed-off-by: Greg Kroah-Hartman

NFSv4.1 fix incorrect return value in copy_file_range

2019-05-10T16:36:11+00:00

[ Upstream commit 0769663b4f580566ef6cdf366f3073dbe8022c39 ]

According to the NFSv4.2 spec if the input and output file is the
same file, operation should fail with EINVAL. However, linux
copy_file_range() system call has no such restrictions. Therefore,
in such case let's return EOPNOTSUPP and allow VFS to fallback
to doing do_splice_direct(). Also when copy_file_range is called
on an NFSv4.0 or 4.1 mount (ie., a server that doesn't support
COPY functionality), we also need to return EOPNOTSUPP and
fallback to a regular copy.

Fixes xfstest generic/075, generic/091, generic/112, generic/263
for all NFSv4.x versions.

Signed-off-by: Olga Kornievskaia 
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

NFS: Fix a typo in nfs_init_timeout_values()

2019-05-04T07:21:17+00:00

[ Upstream commit 5a698243930c441afccec04e4d5dc8febfd2b775 ]

Specifying a retrans=0 mount parameter to a NFS/TCP mount, is
inadvertently causing the NFS client to rewrite any specified
timeout parameter to the default of 60 seconds.

Fixes: a956beda19a6 ("NFS: Allow the mount option retrans=0")
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin (Microsoft)

NFS: Forbid setting AF_INET6 to "struct sockaddr_in"->sin_family.

2019-05-02T08:02:49+00:00

commit 7c2bd9a39845bfb6d72ddb55ce737650271f6f96 upstream.

syzbot is reporting uninitialized value at rpc_sockaddr2uaddr() [1]. This
is because syzbot is setting AF_INET6 to "struct sockaddr_in"->sin_family
(which is embedded into user-visible "struct nfs_mount_data" structure)
despite nfs23_validate_mount_data() cannot pass sizeof(struct sockaddr_in6)
bytes of AF_INET6 address to rpc_sockaddr2uaddr().

Since "struct nfs_mount_data" structure is user-visible, we can't change
"struct nfs_mount_data" to use "struct sockaddr_storage". Therefore,
assuming that everybody is using AF_INET family when passing address via
"struct nfs_mount_data"->addr, reject if its sin_family is not AF_INET.

[1] https://syzkaller.appspot.com/bug?id=599993614e7cbbf66bc2656a919ab2a95fb5d75c

Reported-by: syzbot 
Signed-off-by: Tetsuo Handa 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFSv4.1 don't free interrupted slot on open

2019-04-03T04:27:28+00:00

commit 0cb98abb5bd13b9a636bde603d952d722688b428 upstream.

Allow the async rpc task for finish and update the open state if needed,
then free the slot. Otherwise, the async rpc unable to decode the reply.

Signed-off-by: Olga Kornievskaia 
Fixes: ae55e59da0e4 ("pnfs: Don't release the sequence slot...")
Cc: stable@vger.kernel.org # v4.18+
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFS: Fix nfs4_lock_state refcounting in nfs4_alloc_{lock,unlock}data()

2019-04-03T04:27:28+00:00

commit 3028efe03be9c8c4cd7923f0f3c39b2871cc8a8f upstream.

Commit 7b587e1a5a6c ("NFS: use locks_copy_lock() to copy locks.")
changed the lock copying from memcpy() to the dedicated
locks_copy_lock() function. The latter correctly increments the
nfs4_lock_state.ls_count via nfs4_fl_copy_lock(), however, this refcount
has already been incremented in the nfs4_alloc_{lock,unlock}data().
Kmemleak subsequently reports an unreferenced nfs4_lock_state object as
below (arm64 platform):

unreferenced object 0xffff8000fce0b000 (size 256):
  comm "systemd-sysuser", pid 1608, jiffies 4294892825 (age 32.348s)
  hex dump (first 32 bytes):
    20 57 4c fb 00 80 ff ff 20 57 4c fb 00 80 ff ff   WL..... WL.....
    00 57 4c fb 00 80 ff ff 01 00 00 00 00 00 00 00  .WL.............
  backtrace:
    [<000000000d15010d>] kmem_cache_alloc+0x178/0x208
    [<00000000d7c1d264>] nfs4_set_lock_state+0x124/0x1f0
    [<000000009c867628>] nfs4_proc_lock+0x90/0x478
    [<000000001686bd74>] do_setlk+0x64/0xe8
    [<00000000e01500d4>] nfs_lock+0xe8/0x1f0
    [<000000004f387d8d>] vfs_lock_file+0x18/0x40
    [<00000000656ab79b>] do_lock_file_wait+0x68/0xf8
    [<00000000f17c4a4b>] fcntl_setlk+0x224/0x280
    [<0000000052a242c6>] do_fcntl+0x418/0x730
    [<000000004f47291a>] __arm64_sys_fcntl+0x84/0xd0
    [<00000000d6856e01>] el0_svc_common+0x80/0xf0
    [<000000009c4bd1df>] el0_svc_handler+0x2c/0x80
    [<00000000b1a0d479>] el0_svc+0x8/0xc
    [<0000000056c62a0f>] 0xffffffffffffffff

This patch removes the original refcount_inc(&lsp->ls_count) that was
paired with the memcpy() lock copying.

Fixes: 7b587e1a5a6c ("NFS: use locks_copy_lock() to copy locks.")
Cc:  # 5.0.x-
Cc: NeilBrown 
Signed-off-by: Catalin Marinas 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman