linux-toradex.git/fs/nfs, branch v3.12.18

NFSv3: Fix return value of nfs3_proc_setacls

2014-04-18T08:47:21+00:00

commit 8f493b9cfcd8941c6b27d6ce8e3b4a78c094b3c1 upstream.

nfs3_proc_setacls is used internally by the NFSv3 create operations
to set the acl after the file has been created. If the operation
fails because the server doesn't support acls, then it must return '0',
not -EOPNOTSUPP.

Reported-by: Russell King 
Link: http://lkml.kernel.org/r/20140201010328.GI15937@n2100.arm.linux.org.uk
Cc: Christoph Hellwig 
Tested-by: Takashi Iwai 
Signed-off-by: Trond Myklebust 
Acked-by: NeilBrown 
Signed-off-by: Jiri Slaby

nfs: initialize the ACL support bits to zero.

2014-04-18T08:46:14+00:00

commit a1800acaf7d1c2bf6d68b9a8f4ab8560cc66555a upstream.

Avoid returning incorrect acl mask attributes when the server doesn't
support ACLs.

Signed-off-by: Malahal Naineni 
Signed-off-by: Trond Myklebust 
Signed-off-by: Jiri Slaby

NFSv4.1 free slot before resending I/O to MDS

2014-04-03T08:32:19+00:00

commit f9c96fcc501a43dbc292b17fc0ded4b54e63b79d upstream.

Fix a dynamic session slot leak where a slot is preallocated and I/O is
resent through the MDS.

Signed-off-by: Andy Adamson 
Signed-off-by: Trond Myklebust 
Signed-off-by: Jiri Slaby

nfs: add memory barriers around NFS_INO_INVALID_DATA and NFS_INO_INVALIDATING

2014-04-03T08:32:18+00:00

commit 4db72b40fdbc706f8957e9773ae73b1574b8c694 upstream.

If the setting of NFS_INO_INVALIDATING gets reordered to before the
clearing of NFS_INO_INVALID_DATA, then another task may hit a race
window where both appear to be clear, even though the inode's pages are
still in need of invalidation. Fix this by adding the appropriate memory
barriers.

Signed-off-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
Signed-off-by: Jiri Slaby

NFS: Fix races in nfs_revalidate_mapping

2014-04-03T08:32:17+00:00

commit 17dfeb9113397a6119091a491ef7182649f0c5a9 upstream.

Commit d529ef83c355f97027ff85298a9709fe06216a66 (NFS: fix the handling
of NFS_INO_INVALID_DATA flag in nfs_revalidate_mapping) introduces
a potential race, since it doesn't test the value of nfsi->cache_validity
and set the bitlock in nfsi->flags atomically.

Signed-off-by: Trond Myklebust 
Cc: Jeff Layton 
Signed-off-by: Jiri Slaby

NFS: fix the handling of NFS_INO_INVALID_DATA flag in nfs_revalidate_mapping

2014-04-03T08:32:17+00:00

commit d529ef83c355f97027ff85298a9709fe06216a66 upstream.

There is a possible race in how the nfs_invalidate_mapping function is
handled.  Currently, we go and invalidate the pages in the file and then
clear NFS_INO_INVALID_DATA.

The problem is that it's possible for a stale page to creep into the
mapping after the page was invalidated (i.e., via readahead). If another
writer comes along and sets the flag after that happens but before
invalidate_inode_pages2 returns then we could clear the flag
without the cache having been properly invalidated.

So, we must clear the flag first and then invalidate the pages. Doing
this however, opens another race:

It's possible to have two concurrent read() calls that end up in
nfs_revalidate_mapping at the same time. The first one clears the
NFS_INO_INVALID_DATA flag and then goes to call nfs_invalidate_mapping.

Just before calling that though, the other task races in, checks the
flag and finds it cleared. At that point, it trusts that the mapping is
good and gets the lock on the page, allowing the read() to be satisfied
from the cache even though the data is no longer valid.

These effects are easily manifested by running diotest3 from the LTP
test suite on NFS. That program does a series of DIO writes and buffered
reads. The operations are serialized and page-aligned but the existing
code fails the test since it occasionally allows a read to come out of
the cache incorrectly. While mixing direct and buffered I/O isn't
recommended, I believe it's possible to hit this in other ways that just
use buffered I/O, though that situation is much harder to reproduce.

The problem is that the checking/clearing of that flag and the
invalidation of the mapping really need to be atomic. Fix this by
serializing concurrent invalidations with a bitlock.

At the same time, we also need to allow other places that check
NFS_INO_INVALID_DATA to check whether we might be in the middle of
invalidating the file, so fix up a couple of places that do that
to look for the new NFS_INO_INVALIDATING flag.

