linux-stable.git/fs/nfs, branch v3.2.78

NFS: Fix attribute cache revalidation

2016-02-13T10:34:06+00:00

commit ade14a7df796d4e86bd9d181193c883a57b13db0 upstream.

If a NFSv4 client uses the cache_consistency_bitmask in order to
request only information about the change attribute, timestamps and
size, then it has not revalidated all attributes, and hence the
attribute timeout timestamp should not be updated.

Reported-by: Donald Buczek 
Signed-off-by: Trond Myklebust 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

nfs: if we have no valid attrs, then don't declare the attribute cache valid

2015-12-30T02:25:58+00:00

commit c812012f9ca7cf89c9e1a1cd512e6c3b5be04b85 upstream.

If we pass in an empty nfs_fattr struct to nfs_update_inode, it will
(correctly) not update any of the attributes, but it then clears the
NFS_INO_INVALID_ATTR flag, which indicates that the attributes are
up to date. Don't clear the flag if the fattr struct has no valid
attrs to apply.

Reviewed-by: Steve French 
Signed-off-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings

Failing to send a CLOSE if file is opened WRONLY and server reboots on a 4.x mount

2015-11-17T15:54:46+00:00

commit a41cbe86df3afbc82311a1640e20858c0cd7e065 upstream.

A test case is as the description says:
open(foobar, O_WRONLY);
sleep()  --> reboot the server
close(foobar)

The bug is because in nfs4state.c in nfs4_reclaim_open_state() a few
line before going to restart, there is
clear_bit(NFS4CLNT_RECLAIM_NOGRACE, &state->flags).

NFS4CLNT_RECLAIM_NOGRACE is a flag for the client states not open
owner states. Value of NFS4CLNT_RECLAIM_NOGRACE is 4 which is the
value of NFS_O_WRONLY_STATE in nfs4_state->flags. So clearing it wipes
out state and when we go to close it, “call_close” doesn’t get set as
state flag is not set and CLOSE doesn’t go on the wire.

Signed-off-by: Olga Kornievskaia 
Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings

NFSv4: don't set SETATTR for O_RDONLY|O_EXCL

2015-10-13T02:46:05+00:00

commit efcbc04e16dfa95fef76309f89710dd1d99a5453 upstream.

It is unusual to combine the open flags O_RDONLY and O_EXCL, but
it appears that libre-office does just that.

