linux-stable.git/fs, branch v3.13.6

quota: Fix race between dqput() and dquot_scan_active()

2014-03-07T06:06:28+00:00

commit 1362f4ea20fa63688ba6026e586d9746ff13a846 upstream.

Currently last dqput() can race with dquot_scan_active() causing it to
call callback for an already deactivated dquot. The race is as follows:

CPU1					CPU2
  dqput()
    spin_lock(&dq_list_lock);
    if (atomic_read(&dquot->dq_count) > 1) {
     - not taken
    if (test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) {
      spin_unlock(&dq_list_lock);
      ->release_dquot(dquot);
        if (atomic_read(&dquot->dq_count) > 1)
         - not taken
					  dquot_scan_active()
					    spin_lock(&dq_list_lock);
					    if (!test_bit(DQ_ACTIVE_B, &dquot->dq_flags))
					     - not taken
					    atomic_inc(&dquot->dq_count);
					    spin_unlock(&dq_list_lock);
        - proceeds to release dquot
					    ret = fn(dquot, priv);
					     - called for inactive dquot

Fix the problem by making sure possible ->release_dquot() is finished by
the time we call the callback and new calls to it will notice reference
dquot_scan_active() has taken and bail out.

Signed-off-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman

Revert "writeback: do not sync data dirtied after sync start"

2014-03-07T06:06:22+00:00

commit 0dc83bd30b0bf5410c0933cfbbf8853248eff0a9 upstream.

This reverts commit c4a391b53a72d2df4ee97f96f78c1d5971b47489. Dave
Chinner  has reported the commit may cause some
inodes to be left out from sync(2). This is because we can call
redirty_tail() for some inode (which sets i_dirtied_when to current time)
after sync(2) has started or similarly requeue_inode() can set
i_dirtied_when to current time if writeback had to skip some pages. The
real problem is in the functions clobbering i_dirtied_when but fixing
that isn't trivial so revert is a safer choice for now.

Signed-off-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman

fs: fix iversion handling

2014-03-07T06:06:18+00:00

commit dff6efc326a4d5f305797d4a6bba14f374fdd633 upstream.

Currently notify_change directly updates i_version for size updates,
which not only is counter to how all other fields are updated through
struct iattr, but also breaks XFS, which need inode updates to happen
under its own lock, and synchronized to the structure that gets written
to the log.

Remove the update in the common code, and it to btrfs and ext4,
XFS already does a proper updaste internally and currently gets a
double update with the existing code.

IMHO this is 3.13 and -stable material and should go in through the XFS
tree.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Andreas Dilger 
Acked-by: Jan Kara 
Reviewed-by: Dave Chinner 
Signed-off-by: Chris Mason 
Signed-off-by: Ben Myers 
Signed-off-by: Greg Kroah-Hartman

NFS fix error return in nfs4_select_rw_stateid

2014-03-07T06:06:11+00:00

commit 146d70caaa1b87f64597743429d7da4b8073d0c9 upstream.

Do not return an error when nfs4_copy_delegation_stateid succeeds.

Signed-off-by: Andy Adamson 
Link: http://lkml.kernel.org/r/1392737765-41942-1-git-send-email-andros@netapp.com
Fixes: ef1820f9be27b (NFSv4: Don't try to recover NFSv4 locks when...)
Cc: NeilBrown 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFS: Do not set NFS_INO_INVALID_LABEL unless server supports labeled NFS

2014-03-07T06:06:10+00:00

commit fd1defc257e2b12ab69bc0b379105c00eca4e112 upstream.

Commit aa9c2669626c (NFS: Client implementation of Labeled-NFS) introduces
a performance regression. When nfs_zap_caches_locked is called, it sets
the NFS_INO_INVALID_LABEL flag irrespectively of whether or not the
NFS server supports security labels. Since that flag is never cleared,
it means that all calls to nfs_revalidate_inode() will now trigger
an on-the-wire GETATTR call.

This patch ensures that we never set the NFS_INO_INVALID_LABEL unless the
server advertises support for labeled NFS.
It also causes nfs_setsecurity() to clear NFS_INO_INVALID_LABEL when it
has successfully set the security label for the inode.
Finally it gets rid of the NFS_INO_INVALID_LABEL cruft from nfs_update_inode,
which has nothing to do with labeled NFS.

Reported-by: Neil Brown 
Tested-by: Neil Brown 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

CIFS: Fix too big maxBuf size for SMB3 mounts

2014-03-07T06:06:10+00:00

commit 2365c4eaf077c48574ab6f143960048fc0f31518 upstream.

SMB3 servers can respond with MaxTransactSize of more than 4M
that can cause a memory allocation error returned from kmalloc
in a lock codepath. Also the client doesn't support multicredit
requests now and allows buffer sizes of 65536 bytes only. Set
MaxTransactSize to this maximum supported value.

Signed-off-by: Pavel Shilovsky 
Acked-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: ensure that uncached writes handle unmapped areas correctly

2014-03-07T06:06:10+00:00

commit 5d81de8e8667da7135d3a32a964087c0faf5483f upstream.

It's possible for userland to pass down an iovec via writev() that has a
bogus user pointer in it. If that happens and we're doing an uncached
write, then we can end up getting less bytes than we expect from the
call to iov_iter_copy_from_user. This is CVE-2014-0069

cifs_iovec_write isn't set up to handle that situation however. It'll
blindly keep chugging through the page array and not filling those pages
with anything useful. Worse yet, we'll later end up with a negative
number in wdata->tailsz, which will confuse the sending routines and
cause an oops at the very least.

Fix this by having the copy phase of cifs_iovec_write stop copying data
in this situation and send the last write as a short one. At the same
time, we want to avoid sending a zero-length write to the server, so
break out of the loop and set rc to -EFAULT if that happens. This also
allows us to handle the case where no address in the iovec is valid.

[Note: Marking this for stable on v3.4+ kernels, but kernels as old as
       v2.6.38 may have a similar problem and may need similar fix]

Reviewed-by: Pavel Shilovsky 
Reported-by: Al Viro 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

jbd2: fix use after free in jbd2_journal_start_reserved()

2014-03-07T06:06:09+00:00

commit 92e3b40537707001d17bbad800d150ab04e53bf4 upstream.

If start_this_handle() fails then it leads to a use after free of
"handle".

Signed-off-by: Dan Carpenter 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

ext4: don't leave i_crtime.tv_sec uninitialized

2014-03-07T06:06:07+00:00

commit 19ea80603715d473600cd993b9987bc97d042e02 upstream.

If the i_crtime field is not present in the inode, don't leave the
field uninitialized.

Fixes: ef7f38359 ("ext4: Add nanosecond timestamps")
Reported-by: Vegard Nossum 
Tested-by: Vegard Nossum 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

ext4: fix online resize with a non-standard blocks per group setting

2014-03-07T06:06:07+00:00

commit 3d2660d0c9c2f296837078c189b68a47f6b2e3b5 upstream.

The set_flexbg_block_bitmap() function assumed that the number of
blocks in a blockgroup was sb->blocksize * 8, which is normally true,
but not always!  Use EXT4_BLOCKS_PER_GROUP(sb) instead, to fix block
bitmap corruption after:

mke2fs -t ext4 -g 3072 -i 4096 /dev/vdd 1G
mount -t ext4 /dev/vdd /vdd
resize2fs /dev/vdd 8G

Signed-off-by: "Theodore Ts'o" 
Reported-by: Jon Bernard 
Signed-off-by: Greg Kroah-Hartman