Doing this requires us to be careful not to set the bitlock
unnecessarily, so this code only does that if it believes it will
be doing an invalidation.

Signed-off-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
Signed-off-by: Jiri Slaby

pnfs: fix BUG in filelayout_recover_commit_reqs

2014-04-03T08:32:16+00:00

commit 471252cd8b34b0609973740b25dcd1ff01dc1889 upstream.

cond_resched_lock(cinfo->lock) is called everywhere else while holding
the cinfo->lock spinlock.  Not holding this lock while calling
transfer_commit_list in filelayout_recover_commit_reqs causes the BUG
below.

It's true that we can't hold this lock while calling pnfs_put_lseg,
because that might try to lock the inode lock - which might be the
same lock as cinfo->lock.

To reproduce, mount a 2 DS pynfs server and run an O_DIRECT command
that crosses a stripe boundary and is not page aligned, such as:

 dd if=/dev/zero of=/mnt/f bs=17000 count=1 oflag=direct

BUG: sleeping function called from invalid context at linux/fs/nfs/nfs4filelayout.c:1161
in_atomic(): 0, irqs_disabled(): 0, pid: 27, name: kworker/0:1
2 locks held by kworker/0:1/27:
 #0:  (events){.+.+.+}, at: [] process_one_work+0x175/0x3a5
 #1:  ((&dreq->work)){+.+...}, at: [] process_one_work+0x175/0x3a5
CPU: 0 PID: 27 Comm: kworker/0:1 Not tainted 3.13.0-rc3-branch-dros_testing+ #21
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
Workqueue: events nfs_direct_write_schedule_work [nfs]
 0000000000000000 ffff88007a39bbb8 ffffffff81491256 ffff88007b87a130  ffff88007a39bbd8 ffffffff8105f103 ffff880079614000 ffff880079617d40  ffff88007a39bc20 ffffffffa011603e ffff880078988b98 0000000000000000
Call Trace:
 [] dump_stack+0x4d/0x66
 [] __might_sleep+0x100/0x105
 [] transfer_commit_list+0x94/0xf1 [nfs_layout_nfsv41_files]
 [] filelayout_recover_commit_reqs+0x3b/0x68 [nfs_layout_nfsv41_files]
 [] nfs_direct_write_reschedule+0x9f/0x1d6 [nfs]
 [] ? mark_lock+0x1df/0x224
 [] ? trace_hardirqs_off_caller+0x37/0xa4
 [] ? trace_hardirqs_off+0xd/0xf
 [] nfs_direct_write_schedule_work+0x9d/0xb7 [nfs]
 [] ? process_one_work+0x175/0x3a5
 [] process_one_work+0x1f6/0x3a5
 [] ? process_one_work+0x175/0x3a5
 [] worker_thread+0x149/0x1f5
 [] ? rescuer_thread+0x28d/0x28d
 [] kthread+0xd2/0xda
 [] ? __kthread_parkme+0x61/0x61
 [] ret_from_fork+0x7c/0xb0
 [] ? __kthread_parkme+0x61/0x61

Signed-off-by: Weston Andros Adamson 
Signed-off-by: Trond Myklebust 
Signed-off-by: Jiri Slaby

nfs: increment i_dio_count for reads, too

2014-04-03T08:32:15+00:00

commit 1f90ee27461e31a1c18e5d819f6ea6f5c7304b16 upstream.

i_dio_count is used to protect dio access against truncate.  We want
to make sure there are no dio reads pending either when doing a
truncate.  I suspect on plain NFS things might work even without
this, but once we use a pnfs layout driver that access backing devices
directly things will go bad without the proper synchronization.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Trond Myklebust 
Signed-off-by: Jiri Slaby

nfs: defer inode_dio_done call until size update is done

2014-04-03T08:32:15+00:00

commit 2a009ec98cce440c0992fc9a2353e96cdb0b048b upstream.

We need to have the I/O fully finished before telling the truncate code
that we are done.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Trond Myklebust 
Signed-off-by: Jiri Slaby

nfs: fix size updates for aio writes

2014-04-03T08:32:14+00:00

commit 9811cd57f4c6b5b60ec104de68a88303717e3106 upstream.

nfs_file_direct_write only updates the inode size if it succeeded and
returned the number of bytes written.  But in the AIO case nfs_direct_wait
turns the return value into -EIOCBQUEUED and we skip the size update.

Instead the aio completion path should updated it, which this patch
does.  The implementation is a little hacky because there is no obvious
way to find out we are called for a write in nfs_direct_complete.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Trond Myklebust 
Signed-off-by: Jiri Slaby