commit 02905906ddc049720ded93ded03bbc2652f4646a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri Mar 23 13:54:45 2012 -0700
Linux 3.2.13
commit 8d7548704a1a6b6dacd6b458897007de80a820b3
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 a4599a9b8c0189e7db0ca426f107e2c0d1f472bd
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 3634665532be2d0b3281e9a6a9159dfa7f1d699d
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 cc28ae50b8dad51b597d56b74004c3be46c34406
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 74ace0235c443b01852a226558a262925fe5348d
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Wed Mar 14 12:29:29 2012 -0300
perf tools: Use scnprintf where applicable
commit e7f01d1e3d8d501deb8abeaa269d5d48a703b8b0 upstream.
Several places were expecting that the value returned was the number of
characters printed, not what would be printed if there was space.
Fix it by using the scnprintf and vscnprintf variants we inherited from
the kernel sources.
Some corner cases where the number of printed characters were not
accounted were fixed too.
Reported-by: Anton Blanchard <anton@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Eric B Munson <emunson@mgebm.net>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Link: http://lkml.kernel.org/n/tip-kwxo2eh29cxmd8ilixi2005x@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 460e2faa3a051fa4cb3aacb6ef47c71845bcf6bb
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 a3e7dddf9d7dd2e98f015b96afa343da370e8468
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 3b17e8051322d7ea54e6548606b9eb3a2d694919
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 6637749c3700e68ce8d5f28a096327e8b1d5b9ab
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>