linux-toradex.git, branch v2.6.32.52

Linux 2.6.32.52

2012-01-03T17:51:09+00:00

Revert "clockevents: Set noop handler in clockevents_exchange_device()"

2012-01-03T17:49:22+00:00

commit 3b87487ac5008072f138953b07505a7e3493327f upstream.

This reverts commit de28f25e8244c7353abed8de0c7792f5f883588c.

It results in resume problems for various people. See for example

  http://thread.gmane.org/gmane.linux.kernel/1233033
  http://thread.gmane.org/gmane.linux.kernel/1233389
  http://thread.gmane.org/gmane.linux.kernel/1233159
  http://thread.gmane.org/gmane.linux.kernel/1227868/focus=1230877

and the fedora and ubuntu bug reports

  https://bugzilla.redhat.com/show_bug.cgi?id=767248
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569

which got bisected down to the stable version of this commit.

Reported-by: Jonathan Nieder 
Reported-by: Phil Miller 
Reported-by: Philip Langdale 
Reported-by: Tim Gardner 
Cc: Thomas Gleixner 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Linux 2.6.32.51

2011-12-21T21:05:40+00:00

USB: cdc-acm: add IDs for Motorola H24 HSPA USB module.

2011-12-21T21:04:55+00:00

commit 6abff5dc4d5a2c90e597137ce8987e7fd439259b upstream.

Add USB IDs for Motorola H24 HSPA USB module.

Signed-off-by: Krzysztof Hałasa 
Acked-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman

ext4: avoid hangs in ext4_da_should_update_i_disksize()

2011-12-21T21:04:55+00:00

commit ea51d132dbf9b00063169c1159bee253d9649224 upstream.

If the pte mapping in generic_perform_write() is unmapped between
iov_iter_fault_in_readable() and iov_iter_copy_from_user_atomic(), the
"copied" parameter to ->end_write can be zero. ext4 couldn't cope with
it with delayed allocations enabled. This skips the i_disksize
enlargement logic if copied is zero and no new data was appeneded to
the inode.

 gdb> bt
 #0  0xffffffff811afe80 in ext4_da_should_update_i_disksize (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x1\
 08000, len=0x1000, copied=0x0, page=0xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2467
 #1  ext4_da_write_end (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x108000, len=0x1000, copied=0x0, page=0\
 xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2512
 #2  0xffffffff810d97f1 in generic_perform_write (iocb=, iov=, nr_segs=, pos=0x108000, ppos=0xffff88001e26be40, count=, written=0x0) at mm/filemap.c:2440
 #3  generic_file_buffered_write (iocb=, iov=, nr_segs=, p\
 os=0x108000, ppos=0xffff88001e26be40, count=, written=0x0) at mm/filemap.c:2482
 #4  0xffffffff810db5d1 in __generic_file_aio_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=0x1, ppos=0\
 xffff88001e26be40) at mm/filemap.c:2600
 #5  0xffffffff810db853 in generic_file_aio_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=, pos=) at mm/filemap.c:2632
 #6  0xffffffff811a71aa in ext4_file_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=0x1, pos=0x108000) a\
 t fs/ext4/file.c:136
 #7  0xffffffff811375aa in do_sync_write (filp=0xffff88003f606a80, buf=, len=, \
 ppos=0xffff88001e26bf48) at fs/read_write.c:406
 #8  0xffffffff81137e56 in vfs_write (file=0xffff88003f606a80, buf=0x1ec2960 , count=0x4\
 000, pos=0xffff88001e26bf48) at fs/read_write.c:435
 #9  0xffffffff8113816c in sys_write (fd=, buf=0x1ec2960 , count=0x\
 4000) at fs/read_write.c:487
 #10 
 #11 0x00007f120077a390 in __brk_reservation_fn_dmi_alloc__ ()
 #12 0x0000000000000000 in ?? ()
 gdb> print offset
 $22 = 0xffffffffffffffff
 gdb> print idx
 $23 = 0xffffffff
 gdb> print inode->i_blkbits
 $24 = 0xc
 gdb> up
 #1  ext4_da_write_end (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x108000, len=0x1000, copied=0x0, page=0\
 xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2512
 2512                    if (ext4_da_should_update_i_disksize(page, end)) {
 gdb> print start
 $25 = 0x0
 gdb> print end
 $26 = 0xffffffffffffffff
 gdb> print pos
 $27 = 0x108000
 gdb> print new_i_size
 $28 = 0x108000
 gdb> print ((struct ext4_inode_info *)((char *)inode-((int)(&((struct ext4_inode_info *)0)->vfs_inode))))->i_disksize
 $29 = 0xd9000
 gdb> down
 2467            for (i = 0; i < idx; i++)
 gdb> print i
 $30 = 0xd44acbee

This is 100% reproducible with some autonuma development code tuned in
a very aggressive manner (not normal way even for knumad) which does
"exotic" changes to the ptes. It wouldn't normally trigger but I don't
see why it can't happen normally if the page is added to swap cache in
between the two faults leading to "copied" being zero (which then
hangs in ext4). So it should be fixed. Especially possible with lumpy
reclaim (albeit disabled if compaction is enabled) as that would
ignore the young bits in the ptes.

Signed-off-by: Andrea Arcangeli 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

oprofile, x86: Fix crash when unloading module (timer mode)

2011-12-21T21:04:54+00:00

Based on 97f7f81 oprofile, x86: Fix crash when unloading module (nmi timer
mode) upstream.

Fix for stable kernels v2.6.28.y to v2.6.34.y. This patch is for .32.

Oprofile crashs while unlaoding modules and if in timer mode. Timer
mode is the fallback if the architectural initialization fails. The
pointer variable model is then used uninitialzied during exit causing
a NULL pointer dereference.

It can be triggered with kernel parameters oprofile.timer=1 nolapic
used. Happens esp. in virtual machine environments.

oprofile: using timer interrupt.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
IP: [] op_nmi_exit+0x3d/0x4a [oprofile]
PGD 42ac5e067 PUD 42ac5d067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/module/oprofile/refcnt
CPU 0
Modules linked in: oprofile(-)
Pid: 2245, comm: modprobe Not tainted 2.6.32.21-oprofile-x86_64-debug-00038-gf4db115 #69 Anaheim
RIP: 0010:[]  [] op_nmi_exit+0x3d/0x4a [oprofile]
RSP: 0018:ffff88042d4f9ec8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffffffa0005590 RCX: ffff88042d4f9ea8
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
RBP: ffff88042d4f9ec8 R08: ffff88042d4f9ee8 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000080
R13: 00000000fffffff5 R14: 0000000000000001 R15: 00000000006101e0
FS:  00007fef6ac9c700(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000028 CR3: 000000042ac60000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 2245, threadinfo ffff88042d4f8000, task ffff88042cd66040)
Stack:
 ffff88042d4f9ed8 ffffffffa0002096 ffff88042d4f9ee8 ffffffffa0003bbb
<0> ffff88042d4f9f78 ffffffff810748ad 656c69666f72706f 00007fff77a07800
<0> ffff88042d4f9f28 ffffffff81068414 000000000060f180 0000000000000000
Call Trace:
 [] oprofile_arch_exit+0xe/0x10 [oprofile]
 [] oprofile_exit+0x13/0x15 [oprofile]
 [] sys_delete_module+0x1cd/0x244
 [] ? trace_hardirqs_on_caller+0x114/0x13f
 [] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [] system_call_fastpath+0x16/0x1b
Code: 48 c7 c7 90 4e 00 a0 e8 e7 15 22 e1 48 c7 c7 e0 4e 00 a0 e8 bd 18 22 e1 48 c7 c7 70 4e 00 a0 e8 94 4e 41 e1 48 8b 05 d1 39 00 00 <48> 8b 40 28 48 85 c0 74 02 ff d0 c9 c3 55 48 89 e5 e8 cb 88 00
RIP  [] op_nmi_exit+0x3d/0x4a [oprofile]
 RSP 
CR2: 0000000000000028
---[ end trace 18b12420ceb19193 ]---

Signed-off-by: Robert Richter 
Signed-off-by: Greg Kroah-Hartman

oprofile, x86: Fix nmi-unsafe callgraph support

2011-12-21T21:04:54+00:00

commit a0e3e70243f5b270bc3eca718f0a9fa5e6b8262e upstream.

Backport for stable kernel v2.6.32.y to v2.6.36.y.

Current oprofile's x86 callgraph support may trigger page faults
throwing the BUG_ON(in_nmi()) message below. This patch fixes this by
using the same nmi-safe copy-from-user code as in perf.

------------[ cut here ]------------
kernel BUG at .../arch/x86/kernel/traps.c:436!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:0a.0/0000:07:00.0/0000:08:04.0/net/eth0/broadcast
CPU 5
Modules linked in:

Pid: 8611, comm: opcontrol Not tainted 2.6.39-00007-gfe47ae7 #1 Advanced Micro Device Anaheim/Anaheim
RIP: 0010:[]  [] do_nmi+0x22/0x1ee
RSP: 0000:ffff88042fd47f28  EFLAGS: 00010002
RAX: ffff88042c0a7fd8 RBX: 0000000000000001 RCX: 00000000c0000101
RDX: 00000000ffff8804 RSI: ffffffffffffffff RDI: ffff88042fd47f58
RBP: ffff88042fd47f48 R08: 0000000000000004 R09: 0000000000001484
R10: 0000000000000001 R11: 0000000000000000 R12: ffff88042fd47f58
R13: 0000000000000000 R14: ffff88042fd47d98 R15: 0000000000000020
FS:  00007fca25e56700(0000) GS:ffff88042fd40000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000074 CR3: 000000042d28b000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process opcontrol (pid: 8611, threadinfo ffff88042c0a6000, task ffff88042c532310)
Stack:
 0000000000000000 0000000000000001 ffff88042c0a7fd8 0000000000000000
 ffff88042fd47de8 ffffffff813e897a 0000000000000020 ffff88042fd47d98
 0000000000000000 ffff88042c0a7fd8 ffff88042fd47de8 0000000000000074
Call Trace:
 
 [] nmi+0x1a/0x20
 [] ? bad_to_user+0x25/0x771
 <>
Code: ff 59 5b 41 5c 41 5d c9 c3 55 65 48 8b 04 25 88 b5 00 00 48 89 e5 41 55 41 54 49 89 fc 53 48 83 ec 08 f6 80 47 e0 ff ff 04 74 04 <0f> 0b eb fe 81 80 44 e0 ff ff 00 00 01 04 65 ff 04 25 c4 0f 01
RIP  [] do_nmi+0x22/0x1ee
 RSP 
---[ end trace ed6752185092104b ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 8611, comm: opcontrol Tainted: G      D     2.6.39-00007-gfe47ae7 #1
Call Trace:
   [] panic+0x8c/0x188
 [] oops_end+0x81/0x8e
 [] die+0x55/0x5e
 [] do_trap+0x11c/0x12b
 [] do_invalid_op+0x91/0x9a
 [] ? do_nmi+0x22/0x1ee
 [] ? oprofile_add_sample+0x83/0x95
 [] ? op_amd_check_ctrs+0x4f/0x2cf
 [] invalid_op+0x15/0x20
 [] ? do_nmi+0x22/0x1ee
 [] ? do_nmi+0x67/0x1ee
 [] nmi+0x1a/0x20
 [] ? bad_to_user+0x25/0x771
 <>

Cc: John Lumby 
Cc: Maynard Johnson 
Signed-off-by: Robert Richter 
Signed-off-by: Greg Kroah-Hartman

export __get_user_pages_fast() function

2011-12-21T21:04:54+00:00

commit 45888a0c6edc305495b6bd72a30e66bc40b324c6 upstream.

Backport for stable kernel v2.6.32.y to v2.6.36.y.

Needed for next patch:

 oprofile, x86: Fix nmi-unsafe callgraph support

This function is used by KVM to pin process's page in the atomic context.

Define the 'weak' function to avoid other architecture not support it

Acked-by: Nick Piggin 
Signed-off-by: Xiao Guangrong 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Robert Richter 
Signed-off-by: Greg Kroah-Hartman

hfs: fix hfs_find_init() sb->ext_tree NULL ptr oops

2011-12-21T21:04:53+00:00

commit 434a964daa14b9db083ce20404a4a2add54d037a upstream.

Clement Lecigne reports a filesystem which causes a kernel oops in
hfs_find_init() trying to dereference sb->ext_tree which is NULL.

This proves to be because the filesystem has a corrupted MDB extent
record, where the extents file does not fit into the first three extents
in the file record (the first blocks).

In hfs_get_block() when looking up the blocks for the extent file
(HFS_EXT_CNID), it fails the first blocks special case, and falls
through to the extent code (which ultimately calls hfs_find_init())
which is in the process of being initialised.

Hfs avoids this scenario by always having the extents b-tree fitting
into the first blocks (the extents B-tree can't have overflow extents).

The fix is to check at mount time that the B-tree fits into first
blocks, i.e.  fail if HFS_I(inode)->alloc_blocks >=
HFS_I(inode)->first_blocks

Note, the existing commit 47f365eb57573 ("hfs: fix oops on mount with
corrupted btree extent records") becomes subsumed into this as a special
case, but only for the extents B-tree (HFS_EXT_CNID), it is perfectly
acceptable for the catalog B-Tree file to grow beyond three extents,
with the remaining extent descriptors in the extents overfow.

This fixes CVE-2011-2203

Reported-by: Clement LECIGNE 
Signed-off-by: Phillip Lougher 
Cc: Jeff Mahoney 
Cc: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Moritz Mühlenhoff 
Signed-off-by: Greg Kroah-Hartman

Make TASKSTATS require root access

2011-12-21T21:04:53+00:00

commit 1a51410abe7d0ee4b1d112780f46df87d3621043 upstream.

Ok, this isn't optimal, since it means that 'iotop' needs admin
capabilities, and we may have to work on this some more.  But at the
same time it is very much not acceptable to let anybody just read
anybody elses IO statistics quite at this level.

Use of the GENL_ADMIN_PERM suggested by Johannes Berg as an alternative
to checking the capabilities by hand.

Reported-by: Vasiliy Kulikov 
Cc: Johannes Berg 
Acked-by: Balbir Singh 
Signed-off-by: Linus Torvalds 
Cc: Moritz Mühlenhoff 
Signed-off-by: Greg Kroah-Hartman