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

pnfsblock: limit bio page count

2012-01-26T00:13:37+00:00

commit 74a6eeb44ca6174d9cc93b9b8b4d58211c57bc80 upstream.

One bio can have at most BIO_MAX_PAGES pages. We should limit it bec otherwise
bio_alloc will fail when there are many pages in one read/write_pagelist.

Signed-off-by: Peng Tao 
Signed-off-by: Benny Halevy 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

pnfsblock: don't spinlock when freeing block_dev

2012-01-26T00:13:36+00:00

commit 93a3844ee0f843b05a1df4b52e1a19ff26b98d24 upstream.

bl_free_block_dev() may sleep. We can not call it with spinlock held.
Besides, there is no need to take bm_lock as we are last user freeing bm_devlist.

Signed-off-by: Peng Tao 
Signed-off-by: Benny Halevy 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

pnfsblock: acquire im_lock in _preload_range

2012-01-26T00:13:36+00:00

commit 39e567ae36fe03c2b446e1b83ee3d39bea08f90b upstream.

When calling _add_entry, we should take the im_lock to protect
agains other modifiers.

Signed-off-by: Peng Tao 
Signed-off-by: Benny Halevy 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

nfs: fix regression in handling of context= option in NFSv4

2012-01-26T00:13:16+00:00

commit 8a0d551a59ac92d8ff048d6cb29d3a02073e81e8 upstream.

Setting the security context of a NFSv4 mount via the context= mount
option is currently broken. The NFSv4 codepath allocates a parsed
options struct, and then parses the mount options to fill it. It
eventually calls nfs4_remote_mount which calls security_init_mnt_opts.
That clobbers the lsm_opts struct that was populated earlier. This bug
also looks like it causes a small memory leak on each v4 mount where
context= is used.

Fix this by moving the initialization of the lsm_opts into
nfs_alloc_parsed_mount_data. Also, add a destructor for
nfs_parsed_mount_data to make it easier to free all of the allocations
hanging off of it, and to ensure that the security_free_mnt_opts is
called whenever security_init_mnt_opts is.

I believe this regression was introduced quite some time ago, probably
by commit c02d7adf.

Signed-off-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFSv4: include bitmap in nfsv4 get acl data

2012-01-26T00:13:15+00:00

commit bf118a342f10dafe44b14451a1392c3254629a1f upstream.

The NFSv4 bitmap size is unbounded: a server can return an arbitrary
sized bitmap in an FATTR4_WORD0_ACL request.  Replace using the
nfs4_fattr_bitmap_maxsz as a guess to the maximum bitmask returned by a server
with the inclusion of the bitmap (xdr length plus bitmasks) and the acl data
xdr length to the (cached) acl page data.

This is a general solution to commit e5012d1f "NFSv4.1: update
nfs4_fattr_bitmap_maxsz" and fixes hitting a BUG_ON in xdr_shrink_bufhead
when getting ACLs.

Fix a bug in decode_getacl that returned -EINVAL on ACLs > page when getxattr
was called with a NULL buffer, preventing ACL > PAGE_SIZE from being retrieved.

Signed-off-by: Andy Adamson 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFS - fix recent breakage to NFS error handling.

2012-01-26T00:13:15+00:00

commit 2edb6bc3852c681c0d948245bd55108dc6407604 upstream.

	From c6d615d2b97fe305cbf123a8751ced859dca1d5e Mon Sep 17 00:00:00 2001
	From: NeilBrown 
	Date: Wed, 16 Nov 2011 09:39:05 +1100
	Subject: NFS - fix recent breakage to NFS error handling.

commit 02c24a82187d5a628c68edfe71ae60dc135cd178 made a small and
presumably unintended change to write error handling in NFS.

Previously an error from filemap_write_and_wait_range would only be of
interest if nfs_file_fsync did not return an error.  After this commit,
an error from filemap_write_and_wait_range would mean that (the rest of)
nfs_file_fsync would not even be called.

This means that:
 1/ you are more likely to see EIO than e.g. EDQUOT or ENOSPC.
 2/ NFS_CONTEXT_ERROR_WRITE remains set for longer so more writes are
    synchronous.

This patch restores previous behaviour.

Cc: Josef Bacik 
Cc: Jan Kara 
Cc: Al Viro 
Signed-off-by: NeilBrown 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFSv4.1: fix backchannel slotid off-by-one bug

2012-01-26T00:13:14+00:00

commit 61f2e5106582d02f30b6807e3f9c07463c572ccb upstream.

Signed-off-by: Andy Adamson 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

pnfs-obj: Must return layout on IO error

2012-01-26T00:13:13+00:00

commit fe0fe83585f88346557868a803a479dfaaa0688a upstream.

As mandated by the standard. In case of an IO error, a pNFS
objects layout driver must return it's layout. This is because
all device errors are reported to the server as part of the
layout return buffer.

This is implemented the same way PNFS_LAYOUTRET_ON_SETATTR
is done, through a bit flag on the pnfs_layoutdriver_type->flags
member. The flag is set by the layout driver that wants a
layout_return preformed at pnfs_ld_{write,read}_done in case
of an error.
(Though I have not defined a wrapper like pnfs_ld_layoutret_on_setattr
 because this code is never called outside of pnfs.c and pnfs IO
 paths)

Without this patch 3.[0-2] Kernels leak memory and have an annoying
WARN_ON after every IO error utilizing the pnfs-obj driver.

Signed-off-by: Boaz Harrosh 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

pnfs-obj: pNFS errors are communicated on iodata->pnfs_error

2012-01-26T00:13:13+00:00

commit 5c0b4129c07b902b27d3f3ebc087757f534a3abd upstream.

Some time along the way pNFS IO errors were switched to
communicate with a special iodata->pnfs_error member instead
of the regular RPC members. But objlayout was not switched
over.

Fix that!
Without this fix any IO error is hanged, because IO is not
switched to MDS and pages are never cleared or read.

[Applies to 3.2.0. Same bug different patch for 3.1/0 Kernels]
Signed-off-by: Boaz Harrosh 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFS: Fix a regression in nfs_file_llseek()

2011-12-15T23:44:36+00:00

After commit 06222e491e663dac939f04b125c9dc52126a75c4 (fs: handle
SEEK_HOLE/SEEK_DATA properly in all fs's that define their own llseek)
the behaviour of llseek() was changed so that it always revalidates
the file size. The bug appears to be due to a logic error in the
afore-mentioned commit, which always evaluates to 'true'.

Reported-by: Roel Kluin 
Signed-off-by: Trond Myklebust 
Cc: stable@vger.kernel.org [>=3.1]