Linux 3.0.26

commit f34dfbd3f148498b3fc1070229e5f8b13b98e12e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Mar 23 13:55:24 2012 -0700

    Linux 3.0.26

commit 029a9375e40af22c2f75d7a15615d2c87731f366
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Dec 9 15:06:18 2011 +1100

    powerpc/pmac: Fix SMP kernels on pre-core99 UP machines

    commit 78c5c68a4cf4329d17abfa469345ddf323d4fd62 upstream.

    The code for "powersurge" SMP would kick in and cause a crash
    at boot due to the lack of a NULL test.

    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
    Reported-by: Adam Conrad <adconrad@ubuntu.com>
    Tested-by: Adam Conrad <adconrad@ubuntu.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8290924361675d411266b890ab3b5964dc8e7255
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Mar 8 13:16:01 2012 +0100

    iwl3945: fix possible il->txq NULL pointer dereference in delayed works

    commit 210787e82a0ac1ffb5d7be1c796f0c51050849ad upstream.

    On il3945_down procedure we free tx queue data and nullify il->txq
    pointer. After that we drop mutex and then cancel delayed works. There
    is possibility, that after drooping mutex and before the cancel, some
    delayed work will start and crash while trying to send commands to
    the device. For example, here is reported crash in
    il3945_bg_reg_txpower_periodic():
    https://bugzilla.kernel.org/show_bug.cgi?id=42766#c10

    Patch fix problem by adding il->txq check on works that send commands,
    hence utilize tx queue.

    Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 97490c46fea06ecf95f989789e72c54fba2e2584
Author: RongQing.Li <roy.qing.li@gmail.com>
Date:   Thu Mar 15 22:54:14 2012 +0000

    ipv6: Don't dev_hold(dev) in ip6_mc_find_dev_rcu.

    [ Upstream commit c577923756b7fe9071f28a76b66b83b306d1d001 ]

    ip6_mc_find_dev_rcu() is called with rcu_read_lock(), so don't
    need to dev_hold().
    With dev_hold(), not corresponding dev_put(), will lead to leak.

    [ bug introduced in 96b52e61be1 (ipv6: mcast: RCU conversions) ]

    Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 137a954db947096bd9378ff5a6a77336231f4a90
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Sat Mar 10 09:20:21 2012 +0000

    tcp: fix syncookie regression

    [ Upstream commit dfd25ffffc132c00070eed64200e8950da5d7e9d ]

    commit ea4fc0d619 (ipv4: Don't use rt->rt_{src,dst} in ip_queue_xmit())
    added a serious regression on synflood handling.

    Simon Kirby discovered a successful connection was delayed by 20 seconds
    before being responsive.

    In my tests, I discovered that xmit frames were lost, and needed ~4
    retransmits and a socket dst rebuild before being really sent.

    In case of syncookie initiated connection, we use a different path to
    initialize the socket dst, and inet->cork.fl.u.ip4 is left cleared.

    As ip_queue_xmit() now depends on inet flow being setup, fix this by
    copying the temp flowi4 we use in cookie_v4_check().

    Reported-by: Simon Kirby <sim@netnation.com>
    Bisected-by: Simon Kirby <sim@netnation.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Tested-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f54cf2cb91a3efadeaae555baed47eac660d53c
Author: Anton Blanchard <anton@samba.org>
Date:   Wed Mar 7 11:42:49 2012 +1100

    perf tools: Incorrect use of snprintf results in SEGV

    commit b832796caa1fda8516464a003c8c7cc547bc20c2 upstream.

    I have a workload where perf top scribbles over the stack and we SEGV.
    What makes it interesting is that an snprintf is causing this.

    The workload is a c++ gem that has method names over 3000 characters
    long, but snprintf is designed to avoid overrunning buffers. So what
    went wrong?

    The problem is we assume snprintf returns the number of characters
    written:

        ret += repsep_snprintf(bf + ret, size - ret, "[%c] ", self->level);
    ...
        ret += repsep_snprintf(bf + ret, size - ret, "%s", self->ms.sym->name);

    Unfortunately this is not how snprintf works. snprintf returns the
    number of characters that would have been written if there was enough
    space. In the above case, if the first snprintf returns a value larger
    than size, we pass a negative size into the second snprintf and happily
    scribble over the stack. If you have 3000 character c++ methods thats a
    lot of stack to trample.

    This patch fixes repsep_snprintf by clamping the value at size - 1 which
    is the maximum snprintf can write before adding the NULL terminator.

    I get the sinking feeling that there are a lot of other uses of snprintf
    that have this same bug, we should audit them all.

    Cc: David Ahern <dsahern@gmail.com>
    Cc: Eric B Munson <emunson@mgebm.net>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
    Link: http://lkml.kernel.org/r/20120307114249.44275ca3@kryten
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 086b5909dfe7c79b68ed76d798a30dfc7c329852
Author: Anton Blanchard <anton@samba.org>
Date:   Fri Mar 16 10:28:19 2012 +0000

    afs: Remote abort can cause BUG in rxrpc code

    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 <anton@samba.org>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4376d0751532595d76d8dbe9a7ddb6d92f08ff82
Author: Anton Blanchard <anton@samba.org>
Date:   Fri Mar 16 10:28:07 2012 +0000

    afs: Read of file returns EBADMSG

    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 <anton@samba.org>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4565db7fa0694572ac50b8615c7ac3dc936e012
Author: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Date:   Fri Mar 16 17:08:39 2012 -0700

    nilfs2: fix NULL pointer dereference in nilfs_load_super_block()

    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: [<d0d7a08e>] nilfs_load_super_block+0x17e/0x280 [nilfs2]
     *pde = 00000000
     Oops: 0000 [#1] PREEMPT SMP
     ...
     Call Trace:
      [<d0d7a87b>] init_nilfs+0x4b/0x2e0 [nilfs2]
      [<d0d6f707>] nilfs_mount+0x447/0x5b0 [nilfs2]
      [<c0226636>] mount_fs+0x36/0x180
      [<c023d961>] vfs_kern_mount+0x51/0xa0
      [<c023ddae>] do_kern_mount+0x3e/0xe0
      [<c023f189>] do_mount+0x169/0x700
      [<c023fa9b>] sys_mount+0x6b/0xa0
      [<c04abd1f>] 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: [<d0d7a08e>] 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 <slicky.dvl@gmail.com>
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Tested-by: Slicky Devil <slicky.dvl@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>