commit c8375e7a5705364b525833b15f66138c90d0ad78 Author: Greg Kroah-Hartman Date: Wed Dec 21 13:05:40 2011 -0800 Linux 2.6.32.51 commit 0411b8e7f388630a965a0aedfae24be92a8bb36e Author: Krzysztof Hałasa Date: Mon Dec 12 14:51:00 2011 +0100 USB: cdc-acm: add IDs for Motorola H24 HSPA USB module. 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 commit a13bdfbbe9dbeeb2c1b21869448284e87a00640b Author: Andrea Arcangeli Date: Tue Dec 13 21:41:15 2011 -0500 ext4: avoid hangs in ext4_da_should_update_i_disksize() 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 commit 1c43963ace2abf1e3ad177ddbcd2b897351e6437 Author: Robert Richter Date: Tue Dec 13 00:40:36 2011 +0100 oprofile, x86: Fix crash when unloading module (timer mode) 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 commit 2d8df13be3358f028db8cf15726e35ee55b50349 Author: Robert Richter Date: Tue Dec 13 00:40:35 2011 +0100 oprofile, x86: Fix nmi-unsafe callgraph support 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 commit 1872856ac3ed878ec621a02573cff56491d9f410 Author: Xiao Guangrong Date: Tue Dec 13 00:40:34 2011 +0100 export __get_user_pages_fast() function 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 commit 34456bfafc2743a19eb148d56502f9a8c0dc6fcc Author: Phillip Lougher Date: Wed Nov 2 13:38:01 2011 -0700 hfs: fix hfs_find_init() sb->ext_tree NULL ptr oops 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 commit 6824291b4a7d2a9894acbb6a83a960e6e760c549 Author: Linus Torvalds Date: Mon Sep 19 17:04:37 2011 -0700 Make TASKSTATS require root access 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 commit 903846251193f6545fb3acd1a9a491626a4ed7ce Author: Eryu Guan Date: Tue Nov 1 19:04:59 2011 -0400 jbd/jbd2: validate sb->s_first in journal_get_superblock() commit 8762202dd0d6e46854f786bdb6fb3780a1625efe upstream. I hit a J_ASSERT(blocknr != 0) failure in cleanup_journal_tail() when mounting a fsfuzzed ext3 image. It turns out that the corrupted ext3 image has s_first = 0 in journal superblock, and the 0 is passed to journal->j_head in journal_reset(), then to blocknr in cleanup_journal_tail(), in the end the J_ASSERT failed. So validate s_first after reading journal superblock from disk in journal_get_superblock() to ensure s_first is valid. The following script could reproduce it: fstype=ext3 blocksize=1024 img=$fstype.img offset=0 found=0 magic="c0 3b 39 98" dd if=/dev/zero of=$img bs=1M count=8 mkfs -t $fstype -b $blocksize -F $img filesize=`stat -c %s $img` while [ $offset -lt $filesize ] do if od -j $offset -N 4 -t x1 $img | grep -i "$magic";then echo "Found journal: $offset" found=1 break fi offset=`echo "$offset+$blocksize" | bc` done if [ $found -ne 1 ];then echo "Magic \"$magic\" not found" exit 1 fi dd if=/dev/zero of=$img seek=$(($offset+23)) conv=notrunc bs=1 count=1 mkdir -p ./mnt mount -o loop $img ./mnt Cc: Jan Kara Signed-off-by: Eryu Guan Signed-off-by: "Theodore Ts'o" Cc: Moritz Mühlenhoff Signed-off-by: Greg Kroah-Hartman commit 2b8efc69f9d5254856024cb2e883fe9a99e20cf6 Author: Linus Torvalds Date: Mon Dec 12 22:06:55 2011 -0800 linux/log2.h: Fix rounddown_pow_of_two(1) commit 13c07b0286d340275f2d97adf085cecda37ede37 upstream. Exactly like roundup_pow_of_two(1), the rounddown version was buggy for the case of a compile-time constant '1' argument. Probably because it originated from the same code, sharing history with the roundup version from before the bugfix (for that one, see commit 1a06a52ee1b0: "Fix roundup_pow_of_two(1)"). However, unlike the roundup version, the fix for rounddown is to just remove the broken special case entirely. It's simply not needed - the generic code 1UL << ilog2(n) does the right thing for the constant '1' argment too. The only reason roundup needed that special case was because rounding up does so by subtracting one from the argument (and then adding one to the result) causing the obvious problems with "ilog2(0)". But rounddown doesn't do any of that, since ilog2() naturally truncates (ie "rounds down") to the right rounded down value. And without the ilog2(0) case, there's no reason for the special case that had the wrong value. tl;dr: rounddown_pow_of_two(1) should be 1, not 0. Acked-by: Dmitry Torokhov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 57cc6e02424b967f70a4270e4f059d3b9d684605 Author: Tushar Gohad Date: Thu Jul 28 10:36:20 2011 +0000 xfrm: Fix key lengths for rfc3686(ctr(aes)) commit 4203223a1aed862b4445fdcd260d6139603a51d9 upstream. Fix the min and max bit lengths for AES-CTR (RFC3686) keys. The number of bits in key spec is the key length (128/256) plus 32 bits of nonce. This change takes care of the "Invalid key length" errors reported by setkey when specifying 288 bit keys for aes-ctr. Signed-off-by: Tushar Gohad Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Calvin Owens Signed-off-by: Greg Kroah-Hartman commit f9da6299abdae16617736efb545079ddbfe2e380 Author: Tejun Heo Date: Fri Nov 18 10:55:35 2011 -0800 percpu: fix chunk range calculation commit a855b84c3d8c73220d4d3cd392a7bee7c83de70e upstream. Percpu allocator recorded the cpus which map to the first and last units in pcpu_first/last_unit_cpu respectively and used them to determine the address range of a chunk - e.g. it assumed that the first unit has the lowest address in a chunk while the last unit has the highest address. This simply isn't true. Groups in a chunk can have arbitrary positive or negative offsets from the previous one and there is no guarantee that the first unit occupies the lowest offset while the last one the highest. Fix it by actually comparing unit offsets to determine cpus occupying the lowest and highest offsets. Also, rename pcu_first/last_unit_cpu to pcpu_low/high_unit_cpu to avoid confusion. The chunk address range is used to flush cache on vmalloc area map/unmap and decide whether a given address is in the first chunk by per_cpu_ptr_to_phys() and the bug was discovered by invalid per_cpu_ptr_to_phys() translation for crash_note. Kudos to Dave Young for tracking down the problem. Signed-off-by: Tejun Heo Reported-by: WANG Cong Reported-by: Dave Young Tested-by: Dave Young LKML-Reference: <4EC21F67.10905@redhat.com> Signed-off-by: Thomas Renninger Signed-off-by: Greg Kroah-Hartman commit 41f7082e5996807f0f535a251f235f64ae3d00e1 Author: Robert Richter Date: Wed Dec 7 18:30:11 2011 +0100 oprofile: Fix locking dependency in sync_start() commit 130c5ce716c9bfd1c2a2ec840a746eb7ff9ce1e6 upstream. This fixes the A->B/B->A locking dependency, see the warning below. The function task_exit_notify() is called with (task_exit_notifier) .rwsem set and then calls sync_buffer() which locks buffer_mutex. In sync_start() the buffer_mutex was set to prevent notifier functions to be started before sync_start() is finished. But when registering the notifier, (task_exit_notifier).rwsem is locked too, but now in different order than in sync_buffer(). In theory this causes a locking dependency, what does not occur in practice since task_exit_notify() is always called after the notifier is registered which means the lock is already released. However, after checking the notifier functions it turned out the buffer_mutex in sync_start() is unnecessary. This is because sync_buffer() may be called from the notifiers even if sync_start() did not finish yet, the buffers are already allocated but empty. No need to protect this with the mutex. So we fix this theoretical locking dependency by removing buffer_mutex in sync_start(). This is similar to the implementation before commit: 750d857 oprofile: fix crash when accessing freed task structs which introduced the locking dependency. Lockdep warning: oprofiled/4447 is trying to acquire lock: (buffer_mutex){+.+...}, at: [] sync_buffer+0x31/0x3ec [oprofile] but task is already holding lock: ((task_exit_notifier).rwsem){++++..}, at: [] __blocking_notifier_call_chain+0x39/0x67 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 ((task_exit_notifier).rwsem){++++..}: [] lock_acquire+0xf8/0x11e [] down_write+0x44/0x67 [] blocking_notifier_chain_register+0x52/0x8b [] profile_event_register+0x2d/0x2f [] sync_start+0x47/0xc6 [oprofile] [] oprofile_setup+0x60/0xa5 [oprofile] [] event_buffer_open+0x59/0x8c [oprofile] [] __dentry_open+0x1eb/0x308 [] nameidata_to_filp+0x60/0x67 [] do_last+0x5be/0x6b2 [] path_openat+0xc7/0x360 [] do_filp_open+0x3d/0x8c [] do_sys_open+0x110/0x1a9 [] sys_open+0x20/0x22 [] system_call_fastpath+0x16/0x1b -> #0 (buffer_mutex){+.+...}: [] __lock_acquire+0x1085/0x1711 [] lock_acquire+0xf8/0x11e [] mutex_lock_nested+0x63/0x309 [] sync_buffer+0x31/0x3ec [oprofile] [] task_exit_notify+0x16/0x1a [oprofile] [] notifier_call_chain+0x37/0x63 [] __blocking_notifier_call_chain+0x50/0x67 [] blocking_notifier_call_chain+0x14/0x16 [] profile_task_exit+0x1a/0x1c [] do_exit+0x2a/0x6fc [] do_group_exit+0x83/0xae [] sys_exit_group+0x17/0x1b [] system_call_fastpath+0x16/0x1b other info that might help us debug this: 1 lock held by oprofiled/4447: #0: ((task_exit_notifier).rwsem){++++..}, at: [] __blocking_notifier_call_chain+0x39/0x67 stack backtrace: Pid: 4447, comm: oprofiled Not tainted 2.6.39-00007-gcf4d8d4 #10 Call Trace: [] print_circular_bug+0xae/0xbc [] __lock_acquire+0x1085/0x1711 [] ? sync_buffer+0x31/0x3ec [oprofile] [] lock_acquire+0xf8/0x11e [] ? sync_buffer+0x31/0x3ec [oprofile] [] ? mark_lock+0x42f/0x552 [] ? sync_buffer+0x31/0x3ec [oprofile] [] mutex_lock_nested+0x63/0x309 [] ? sync_buffer+0x31/0x3ec [oprofile] [] sync_buffer+0x31/0x3ec [oprofile] [] ? __blocking_notifier_call_chain+0x39/0x67 [] ? __blocking_notifier_call_chain+0x39/0x67 [] task_exit_notify+0x16/0x1a [oprofile] [] notifier_call_chain+0x37/0x63 [] __blocking_notifier_call_chain+0x50/0x67 [] blocking_notifier_call_chain+0x14/0x16 [] profile_task_exit+0x1a/0x1c [] do_exit+0x2a/0x6fc [] ? retint_swapgs+0xe/0x13 [] do_group_exit+0x83/0xae [] sys_exit_group+0x17/0x1b [] system_call_fastpath+0x16/0x1b Reported-by: Marcin Slusarz Cc: Carl Love Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit 0faa8aa92a6fe975a8315c703999d2e3a250d370 Author: Robert Richter Date: Wed Dec 7 18:30:10 2011 +0100 oprofile: Free potentially owned tasks in case of errors commit 6ac6519b93065625119a347be1cbcc1b89edb773 upstream. After registering the task free notifier we possibly have tasks in our dying_tasks list. Free them after unregistering the notifier in case of an error. Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit 372dfcdb6d71bb4d8a922a70d64702fc9e5792d4 Author: Hans Verkuil Date: Mon Nov 14 19:20:49 2011 +0100 ARM: davinci: dm646x evm: wrong register used in setup_vpif_input_channel_mode commit 83713fc9373be2e943f82e9d36213708c6b0050e upstream. The function setup_vpif_input_channel_mode() used the VSCLKDIS register instead of VIDCLKCTL. This meant that when in HD mode videoport channel 0 used a different clock from channel 1. Clearly a copy-and-paste error. Signed-off-by: Hans Verkuil Acked-by: Manjunath Hadli Signed-off-by: Sekhar Nori Signed-off-by: Greg Kroah-Hartman commit 0f215d5b6bfd70c926569b41e696a35c54fd7bd3 Author: Takashi Iwai Date: Fri Dec 2 15:29:12 2011 +0100 ALSA: hda/realtek - Fix Oops in alc_mux_select() commit cce4aa378a049f4275416ee6302dd24f37b289df upstream. When no imux is available (e.g. a single capture source), alc_auto_init_input_src() may trigger an Oops due to the access to -1. Add a proper zero-check to avoid it. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d21de8b14ac52b2be0b86435a966aa8e568f853e Author: David Dillow Date: Thu Dec 1 23:26:53 2011 -0500 ALSA: sis7019 - give slow codecs more time to reset commit fc084e0b930d546872ab23667052499f7daf0fed upstream. There are some AC97 codec and board combinations that have been observed to take a very long time to respond after the cold reset has completed. In one case, more than 350 ms was required. To allow users to have sound on those platforms, we'll wait up to 500ms for the codec to become ready. As a board may have multiple codecs, with some faster than others to reset, we add a module parameter to inform the driver which codecs should be present. Reported-by: KotCzarny Signed-off-by: David Dillow Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman