linux-toradex.git/fs, branch v3.12.14

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

2014-03-05T16:13:53+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: Jiri Slaby

fs: fix iversion handling

2014-03-05T16:13:43+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: Jiri Slaby

NFS fix error return in nfs4_select_rw_stateid

2014-03-05T16:13:42+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: Jiri Slaby

CIFS: Fix too big maxBuf size for SMB3 mounts

2014-03-05T16:13:41+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: Jiri Slaby

cifs: ensure that uncached writes handle unmapped areas correctly

2014-03-05T16:13:41+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: Jiri Slaby

jbd2: fix use after free in jbd2_journal_start_reserved()

2014-03-05T16:13:41+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: Jiri Slaby

ext4: don't leave i_crtime.tv_sec uninitialized

2014-03-05T16:13:40+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: Jiri Slaby

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

2014-03-05T16:13:39+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: Jiri Slaby

ext4: fix online resize with very large inode tables

2014-03-05T16:13:39+00:00

commit b93c95353413041a8cebad915a8109619f66bcc6 upstream.

If a file system has a large number of inodes per block group, all of
the metadata blocks in a flex_bg may be larger than what can fit in a
single block group.  Unfortunately, ext4_alloc_group_tables() in
resize.c was never tested to see if it would handle this case
correctly, and there were a large number of bugs which caused the
following sequence to result in a BUG_ON:

kernel bug at fs/ext4/resize.c:409!
   ...
call trace:
 [] ext4_flex_group_add+0x1448/0x1830
 [] ext4_resize_fs+0x7b2/0xe80
 [] ext4_ioctl+0xbf0/0xf00
 [] do_vfs_ioctl+0x2dd/0x4b0
 [] ? final_putname+0x22/0x50
 [] sys_ioctl+0x81/0xa0
 [] system_call_fastpath+0x16/0x1b
code: c8 4c 89 df e8 41 96 f8 ff 44 89 e8 49 01 c4 44 29 6d d4 0
rip  [] set_flexbg_block_bitmap+0x171/0x180


This can be reproduced with the following command sequence:

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

To fix this, we need to make sure the right thing happens when a block
group's inode table straddles two block groups, which means the
following bugs had to be fixed:

1) Not clearing the BLOCK_UNINIT flag in the second block group in
   ext4_alloc_group_tables --- the was proximate cause of the BUG_ON.

2) Incorrectly determining how many block groups contained contiguous
   free blocks in ext4_alloc_group_tables().

3) Incorrectly setting the start of the next block range to be marked
   in use after a discontinuity in setup_new_flex_group_blocks().

Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Jiri Slaby

ext4: don't try to modify s_flags if the the file system is read-only

2014-03-05T16:13:39+00:00

commit 23301410972330c0ae9a8afc379ba2005e249cc6 upstream.

If an ext4 file system is created by some tool other than mke2fs
(perhaps by someone who has a pathalogical fear of the GPL) that
doesn't set one or the other of the EXT2_FLAGS_{UN}SIGNED_HASH flags,
and that file system is then mounted read-only, don't try to modify
the s_flags field.  Otherwise, if dm_verity is in use, the superblock
will change, causing an dm_verity failure.

Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Jiri Slaby