[pid  3250] stat("/home/USER/.config", {st_mode=S_IFDIR|0700, st_size=8192, ...}) = 0
[pid  3250] open("/home/USER/.config/libreoffice/4-suse/user/extensions/buildid", O_RDONLY|O_EXCL 

NFSv4 takes O_EXCL as a sign that a setattr command should be sent,
probably to reset the timestamps.

When it was an O_RDONLY open, the SETATTR command does not
identify any actual attributes to change.
If no delegation was provided to the open, the SETATTR uses the
all-zeros stateid and the request is accepted (at least by the
Linux NFS server - no harm, no foul).

If a read-delegation was provided, this is used in the SETATTR
request, and a Netapp filer will justifiably claim
NFS4ERR_BAD_STATEID, which the Linux client takes as a sign
to retry - indefinitely.

So only treat O_EXCL specially if O_CREAT was also given.

Signed-off-by: NeilBrown 
Signed-off-by: Trond Myklebust 
[bwh: Backported to 3.2: we only check open_flags, not createmode as well]
Signed-off-by: Ben Hutchings

NFS: Fix size of NFSACL SETACL operations

2015-08-12T14:33:14+00:00

commit d683cc49daf7c5afca8cd9654aaa1bf63cdf2ad9 upstream.

When encoding the NFSACL SETACL operation, reserve just the estimated
size of the ACL rather than a fixed maximum. This eliminates needless
zero padding on the wire that the server ignores.

Fixes: ee5dc7732bd5 ('NFS: Fix "kernel BUG at fs/nfs/nfs3xdr.c:1338!"')
Signed-off-by: Chuck Lever 
Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings

fixing infinite OPEN loop in 4.0 stateid recovery

2015-08-12T14:33:13+00:00

commit e8d975e73e5fa05f983fbf2723120edcf68e0b38 upstream.

Problem: When an operation like WRITE receives a BAD_STATEID, even though
recovery code clears the RECLAIM_NOGRACE recovery flag before recovering
the open state, because of clearing delegation state for the associated
inode, nfs_inode_find_state_and_recover() gets called and it makes the
same state with RECLAIM_NOGRACE flag again. As a results, when we restart
looking over the open states, we end up in the infinite loop instead of
breaking out in the next test of state flags.

Solution: unset the RECLAIM_NOGRACE set because of
calling of nfs_inode_find_state_and_recover() after returning from calling
recover_open() function.

Signed-off-by: Olga Kornievskaia 
Signed-off-by: Trond Myklebust 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

NFSv4: Minor cleanups for nfs4_handle_exception and nfs4_async_handle_error

2015-05-09T22:16:36+00:00

commit 14977489ffdb80d4caf5a184ba41b23b02fbacd9 upstream.

Signed-off-by: Trond Myklebust 
[bwh: This is not merely a cleanup but also fixes a regression introduced by
 commit 3114ea7a24d3 ("NFSv4: Return the delegation if the server returns
 NFS4ERR_OPENMODE"), backported in 3.2.14]
Signed-off-by: Ben Hutchings

NFSv4: Don't call put_rpccred() under the rcu_read_lock()

2015-05-09T22:16:22+00:00

commit 7c0af9ffb7bb4e5355470fa60b3eb711ddf226fa upstream.

put_rpccred() can sleep.

Fixes: 8f649c3762547 ("NFSv4: Fix the locking in nfs_inode_reclaim_delegation()")
Signed-off-by: Trond Myklebust 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

NFSv4.1: Fix a kfree() of uninitialised pointers in decode_cb_sequence_args

2015-05-09T22:16:15+00:00

commit d8ba1f971497c19cf80da1ea5391a46a5f9fbd41 upstream.

If the call to decode_rc_list() fails due to a memory allocation error,
then we need to truncate the array size to ensure that we only call
kfree() on those pointer that were allocated.

Reported-by: David Ramos 
Fixes: 4aece6a19cf7f ("nfs41: cb_sequence xdr implementation")
Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings

nfs: don't call blocking operations while !TASK_RUNNING

2015-05-09T22:16:14+00:00

commit 6ffa30d3f734d4f6b478081dfc09592021028f90 upstream.

Bruce reported seeing this warning pop when mounting using v4.1:

     ------------[ cut here ]------------
     WARNING: CPU: 1 PID: 1121 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0()
    do not call blocking ops when !TASK_RUNNING; state=1 set at [] prepare_to_wait+0x2f/0x90
    Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer ppdev joydev snd virtio_console virtio_balloon pcspkr serio_raw parport_pc parport pvpanic floppy soundcore i2c_piix4 virtio_blk virtio_net qxl drm_kms_helper ttm drm virtio_pci virtio_ring ata_generic virtio pata_acpi
    CPU: 1 PID: 1121 Comm: nfsv4.1-svc Not tainted 3.19.0-rc4+ #25
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153950- 04/01/2014
     0000000000000000 000000004e5e3f73 ffff8800b998fb48 ffffffff8186ac78
     0000000000000000 ffff8800b998fba0 ffff8800b998fb88 ffffffff810ac9da
     ffff8800b998fb68 ffffffff81c923e7 00000000000004d9 0000000000000000
    Call Trace:
     [] dump_stack+0x4c/0x65
     [] warn_slowpath_common+0x8a/0xc0
     [] warn_slowpath_fmt+0x55/0x70
     [] ? prepare_to_wait+0x2f/0x90
     [] ? prepare_to_wait+0x2f/0x90
     [] __might_sleep+0xbd/0xd0
     [] kmem_cache_alloc_trace+0x243/0x430
     [] ? groups_alloc+0x3e/0x130
     [] groups_alloc+0x3e/0x130
     [] svcauth_unix_accept+0x16e/0x290 [sunrpc]
     [] svc_authenticate+0xe1/0xf0 [sunrpc]
     [] svc_process_common+0x244/0x6a0 [sunrpc]
     [] bc_svc_process+0x1c4/0x260 [sunrpc]
     [] nfs41_callback_svc+0x128/0x1f0 [nfsv4]
     [] ? wait_woken+0xc0/0xc0
     [] ? nfs4_callback_svc+0x60/0x60 [nfsv4]
     [] kthread+0x11f/0x140
     [] ? local_clock+0x15/0x30
     [] ? kthread_create_on_node+0x250/0x250
     [] ret_from_fork+0x7c/0xb0
     [] ? kthread_create_on_node+0x250/0x250
    ---[ end trace 675220a11e30f4f2 ]---

nfs41_callback_svc does most of its work while in TASK_INTERRUPTIBLE,
which is just wrong. Fix that by finishing the wait immediately if we've
found that the list has something on it.

Also, we don't expect this kthread to accept signals, so we should be
using a TASK_UNINTERRUPTIBLE sleep instead. That however, opens us up
hung task warnings from the watchdog, so have the schedule_timeout
wake up every 60s if there's no callback activity.

Reported-by: "J. Bruce Fields" 
Signed-off-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings