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

afs: Remote abort can cause BUG in rxrpc code

2012-03-23T18:21:22+00:00

commit c0173863528a8c9212c53e080d63a1aaae5ef4f4 upstream.

When writing files to afs I sometimes hit a BUG:

kernel BUG at fs/afs/rxrpc.c:179!

With a backtrace of:

	afs_free_call
	afs_make_call
	afs_fs_store_data
	afs_vnode_store_data
	afs_write_back_from_locked_page
	afs_writepages_region
	afs_writepages

The cause is:

	ASSERT(skb_queue_empty(&call->rx_queue));

Looking at a tcpdump of the session the abort happens because we
are exceeding our disk quota:

	rx abort fs reply store-data error diskquota exceeded (32)

So the abort error is valid. We hit the BUG because we haven't
freed all the resources for the call.

By freeing any skbs in call->rx_queue before calling afs_free_call
we avoid hitting leaking memory and avoid hitting the BUG.

Signed-off-by: Anton Blanchard 
Signed-off-by: David Howells 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

afs: Read of file returns EBADMSG

2012-03-23T18:21:21+00:00

commit 2c724fb92732c0b2a5629eb8af74e82eb62ac947 upstream.

A read of a large file on an afs mount failed:

# cat junk.file > /dev/null
cat: junk.file: Bad message

Looking at the trace, call->offset wrapped since it is only an
unsigned short. In afs_extract_data:

        _enter("{%u},{%zu},%d,,%zu", call->offset, len, last, count);
...

        if (call->offset < count) {
                if (last) {
                        _leave(" = -EBADMSG [%d < %zu]", call->offset, count);
                        return -EBADMSG;
                }

Which matches the trace:

[cat   ] ==> afs_extract_data({65132},{524},1,,65536)
[cat   ] <== afs_extract_data() = -EBADMSG [0 < 65536]

call->offset went from 65132 to 0. Fix this by making call->offset an
unsigned int.

Signed-off-by: Anton Blanchard 
Signed-off-by: David Howells 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

nilfs2: fix NULL pointer dereference in nilfs_load_super_block()

2012-03-23T18:21:21+00:00

commit d7178c79d9b7c5518f9943188091a75fc6ce0675 upstream.

According to the report from Slicky Devil, nilfs caused kernel oops at
nilfs_load_super_block function during mount after he shrank the
partition without resizing the filesystem:

 BUG: unable to handle kernel NULL pointer dereference at 00000048
 IP: [] nilfs_load_super_block+0x17e/0x280 [nilfs2]
 *pde = 00000000
 Oops: 0000 [#1] PREEMPT SMP
 ...
 Call Trace:
  [] init_nilfs+0x4b/0x2e0 [nilfs2]
  [] nilfs_mount+0x447/0x5b0 [nilfs2]
  [] mount_fs+0x36/0x180
  [] vfs_kern_mount+0x51/0xa0
  [] do_kern_mount+0x3e/0xe0
  [] do_mount+0x169/0x700
  [] sys_mount+0x6b/0xa0
  [] sysenter_do_call+0x12/0x28
 Code: 53 18 8b 43 20 89 4b 18 8b 4b 24 89 53 1c 89 43 24 89 4b 20 8b 43
 20 c7 43 2c 00 00 00 00 23 75 e8 8b 50 68 89 53 28 8b 54 b3 20 <8b> 72
 48 8b 7a 4c 8b 55 08 89 b3 84 00 00 00 89 bb 88 00 00 00
 EIP: [] nilfs_load_super_block+0x17e/0x280 [nilfs2] SS:ESP 0068:ca9bbdcc
 CR2: 0000000000000048

This turned out due to a defect in an error path which runs if the
calculated location of the secondary super block was invalid.

This patch fixes it and eliminates the reported oops.

Reported-by: Slicky Devil 
Signed-off-by: Ryusuke Konishi 
Tested-by: Slicky Devil 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

block: Fix NULL pointer dereference in sd_revalidate_disk

2012-03-19T16:02:34+00:00

commit fe316bf2d5847bc5dd975668671a7b1067603bc7 upstream.

Since 2.6.39 (1196f8b), when a driver returns -ENOMEDIUM for open(),
__blkdev_get() calls rescan_partitions() to remove
in-kernel partition structures and raise KOBJ_CHANGE uevent.

However it ends up calling driver's revalidate_disk without open
and could cause oops.

In the case of SCSI:

  process A                  process B
  ----------------------------------------------
  sys_open
    __blkdev_get
      sd_open
        returns -ENOMEDIUM
                             scsi_remove_device
                               
      rescan_partitions
        sd_revalidate_disk
          
Oopses are reported here:
http://marc.info/?l=linux-scsi&m=132388619710052

This patch separates the partition invalidation from rescan_partitions()
and use it for -ENOMEDIUM case.

Reported-by: Huajun Li 
Signed-off-by: Jun'ichi Nomura 
Acked-by: Tejun Heo 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

vfs: fix double put after complete_walk()

2012-03-19T16:02:20+00:00

commit 097b180ca09b581ef0dc24fbcfc1b227de3875df upstream.

complete_walk() already puts nd->path, no need to do it again at cleanup time.

This would result in Oopses if triggered, apparently the codepath is not too
well exercised.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

vfs: fix return value from do_last()

2012-03-19T16:02:20+00:00

commit 7f6c7e62fcc123e6bd9206da99a2163fe3facc31 upstream.

complete_walk() returns either ECHILD or ESTALE.  do_last() turns this into
ECHILD unconditionally.  If not in RCU mode, this error will reach userspace
which is complete nonsense.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

CIFS: Do not kmalloc under the flocks spinlock

2012-03-19T16:02:20+00:00

commit d5751469f210d2149cc2159ffff66cbeef6da3f2 upstream.

Reorganize the code to make the memory already allocated before
spinlock'ed loop.

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

aio: fix the "too late munmap()" race

2012-03-19T16:02:19+00:00

commit c7b285550544c22bc005ec20978472c9ac7138c6 upstream.

Current code has put_ioctx() called asynchronously from aio_fput_routine();
that's done *after* we have killed the request that used to pin ioctx,
so there's nothing to stop io_destroy() waiting in wait_for_all_aios()
from progressing.  As the result, we can end up with async call of
put_ioctx() being the last one and possibly happening during exit_mmap()
or elf_core_dump(), neither of which expects stray munmap() being done
to them...

We do need to prevent _freeing_ ioctx until aio_fput_routine() is done
with that, but that's all we care about - neither io_destroy() nor
exit_aio() will progress past wait_for_all_aios() until aio_fput_routine()
does really_put_req(), so the ioctx teardown won't be done until then
and we don't care about the contents of ioctx past that point.

Since actual freeing of these suckers is RCU-delayed, we don't need to
bump ioctx refcount when request goes into list for async removal.
All we need is rcu_read_lock held just over the ->ctx_lock-protected
area in aio_fput_routine().

Signed-off-by: Al Viro 
Reviewed-by: Jeff Moyer 
Acked-by: Benjamin LaHaise 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

aio: fix io_setup/io_destroy race

2012-03-19T16:02:18+00:00

commit 86b62a2cb4fc09037bbce2959d2992962396fd7f upstream.

Have ioctx_alloc() return an extra reference, so that caller would drop it
on success and not bother with re-grabbing it on failure exit.  The current
code is obviously broken - io_destroy() from another thread that managed
to guess the address io_setup() would've returned would free ioctx right
under us; gets especially interesting if aio_context_t * we pass to
io_setup() points to PROT_READ mapping, so put_user() fails and we end
up doing io_destroy() on kioctx another thread has just got freed...

Signed-off-by: Al Viro 
Acked-by: Benjamin LaHaise 
Reviewed-by: Jeff Moyer 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

cifs: fix dentry refcount leak when opening a FIFO on lookup

2012-03-12T19:31:26+00:00

commit 5bccda0ebc7c0331b81ac47d39e4b920b198b2cd upstream.

The cifs code will attempt to open files on lookup under certain
circumstances. What happens though if we find that the file we opened
was actually a FIFO or other special file?

Currently, the open filehandle just ends up being leaked leading to
a dentry refcount mismatch and oops on umount. Fix this by having the
code close the filehandle on the server if it turns out not to be a
regular file. While we're at it, change this spaghetti if statement
into a switch too.

Reported-by: CAI Qian 
Tested-by: CAI Qian 
Reviewed-by: Shirish Pargaonkar 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman