commit c12a2ff7096edca9f610ef813253c1bceeb2800d Author: Paul Gortmaker Date: Wed Jan 16 16:55:31 2013 -0500 Linux 2.6.34.14 Signed-off-by: Paul Gortmaker commit 02ce77862d85f8a87e56fdba5c237cd3dfc43a3f Author: Matthew Garrett Date: Wed Jul 6 16:52:37 2011 -0400 x86: Don't use the EFI reboot method by default commit f70e957cda22d309c769805cbb932407a5232219 upstream. Testing suggests that at least some Lenovos and some Intels will fail to reboot via EFI, attempting to jump to an unmapped physical address. In the long run we could handle this by providing a page table with a 1:1 mapping of physical addresses, but for now it's probably just easier to assume that ACPI or legacy methods will be present and reboot via those. Signed-off-by: Matthew Garrett Cc: Linus Torvalds Cc: Andrew Morton Cc: Alan Cox Link: http://lkml.kernel.org/r/1309985557-15350-1-git-send-email-mjg@redhat.com Signed-off-by: Ingo Molnar [PG: in 2.6.34, file is x86/platform/efi/efi.c --> x86/kernel/efi.c] Signed-off-by: Paul Gortmaker commit f9f3d329a6370e2cbc6b34a2c290dc8cf0fd76a4 Author: Richard Weinberger Date: Tue May 24 00:18:05 2011 +0200 x86: Get rid of asmregparm commit 1b4ac2a935aaf194241a2f4165d6407ba9650e1a upstream. As UML does no longer need asmregparm we can remove it. Signed-off-by: Richard Weinberger Cc: namhyung@gmail.com Cc: davem@davemloft.net Cc: fweisbec@gmail.com Cc: dhowells@redhat.com Link: http://lkml.kernel.org/r/%3C1306189085-29896-1-git-send-email-richard%40nod.at%3E Signed-off-by: Thomas Gleixner Signed-off-by: Paul Gortmaker commit 2e2f176b4ee36570a247e13d6de4314ab96def0b Author: Richard Weinberger Date: Mon May 23 22:51:33 2011 +0200 um: Use RWSEM_GENERIC_SPINLOCK on x86 commit 3a3679078aed2c451ebc32836bbd3b8219a65e01 upstream. Commit d12337 (rwsem: Remove redundant asmregparm annotation) broke rwsem on UML. As we cannot compile UML with -mregparm=3 and keeping asmregparm only for UML is inadequate the easiest solution is using RWSEM_GENERIC_SPINLOCK. Thanks to Thomas Gleixner for the idea. Reported-by: Toralf Förster Tested-by: Toralf Förster Signed-off-by: Richard Weinberger Cc: user-mode-linux-devel@lists.sourceforge.net Link: http://lkml.kernel.org/r/%3C1306183893-26655-1-git-send-email-richard%40nod.at%3E Signed-off-by: Thomas Gleixner Signed-off-by: Paul Gortmaker commit 0b6a58d3ea8df7608d690819176ef195ec428f6b Author: Thomas Gleixner Date: Wed Jan 26 21:32:01 2011 +0100 rwsem: Remove redundant asmregparm annotation commit d123375425d7df4b6081a631fc1203fceafa59b2 upstream. Peter Zijlstra pointed out, that the only user of asmregparm (x86) is compiling the kernel already with -mregparm=3. So the annotation of the rwsem functions is redundant. Remove it. Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Cc: David Howells Cc: Benjamin Herrenschmidt Cc: Matt Turner Cc: Tony Luck Cc: Heiko Carstens Cc: Paul Mundt Cc: David Miller Cc: Chris Zankel LKML-Reference: Signed-off-by: Thomas Gleixner [PG: fixes compile errors when using newer gcc on 2.6.34 baseline] Signed-off-by: Paul Gortmaker commit aea328d332e3d132dcaa9b258bc16f4c4f002192 Author: Chanho Min Date: Thu Jan 5 20:00:19 2012 +0900 sched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW commit cb297a3e433dbdcf7ad81e0564e7b804c941ff0d upstream. This issue happens under the following conditions: 1. preemption is off 2. __ARCH_WANT_INTERRUPTS_ON_CTXSW is defined 3. RT scheduling class 4. SMP system Sequence is as follows: 1.suppose current task is A. start schedule() 2.task A is enqueued pushable task at the entry of schedule() __schedule prev = rq->curr; ... put_prev_task put_prev_task_rt enqueue_pushable_task 4.pick the task B as next task. next = pick_next_task(rq); 3.rq->curr set to task B and context_switch is started. rq->curr = next; 4.At the entry of context_swtich, release this cpu's rq->lock. context_switch prepare_task_switch prepare_lock_switch raw_spin_unlock_irq(&rq->lock); 5.Shortly after rq->lock is released, interrupt is occurred and start IRQ context 6.try_to_wake_up() which called by ISR acquires rq->lock try_to_wake_up ttwu_remote rq = __task_rq_lock(p) ttwu_do_wakeup(rq, p, wake_flags); task_woken_rt 7.push_rt_task picks the task A which is enqueued before. task_woken_rt push_rt_tasks(rq) next_task = pick_next_pushable_task(rq) 8.At find_lock_lowest_rq(), If double_lock_balance() returns 0, lowest_rq can be the remote rq. (But,If preemption is on, double_lock_balance always return 1 and it does't happen.) push_rt_task find_lock_lowest_rq if (double_lock_balance(rq, lowest_rq)).. 9.find_lock_lowest_rq return the available rq. task A is migrated to the remote cpu/rq. push_rt_task ... deactivate_task(rq, next_task, 0); set_task_cpu(next_task, lowest_rq->cpu); activate_task(lowest_rq, next_task, 0); 10. But, task A is on irq context at this cpu. So, task A is scheduled by two cpus at the same time until restore from IRQ. Task A's stack is corrupted. To fix it, don't migrate an RT task if it's still running. Signed-off-by: Chanho Min Signed-off-by: Peter Zijlstra Acked-by: Steven Rostedt Link: http://lkml.kernel.org/r/CAOAMb1BHA=5fm7KTewYyke6u-8DP0iUuJMpgQw54vNeXFsGpoQ@mail.gmail.com Signed-off-by: Ingo Molnar [PG: in 2.6.34, sched/rt.c is just sched_rt.c] Signed-off-by: Paul Gortmaker commit 67edd8ef996168b7dbbdc00d1ce483b2b76cea5a Author: Eric W. Biederman Date: Sat Jan 29 14:57:22 2011 +0000 net: Fix ip link add netns oops commit 13ad17745c2cbd437d9e24b2d97393e0be11c439 upstream. Ed Swierk writes: > On 2.6.35.7 > ip link add link eth0 netns 9999 type macvlan > where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang: > [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d > [10663.821917] IP: [] __dev_alloc_name+0x9a/0x170 > [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0 > [10663.821944] Oops: 0000 [#1] SMP > [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > [10663.821959] CPU 3 > [10663.821963] Modules linked in: macvlan ip6table_filter ip6_tables rfcomm ipt_MASQUERADE binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack sco ipt_REJECT bnep l2cap xt_tcpudp iptable_filter ip_tables x_tables bridge stp vboxnetadp vboxnetflt vboxdrv kvm_intel kvm parport_pc ppdev snd_hda_codec_intelhdmi snd_hda_codec_conexant arc4 iwlagn iwlcore mac80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi i915 snd_seq_midi_event snd_seq thinkpad_acpi drm_kms_helper btusb tpm_tis nvram uvcvideo snd_timer snd_seq_device bluetooth videodev v4l1_compat v4l2_compat_ioctl32 tpm drm tpm_bios snd cfg80211 psmouse serio_raw intel_ips soundcore snd_page_alloc intel_agp i2c_algo_bit video output netconsole configfs lp parport usbhid hid e1000e sdhci_pci ahci libahci sdhci led_class > [10663.822155] > [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO > [10663.822167] RIP: 0010:[] [] __dev_alloc_name+0x9a/0x170 > [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286 > [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000 > [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000 > [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041 > [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818 > [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000 > [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000 > [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0 > [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0) > [10663.822236] Stack: > [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6 > [10663.822251] <0> 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818 > [10663.822265] <0> ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413 > [10663.822281] Call Trace: > [10663.822290] [] ? dev_addr_init+0x75/0xb0 > [10663.822298] [] dev_alloc_name+0x43/0x90 > [10663.822307] [] rtnl_create_link+0xbe/0x1b0 > [10663.822314] [] rtnl_newlink+0x48a/0x570 > [10663.822321] [] ? rtnl_newlink+0x1ac/0x570 > [10663.822332] [] ? native_x2apic_icr_read+0x4/0x20 > [10663.822339] [] rtnetlink_rcv_msg+0x177/0x290 > [10663.822346] [] ? rtnetlink_rcv_msg+0x0/0x290 > [10663.822354] [] netlink_rcv_skb+0xa9/0xd0 > [10663.822360] [] rtnetlink_rcv+0x25/0x40 > [10663.822367] [] netlink_unicast+0x2de/0x2f0 > [10663.822374] [] netlink_sendmsg+0x1fe/0x2e0 > [10663.822383] [] sock_sendmsg+0xf3/0x120 > [10663.822391] [] ? _raw_spin_lock+0xe/0x20 > [10663.822400] [] ? __d_lookup+0x136/0x150 > [10663.822406] [] ? _raw_spin_lock+0xe/0x20 > [10663.822414] [] ? _atomic_dec_and_lock+0x4d/0x80 > [10663.822422] [] ? mntput_no_expire+0x30/0x110 > [10663.822429] [] ? move_addr_to_kernel+0x65/0x70 > [10663.822435] [] ? verify_iovec+0x88/0xe0 > [10663.822442] [] sys_sendmsg+0x240/0x3a0 > [10663.822450] [] ? __do_fault+0x479/0x560 > [10663.822457] [] ? _raw_spin_lock+0xe/0x20 > [10663.822465] [] ? alloc_fd+0x10a/0x150 > [10663.822473] [] ? do_page_fault+0x15e/0x350 > [10663.822482] [] system_call_fastpath+0x16/0x1b > [10663.822487] Code: 90 48 8d 78 02 be 25 00 00 00 e8 92 1d e2 ff 48 85 c0 75 cf bf 20 00 00 00 e8 c3 b1 c6 ff 49 89 c7 b8 f4 ff ff ff 4d 85 ff 74 bd <4d> 8b 75 70 49 8d 45 70 48 89 45 b8 49 83 ee 58 eb 28 48 8d 55 > [10663.822618] RIP [] __dev_alloc_name+0x9a/0x170 > [10663.822627] RSP > [10663.822631] CR2: 000000000000006d > [10663.822636] ---[ end trace 3dfd6c3ad5327ca7 ]--- This bug was introduced in: commit 81adee47dfb608df3ad0b91d230fb3cef75f0060 Author: Eric W. Biederman Date: Sun Nov 8 00:53:51 2009 -0800 net: Support specifying the network namespace upon device creation. There is no good reason to not support userspace specifying the network namespace during device creation, and it makes it easier to create a network device and pass it to a child network namespace with a well known name. We have to be careful to ensure that the target network namespace for the new device exists through the life of the call. To keep that logic clear I have factored out the network namespace grabbing logic into rtnl_link_get_net. In addtion we need to continue to pass the source network namespace to the rtnl_link_ops.newlink method so that we can find the base device source network namespace. Signed-off-by: Eric W. Biederman Acked-by: Eric Dumazet Where apparently I forgot to add error handling to the path where we create a new network device in a new network namespace, and pass in an invalid pid. Reported-by: Ed Swierk Signed-off-by: "Eric W. Biederman" Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 7790e85f5395fe8015cd59dd45e86bd9425d6193 Author: Will Deacon Date: Fri Aug 10 15:22:09 2012 +0100 mutex: Place lock in contended state after fastpath_lock failure commit 0bce9c46bf3b15f485d82d7e81dabed6ebcc24b1 upstream. ARM recently moved to asm-generic/mutex-xchg.h for its mutex implementation after the previous implementation was found to be missing some crucial memory barriers. However, this has revealed some problems running hackbench on SMP platforms due to the way in which the MUTEX_SPIN_ON_OWNER code operates. The symptoms are that a bunch of hackbench tasks are left waiting on an unlocked mutex and therefore never get woken up to claim it. This boils down to the following sequence of events: Task A Task B Task C Lock value 0 1 1 lock() 0 2 lock() 0 3 spin(A) 0 4 unlock() 1 5 lock() 0 6 cmpxchg(1,0) 0 7 contended() -1 8 lock() 0 9 spin(C) 0 10 unlock() 1 11 cmpxchg(1,0) 0 12 unlock() 1 At this point, the lock is unlocked, but Task B is in an uninterruptible sleep with nobody to wake it up. This patch fixes the problem by ensuring we put the lock into the contended state if we fail to acquire it on the fastpath, ensuring that any blocked waiters are woken up when the mutex is released. Signed-off-by: Will Deacon Cc: Arnd Bergmann Cc: Chris Mason Cc: Ingo Molnar Cc: Reviewed-by: Nicolas Pitre Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/n/tip-6e9lrw2avczr0617fzl5vqb8@git.kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Paul Gortmaker commit db379e212d8a9431ae296e80f5ddb597afed4996 Author: Stanislaw Gruszka Date: Wed Aug 8 11:27:15 2012 +0200 sched: fix divide by zero at {thread_group,task}_times commit bea6832cc8c4a0a9a65dd17da6aaa657fe27bc3e upstream. On architectures where cputime_t is 64 bit type, is possible to trigger divide by zero on do_div(temp, (__force u32) total) line, if total is a non zero number but has lower 32 bit's zeroed. Removing casting is not a good solution since some do_div() implementations do cast to u32 internally. This problem can be triggered in practice on very long lived processes: PID: 2331 TASK: ffff880472814b00 CPU: 2 COMMAND: "oraagent.bin" #0 [ffff880472a51b70] machine_kexec at ffffffff8103214b #1 [ffff880472a51bd0] crash_kexec at ffffffff810b91c2 #2 [ffff880472a51ca0] oops_end at ffffffff814f0b00 #3 [ffff880472a51cd0] die at ffffffff8100f26b #4 [ffff880472a51d00] do_trap at ffffffff814f03f4 #5 [ffff880472a51d60] do_divide_error at ffffffff8100cfff #6 [ffff880472a51e00] divide_error at ffffffff8100be7b [exception RIP: thread_group_times+0x56] RIP: ffffffff81056a16 RSP: ffff880472a51eb8 RFLAGS: 00010046 RAX: bc3572c9fe12d194 RBX: ffff880874150800 RCX: 0000000110266fad RDX: 0000000000000000 RSI: ffff880472a51eb8 RDI: 001038ae7d9633dc RBP: ffff880472a51ef8 R8: 00000000b10a3a64 R9: ffff880874150800 R10: 00007fcba27ab680 R11: 0000000000000202 R12: ffff880472a51f08 R13: ffff880472a51f10 R14: 0000000000000000 R15: 0000000000000007 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff880472a51f00] do_sys_times at ffffffff8108845d #8 [ffff880472a51f40] sys_times at ffffffff81088524 #9 [ffff880472a51f80] system_call_fastpath at ffffffff8100b0f2 RIP: 0000003808caac3a RSP: 00007fcba27ab6d8 RFLAGS: 00000202 RAX: 0000000000000064 RBX: ffffffff8100b0f2 RCX: 0000000000000000 RDX: 00007fcba27ab6e0 RSI: 000000000076d58e RDI: 00007fcba27ab6e0 RBP: 00007fcba27ab700 R8: 0000000000000020 R9: 000000000000091b R10: 00007fcba27ab680 R11: 0000000000000202 R12: 00007fff9ca41940 R13: 0000000000000000 R14: 00007fcba27ac9c0 R15: 00007fff9ca41940 ORIG_RAX: 0000000000000064 CS: 0033 SS: 002b Signed-off-by: Stanislaw Gruszka Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/20120808092714.GA3580@redhat.com Signed-off-by: Thomas Gleixner [PG: sched/core.c is just sched.c in 2.6.34; also the do_div() on __force u32 isn't explicitly seen since that is in v3.3-rc1~191^2~11] Signed-off-by: Paul Gortmaker commit ebc8f5c86a76386df6ca4e335f6f504e218eead4 Author: Peter Zijlstra Date: Tue Mar 15 14:37:10 2011 +0100 perf: Fix tear-down of inherited group events commit 38b435b16c36b0d863efcf3f07b34a6fac9873fd upstream. When destroying inherited events, we need to destroy groups too, otherwise the event iteration in perf_event_exit_task_context() will miss group siblings and we leak events with all the consequences. Reported-and-tested-by: Vince Weaver Signed-off-by: Peter Zijlstra LKML-Reference: <1300196470.2203.61.camel@twins> Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit e732ebc42aea321ee84514330eb3a675307fcc83 Author: Peter Zijlstra Date: Thu May 27 15:47:49 2010 +0200 perf_events: Fix races in group composition commit 8a49542c0554af7d0073aac0ee73ee65b807ef34 upstream. Group siblings don't pin each-other or the parent, so when we destroy events we must make sure to clean up all cross referencing pointers. In particular, for destruction of a group leader we must be able to find all its siblings and remove their reference to it. This means that detaching an event from its context must not detach it from the group, otherwise we can end up failing to clear all pointers. Solve this by clearly separating the attachment to a context and attachment to a group, and keep the group composed until we destroy the events. Signed-off-by: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 9cb08e9f1df7113af1cf28534d73ef3adb419017 Author: Jan Kiszka Date: Wed Dec 14 19:25:13 2011 +0100 KVM: x86: Prevent starting PIT timers in the absence of irqchip support commit 0924ab2cfa98b1ece26c033d696651fd62896c69 upstream. User space may create the PIT and forgets about setting up the irqchips. In that case, firing PIT IRQs will crash the host: BUG: unable to handle kernel NULL pointer dereference at 0000000000000128 IP: [] kvm_set_irq+0x30/0x170 [kvm] ... Call Trace: [] pit_do_work+0x51/0xd0 [kvm] [] process_one_work+0x111/0x4d0 [] worker_thread+0x152/0x340 [] kthread+0x7e/0x90 [] kernel_thread_helper+0x4/0x10 Prevent this by checking the irqchip mode before starting a timer. We can't deny creating the PIT if the irqchips aren't set up yet as current user land expects this order to work. Signed-off-by: Jan Kiszka Signed-off-by: Marcelo Tosatti Signed-off-by: Paul Gortmaker commit 9b970b952ca4c0294a1fa0031ffaffeef23593ab Author: Jacek Luczak Date: Thu May 19 09:55:13 2011 +0000 SCTP: fix race between sctp_bind_addr_free() and sctp_bind_addr_conflict() commit c182f90bc1f22ce5039b8722e45621d5f96862c2 upstream. During the sctp_close() call, we do not use rcu primitives to destroy the address list attached to the endpoint. At the same time, we do the removal of addresses from this list before attempting to remove the socket from the port hash As a result, it is possible for another process to find the socket in the port hash that is in the process of being closed. It then proceeds to traverse the address list to find the conflict, only to have that address list suddenly disappear without rcu() critical section. Fix issue by closing address list removal inside RCU critical section. Race can result in a kernel crash with general protection fault or kernel NULL pointer dereference: kernel: general protection fault: 0000 [#1] SMP kernel: RIP: 0010:[] [] sctp_bind_addr_conflict+0x64/0x82 [sctp] kernel: Call Trace: kernel: [] ? sctp_get_port_local+0x17b/0x2a3 [sctp] kernel: [] ? sctp_bind_addr_match+0x33/0x68 [sctp] kernel: [] ? sctp_do_bind+0xd3/0x141 [sctp] kernel: [] ? sctp_bindx_add+0x4d/0x8e [sctp] kernel: [] ? sctp_setsockopt_bindx+0x112/0x4a4 [sctp] kernel: [] ? generic_file_aio_write+0x7f/0x9b kernel: [] ? sctp_setsockopt+0x14f/0xfee [sctp] kernel: [] ? do_sync_write+0xab/0xeb kernel: [] ? fsnotify+0x239/0x282 kernel: [] ? alloc_file+0x18/0xb1 kernel: [] ? compat_sys_setsockopt+0x1a5/0x1d9 kernel: [] ? compat_sys_socketcall+0x143/0x1a4 kernel: [] ? sysenter_dispatch+0x7/0x32 Signed-off-by: Jacek Luczak Acked-by: Vlad Yasevich CC: Eric Dumazet Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit f136196bbb5fd226fbc3d0873768a355dcb2d513 Author: Thomas Graf Date: Thu Jul 7 00:28:35 2011 +0000 sctp: Enforce retransmission limit during shutdown commit f8d9605243280f1870dd2c6c37a735b925c15f3c upstream. When initiating a graceful shutdown while having data chunks on the retransmission queue with a peer which is in zero window mode the shutdown is never completed because the retransmission error count is reset periodically by the following two rules: - Do not timeout association while doing zero window probe. - Reset overall error count when a heartbeat request has been acknowledged. The graceful shutdown will wait for all outstanding TSN to be acknowledged before sending the SHUTDOWN request. This never happens due to the peer's zero window not acknowledging the continuously retransmitted data chunks. Although the error counter is incremented for each failed retransmission, the receiving of the SACK announcing the zero window clears the error count again immediately. Also heartbeat requests continue to be sent periodically. The peer acknowledges these requests causing the error counter to be reset as well. This patch changes behaviour to only reset the overall error counter for the above rules while not in shutdown. After reaching the maximum number of retransmission attempts, the T5 shutdown guard timer is scheduled to give the receiver some additional time to recover. The timer is stopped as soon as the receiver acknowledges any data. The issue can be easily reproduced by establishing a sctp association over the loopback device, constantly queueing data at the sender while not reading any at the receiver. Wait for the window to reach zero, then initiate a shutdown by killing both processes simultaneously. The association will never be freed and the chunks on the retransmission queue will be retransmitted indefinitely. Signed-off-by: Thomas Graf Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 3f1562900a805d9555b832c6224caafbc2c6f068 Author: Thomas Graf Date: Fri Jul 8 04:37:46 2011 +0000 sctp: ABORT if receive, reassmbly, or reodering queue is not empty while closing socket commit cd4fcc704f30f2064ab30b5300d44d431e46db50 upstream. Trigger user ABORT if application closes a socket which has data queued on the socket receive queue or chunks waiting on the reassembly or ordering queue as this would imply data being lost which defeats the point of a graceful shutdown. This behavior is already practiced in TCP. We do not check the input queue because that would mean to parse all chunks on it to look for unacknowledged data which seems too much of an effort. Control chunks or duplicated chunks may also be in the input queue and should not be stopping a graceful shutdown. Signed-off-by: Thomas Graf Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 6481bb37fc7ad1f4772014c97f7e054ae9a08981 Author: Neil Horman Date: Mon Jul 16 09:13:51 2012 +0000 sctp: Fix list corruption resulting from freeing an association on a list commit 2eebc1e188e9e45886ee00662519849339884d6d upstream. A few days ago Dave Jones reported this oops: [22766.294255] general protection fault: 0000 [#1] PREEMPT SMP [22766.295376] CPU 0 [22766.295384] Modules linked in: [22766.387137] ffffffffa169f292 6b6b6b6b6b6b6b6b ffff880147c03a90 ffff880147c03a74 [22766.387135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000 [22766.387136] Process trinity-watchdo (pid: 10896, threadinfo ffff88013e7d2000, [22766.387137] Stack: [22766.387140] ffff880147c03a10 [22766.387140] ffffffffa169f2b6 [22766.387140] ffff88013ed95728 [22766.387143] 0000000000000002 [22766.387143] 0000000000000000 [22766.387143] ffff880003fad062 [22766.387144] ffff88013c120000 [22766.387144] [22766.387145] Call Trace: [22766.387145] [22766.387150] [] ? __sctp_lookup_association+0x62/0xd0 [sctp] [22766.387154] [] __sctp_lookup_association+0x86/0xd0 [sctp] [22766.387157] [] sctp_rcv+0x207/0xbb0 [sctp] [22766.387161] [] ? trace_hardirqs_off_caller+0x28/0xd0 [22766.387163] [] ? nf_hook_slow+0x133/0x210 [22766.387166] [] ? ip_local_deliver_finish+0x4c/0x4c0 [22766.387168] [] ip_local_deliver_finish+0x18d/0x4c0 [22766.387169] [] ? ip_local_deliver_finish+0x4c/0x4c0 [22766.387171] [] ip_local_deliver+0x47/0x80 [22766.387172] [] ip_rcv_finish+0x150/0x680 [22766.387174] [] ip_rcv+0x214/0x320 [22766.387176] [] __netif_receive_skb+0x7b7/0x910 [22766.387178] [] ? __netif_receive_skb+0x11c/0x910 [22766.387180] [] ? put_lock_stats.isra.25+0xe/0x40 [22766.387182] [] netif_receive_skb+0x23/0x1f0 [22766.387183] [] ? dev_gro_receive+0x139/0x440 [22766.387185] [] napi_skb_finish+0x70/0xa0 [22766.387187] [] napi_gro_receive+0xf5/0x130 [22766.387218] [] e1000_receive_skb+0x59/0x70 [e1000e] [22766.387242] [] e1000_clean_rx_irq+0x28b/0x460 [e1000e] [22766.387266] [] e1000e_poll+0x78/0x430 [e1000e] [22766.387268] [] net_rx_action+0x1aa/0x3d0 [22766.387270] [] ? account_system_vtime+0x10f/0x130 [22766.387273] [] __do_softirq+0xe0/0x420 [22766.387275] [] call_softirq+0x1c/0x30 [22766.387278] [] do_softirq+0xd5/0x110 [22766.387279] [] irq_exit+0xd5/0xe0 [22766.387281] [] do_IRQ+0x63/0xd0 [22766.387283] [] common_interrupt+0x6f/0x6f [22766.387283] [22766.387284] [22766.387285] [] ? retint_swapgs+0x13/0x1b [22766.387285] Code: c0 90 5d c3 66 0f 1f 44 00 00 4c 89 c8 5d c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 <0f> b7 87 98 00 00 00 48 89 fb 49 89 f5 66 c1 c0 08 66 39 46 02 [22766.387307] [22766.387307] RIP [22766.387311] [] sctp_assoc_is_match+0x19/0x90 [sctp] [22766.387311] RSP [22766.387142] ffffffffa16ab120 [22766.599537] ---[ end trace 3f6dae82e37b17f5 ]--- [22766.601221] Kernel panic - not syncing: Fatal exception in interrupt It appears from his analysis and some staring at the code that this is likely occuring because an association is getting freed while still on the sctp_assoc_hashtable. As a result, we get a gpf when traversing the hashtable while a freed node corrupts part of the list. Nominally I would think that an mibalanced refcount was responsible for this, but I can't seem to find any obvious imbalance. What I did note however was that the two places where we create an association using sctp_primitive_ASSOCIATE (__sctp_connect and sctp_sendmsg), have failure paths which free a newly created association after calling sctp_primitive_ASSOCIATE. sctp_primitive_ASSOCIATE brings us into the sctp_sf_do_prm_asoc path, which issues a SCTP_CMD_NEW_ASOC side effect, which in turn adds a new association to the aforementioned hash table. the sctp command interpreter that process side effects has not way to unwind previously processed commands, so freeing the association from the __sctp_connect or sctp_sendmsg error path would lead to a freed association remaining on this hash table. I've fixed this but modifying sctp_[un]hash_established to use hlist_del_init, which allows us to proerly use hlist_unhashed to check if the node is on a hashlist safely during a delete. That in turn alows us to safely call sctp_unhash_established in the __sctp_connect and sctp_sendmsg error paths before freeing them, regardles of what the associations state is on the hash list. I noted, while I was doing this, that the __sctp_unhash_endpoint was using hlist_unhsashed in a simmilar fashion, but never nullified any removed nodes pointers to make that function work properly, so I fixed that up in a simmilar fashion. I attempted to test this using a virtual guest running the SCTP_RR test from netperf in a loop while running the trinity fuzzer, both in a loop. I wasn't able to recreate the problem prior to this fix, nor was I able to trigger the failure after (neither of which I suppose is suprising). Given the trace above however, I think its likely that this is what we hit. Signed-off-by: Neil Horman Reported-by: davej@redhat.com CC: davej@redhat.com CC: "David S. Miller" CC: Vlad Yasevich CC: Sridhar Samudrala CC: linux-sctp@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 3b38501302d2651cba3287e1183e81203632e0a2 Author: Wei Yongjun Date: Thu Mar 31 23:42:55 2011 +0000 sctp: malloc enough room for asconf-ack chunk commit 2cab86bee8e7f353e6ac8c15b3eb906643497644 upstream. Sometime the ASCONF_ACK parameters can equal to the fourfold of ASCONF parameters, this only happend in some special case: ASCONF parameter is : Unrecognized Parameter (4 bytes) ASCONF_ACK parameter should be: Error Cause Indication parameter (8 bytes header) + Error Cause (4 bytes header) + Unrecognized Parameter (4bytes) Four 4bytes Unrecognized Parameters in ASCONF chunk will cause panic. Pid: 0, comm: swapper Not tainted 2.6.38-next+ #22 Bochs Bochs EIP: 0060:[] EFLAGS: 00010246 CPU: 0 EIP is at skb_put+0x60/0x70 EAX: 00000077 EBX: c09060e2 ECX: dec1dc30 EDX: c09469c0 ESI: 00000000 EDI: de3c8d40 EBP: dec1dc58 ESP: dec1dc2c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process swapper (pid: 0, ti=dec1c000 task=c09aef20 task.ti=c0980000) Stack: c09469c0 e1894fa4 00000044 00000004 de3c8d00 de3c8d00 de3c8d44 de3c8d40 c09060e2 de25dd80 de3c8d40 dec1dc7c e1894fa4 dec1dcb0 00000040 00000004 00000000 00000800 00000004 00000004 dec1dce0 e1895a2b dec1dcb4 de25d960 Call Trace: [] ? sctp_addto_chunk+0x4e/0x89 [sctp] [] sctp_addto_chunk+0x4e/0x89 [sctp] [] sctp_process_asconf+0x32f/0x3d1 [sctp] [] sctp_sf_do_asconf+0xf8/0x173 [sctp] [] sctp_do_sm+0xb8/0x159 [sctp] [] ? sctp_cname+0x0/0x52 [sctp] [] sctp_assoc_bh_rcv+0xac/0xe3 [sctp] [] sctp_inq_push+0x2d/0x30 [sctp] [] sctp_rcv+0x7a7/0x83d [sctp] [] ? ipv4_confirm+0x118/0x125 [] ? nf_iterate+0x34/0x62 [] ? ip_local_deliver_finish+0x0/0x194 [] ? ip_local_deliver_finish+0x0/0x194 [] ip_local_deliver_finish+0xf5/0x194 [] ? ip_local_deliver_finish+0x0/0x194 [] NF_HOOK.clone.1+0x3d/0x44 [] ip_local_deliver+0x3e/0x44 [] ? ip_local_deliver_finish+0x0/0x194 [] ip_rcv_finish+0x29f/0x2c7 [] ? ip_rcv_finish+0x0/0x2c7 [] NF_HOOK.clone.1+0x3d/0x44 [] ip_rcv+0x1f5/0x233 [] ? ip_rcv_finish+0x0/0x2c7 [] __netif_receive_skb+0x310/0x336 [] netif_receive_skb+0x4b/0x51 [] cp_rx_poll+0x1e7/0x29c [8139cp] [] net_rx_action+0x65/0x13a [] __do_softirq+0xa1/0x149 [] ? __do_softirq+0x0/0x149 [] ? irq_exit+0x37/0x72 [] ? do_IRQ+0x81/0x95 [] ? common_interrupt+0x30/0x38 [] ? native_safe_halt+0xa/0xc [] ? default_idle+0x58/0x92 [] ? cpu_idle+0x96/0xb2 [] ? rest_init+0x5d/0x5f [] ? start_kernel+0x34b/0x350 [] ? i386_start_kernel+0xba/0xc1 Signed-off-by: Wei Yongjun Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker commit 1bf86851f449172c5cb6ed1d8a05c5e45994b56b Author: Jan Kara Date: Tue Jul 10 17:58:04 2012 +0200 udf: Improve table length check to avoid possible overflow commit 57b9655d01ef057a523e810d29c37ac09b80eead upstream. When a partition table length is corrupted to be close to 1 << 32, the check for its length may overflow on 32-bit systems and we will think the length is valid. Later on the kernel can crash trying to read beyond end of buffer. Fix the check to avoid possible overflow. Reported-by: Ben Hutchings Signed-off-by: Jan Kara Signed-off-by: Paul Gortmaker commit d7542a6eb171336db2101522803f46e6e624bd1f Author: Jan Kara Date: Wed Jun 27 20:20:22 2012 +0200 udf: Avoid run away loop when partition table length is corrupted commit adee11b2085bee90bd8f4f52123ffb07882d6256 upstream. Check provided length of partition table so that (possibly maliciously) corrupted partition table cannot cause accessing data beyond current buffer. Signed-off-by: Jan Kara [PG: in 2.6.34 udf_err() is called udf_error()] Signed-off-by: Paul Gortmaker commit 9ae30e324a96d0328a575329d7a95a09b3318601 Author: Jan Kara Date: Wed Jun 27 21:23:07 2012 +0200 udf: Fortify loading of sparing table commit 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 upstream. Add sanity checks when loading sparing table from disk to avoid accessing unallocated memory or writing to it. Signed-off-by: Jan Kara [PG: in 2.6.34 udf_err() is called udf_error()] Signed-off-by: Paul Gortmaker commit 0ccf5700cfba2b986a7a7df39334a6f045df0ada 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 Signed-off-by: Paul Gortmaker commit 25772970966c268c16ec5c0f9d02449f401663c1 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: Paul Gortmaker commit 6858f663d73dffd63ef7abb82ed26b07a17a58cc 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 Signed-off-by: Paul Gortmaker commit b17a40e94bab5b7bdc17231756ef8fab4b9318f0 Author: Xiao Guangrong Date: Sun Aug 22 19:08:57 2010 +0800 export __get_user_pages_fast() function commit 45888a0c6edc305495b6bd72a30e66bc40b324c6 upstream. 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: Paul Gortmaker commit 9d6b8fa025237243e1782c358c83f20062d39fbe 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 Signed-off-by: Paul Gortmaker commit 9e3e877bb1a15d180207fd191058ac7e3da91d30 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 Signed-off-by: Paul Gortmaker commit df58c339ca7baf1720a319fbea2b6d8ea01ab27a 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" Signed-off-by: Paul Gortmaker commit 7e8d8dece102adb905a3c4f2fa95b49ff91d7fcd 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: Paul Gortmaker commit e6a06a380db7a1c307bba91233faf07678e52d75 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: Paul Gortmaker commit 264266e6897dd81c894d1c5cbd90b133707b32f3 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: Paul Gortmaker commit 3f52a4057b24ed3a9d628a4594f80f15949e3b12 Author: Tejun Heo Date: Fri Jun 18 11:44:31 2010 +0200 percpu: fix first chunk match in per_cpu_ptr_to_phys() commit 9983b6f0cf8263e51bcf4c8a9dc0c1ef175b3c60 upstream. per_cpu_ptr_to_phys() determines whether the passed in @addr belongs to the first_chunk or not by just matching the address against the address range of the base unit (unit0, used by cpu0). When an adress from another cpu was passed in, it will always determine that the address doesn't belong to the first chunk even when it does. This makes the function return a bogus physical address which may lead to crash. This problem was discovered by Cliff Wickman while investigating a crash during kdump on a SGI UV system. Signed-off-by: Tejun Heo Reported-by: Cliff Wickman Tested-by: Cliff Wickman [PG: for 2.6.34, diffstat differs slightly due to a trivial indenting difference, and 34 does not have the _maybe_unused annotation to delete] Signed-off-by: Paul Gortmaker commit a0cf4d370df2e6fdf50f73679f1d6315c13e073a Author: Robert Richter Date: Thu May 26 18:39:35 2011 +0200 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: Paul Gortmaker commit 2d393c3a6ac2e1a926ba67c3d8aa3a3479c2ba73 Author: Robert Richter Date: Thu May 26 18:22:54 2011 +0200 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: Paul Gortmaker commit 99a99c44ad2eacb1ff6faa603176ccdb11088696 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: Paul Gortmaker commit 3c49ac0cf82ece4c02784528cdfce7c6748254d2 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 [PG: in mainline, 21268961d3 rewrites and creates alc_mux_select, but the code that needed the check still existed prior to that in alc_mux_enum_put] Signed-off-by: Paul Gortmaker commit 50c8a5c24efdc2b15e2e11f8ce2cbe1284fb933e 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: Paul Gortmaker commit 675be1e1dacca2ade17771af82b8c948579a080b Author: Thomas Gleixner Date: Fri Dec 2 12:34:16 2011 +0100 tick-broadcast: Stop active broadcast device when replacing it commit c1be84309c58b1e7c6d626e28fba41a22b364c3d upstream. When a better rated broadcast device is installed, then the current active device is not disabled, which results in two running broadcast devices. Signed-off-by: Thomas Gleixner Signed-off-by: Paul Gortmaker commit 8844a98f2d95682ab4c71180e2e599cdb888ae7d Author: Ido Yariv Date: Thu Dec 1 13:55:08 2011 +0200 genirq: Fix race condition when stopping the irq thread commit 550acb19269d65f32e9ac4ddb26c2b2070e37f1c upstream. In irq_wait_for_interrupt(), the should_stop member is verified before setting the task's state to TASK_INTERRUPTIBLE and calling schedule(). In case kthread_stop sets should_stop and wakes up the process after should_stop is checked by the irq thread but before the task's state is changed, the irq thread might never exit: kthread_stop irq_wait_for_interrupt ------------ ---------------------- ... ... while (!kthread_should_stop()) { kthread->should_stop = 1; wake_up_process(k); wait_for_completion(&kthread->exited); ... set_current_state(TASK_INTERRUPTIBLE); ... schedule(); } Fix this by checking if the thread should stop after modifying the task's state. [ tglx: Simplified it a bit ] Signed-off-by: Ido Yariv Link: http://lkml.kernel.org/r/1322740508-22640-1-git-send-email-ido@wizery.com Signed-off-by: Thomas Gleixner Signed-off-by: Paul Gortmaker commit e643d6a6556081c73ec68e7a7045b3d994106616 Author: Robert Richter Date: Mon Oct 10 16:21:10 2011 +0200 oprofile, x86: Fix crash when unloading module (nmi timer mode) commit 97f7f8189fe54e3cfe324ef9ad35064f3d2d3bff upstream. If oprofile uses the nmi timer interrupt there is a crash while unloading the module. The bug can be triggered with oprofile build as module and kernel parameter nolapic set. This patch fixes this. oprofile: using NMI timer interrupt. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [] unregister_syscore_ops+0x41/0x58 PGD 42dbca067 PUD 41da6a067 PMD 0 Oops: 0002 [#1] PREEMPT SMP CPU 5 Modules linked in: oprofile(-) [last unloaded: oprofile] Pid: 2518, comm: modprobe Not tainted 3.1.0-rc7-00019-gb2fb49d #19 Advanced Micro Device Anaheim/Anaheim RIP: 0010:[] [] unregister_syscore_ops+0x41/0x58 RSP: 0018:ffff88041ef71e98 EFLAGS: 00010296 RAX: 0000000000000000 RBX: ffffffffa0017100 RCX: dead000000200200 RDX: 0000000000000000 RSI: dead000000100100 RDI: ffffffff8178c620 RBP: ffff88041ef71ea8 R08: 0000000000000001 R09: 0000000000000082 R10: 0000000000000000 R11: ffff88041ef71de8 R12: 0000000000000080 R13: fffffffffffffff5 R14: 0000000000000001 R15: 0000000000610210 FS: 00007fc902f20700(0000) GS:ffff88042fd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000008 CR3: 000000041cdb6000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process modprobe (pid: 2518, threadinfo ffff88041ef70000, task ffff88041d348040) Stack: ffff88041ef71eb8 ffffffffa0017790 ffff88041ef71eb8 ffffffffa0013532 ffff88041ef71ec8 ffffffffa00132d6 ffff88041ef71ed8 ffffffffa00159b2 ffff88041ef71f78 ffffffff81073115 656c69666f72706f 0000000000610200 Call Trace: [] op_nmi_exit+0x15/0x17 [oprofile] [] oprofile_arch_exit+0xe/0x10 [oprofile] [] oprofile_exit+0x1e/0x20 [oprofile] [] sys_delete_module+0x1c3/0x22f [] ? trace_hardirqs_on_thunk+0x3a/0x3f [] system_call_fastpath+0x16/0x1b Code: 20 c6 78 81 e8 c5 cc 23 00 48 8b 13 48 8b 43 08 48 be 00 01 10 00 00 00 ad de 48 b9 00 02 20 00 00 00 ad de 48 c7 c7 20 c6 78 81 89 42 08 48 89 10 48 89 33 48 89 4b 08 e8 a6 c0 23 00 5a 5b RIP [] unregister_syscore_ops+0x41/0x58 RSP CR2: 0000000000000008 ---[ end trace 43a541a52956b7b0 ]--- Signed-off-by: Robert Richter Signed-off-by: Paul Gortmaker commit 90de15d724da0ce5672a6a04419934023b41e52f Author: Bjorn Helgaas Date: Sun Sep 25 15:29:00 2011 -0600 x86/mpparse: Account for bus types other than ISA and PCI commit 9e6866686bdf2dcf3aeb0838076237ede532dcc8 upstream. In commit f8924e770e04 ("x86: unify mp_bus_info"), the 32-bit and 64-bit versions of MP_bus_info were rearranged to match each other better. Unfortunately it introduced a regression: prior to that change we used to always set the mp_bus_not_pci bit, then clear it if we found a PCI bus. After it, we set mp_bus_not_pci for ISA buses, clear it for PCI buses, and leave it alone otherwise. In the cases of ISA and PCI, there's not much difference. But ISA is not the only non-PCI bus, so it's better to always set mp_bus_not_pci and clear it only for PCI. Without this change, Dan's Dell PowerEdge 4200 panics on boot with a log indicating interrupt routing trouble unless the "noapic" option is supplied. With this change, the machine boots reliably without "noapic". Fixes http://bugs.debian.org/586494 Reported-bisected-and-tested-by: Dan McGrath Signed-off-by: Bjorn Helgaas Cc: Dan McGrath Cc: Alexey Starikovskiy [jrnieder@gmail.com: clarified commit message] Signed-off-by: Jonathan Nieder Link: http://lkml.kernel.org/r/20111122215000.GA9151@elie.hsd1.il.comcast.net Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit 1db597885d25b0c0ef0636b15465eecca7158dfc Author: Salman Qazi Date: Tue Nov 15 14:12:06 2011 -0800 sched, x86: Avoid unnecessary overflow in sched_clock commit 4cecf6d401a01d054afc1e5f605bcbfe553cb9b9 upstream. (Added the missing signed-off-by line) In hundreds of days, the __cycles_2_ns calculation in sched_clock has an overflow. cyc * per_cpu(cyc2ns, cpu) exceeds 64 bits, causing the final value to become zero. We can solve this without losing any precision. We can decompose TSC into quotient and remainder of division by the scale factor, and then use this to convert TSC into nanoseconds. Signed-off-by: Salman Qazi Acked-by: John Stultz Reviewed-by: Paul Turner Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/20111115221121.7262.88871.stgit@dungbeetle.mtv.corp.google.com Signed-off-by: Ingo Molnar Signed-off-by: Paul Gortmaker commit cb49b3fde667fea4a8121f9d376085564ba64ba0 Author: Hannes Reinecke Date: Wed Nov 9 08:39:24 2011 +0100 Silencing 'killing requests for dead queue' commit 745718132c3c7cac98a622b610e239dcd5217f71 upstream. When we tear down a device we try to flush all outstanding commands in scsi_free_queue(). However the check in scsi_request_fn() is imperfect as it only signals that we _might start_ aborting commands, not that we've actually aborted some. So move the printk inside the scsi_kill_request function, this will also give us a hint about which commands are aborted. Signed-off-by: Hannes Reinecke Signed-off-by: James Bottomley Signed-off-by: Paul Gortmaker commit 6a114984d0d4c0790b64676e4513d78277a777c5 Author: Qinglin Ye Date: Wed Nov 23 23:39:32 2011 +0800 USB: usb-storage: unusual_devs entry for Kingston DT 101 G2 commit cec28a5428793b6bc64e56687fb239759d6da74e upstream. Kingston DT 101 G2 replies a wrong tag while transporting, add an unusal_devs entry to ignore the tag validation. Signed-off-by: Qinglin Ye Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 80de3a8ff44f7c4f23cedc6276628f335ca3fd6d Author: Veli-Pekka Peltola Date: Thu Nov 24 22:08:56 2011 +0200 usb: option: add SIMCom SIM5218 commit ec0cd94d881ca89cc9fb61d00d0f4b2b52e605b3 upstream. Tested with SIM5218EVB-KIT evaluation kit. Signed-off-by: Veli-Pekka Peltola Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 5c8955dd97124d8072bcbc5053bb10855719ead3 Author: Marcin Kościelnicki Date: Wed Nov 30 17:01:04 2011 +0100 usb: ftdi_sio: add PID for Propox ISPcable III commit 307369b0ca06b27b511b61714e335ddfccf19c4f upstream. Signed-off-by: Marcin Kościelnicki Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 6066bdfc7f12a131e8662c989cf366ead803a8ed Author: Dan Carpenter Date: Tue Nov 22 10:28:31 2011 +0300 USB: whci-hcd: fix endian conversion in qset_clear() commit 8746c83d538cab273d335acb2be226d096f4a5af upstream. qset->qh.link is an __le64 field and we should be using cpu_to_le64() to fill it. Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 15c1145a43b3935d1cbb01ddde21a0e716529c71 Author: Federico Vaga Date: Sat Oct 29 09:47:39 2011 +0200 Staging: comedi: fix signal handling in read and write commit 6a9ce6b654e491981f6ef7e214cbd4f63e033848 upstream. After sleeping on a wait queue, signal_pending(current) should be checked (not before sleeping). Acked-by: Alessandro Rubini Signed-off-by: Federico Vaga Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 3795b50b1456e0b461ae3095f94e7b953909dc5e Author: Bernd Porr Date: Tue Nov 8 21:23:03 2011 +0000 staging: comedi: fix oops for USB DAQ devices. commit 3ffab428f40849ed5f21bcfd7285bdef7902f9ca upstream. This fixes kernel oops when an USB DAQ device is plugged out while it's communicating with the userspace software. Signed-off-by: Bernd Porr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit bb3435c68eea53ece598243a9c481177372dafb4 Author: Bart Westgeest Date: Tue Nov 1 15:01:28 2011 -0400 staging: usbip: bugfix for deadlock commit 438957f8d4a84daa7fa5be6978ad5897a2e9e5e5 upstream. Interrupts must be disabled prior to calling usb_hcd_unlink_urb_from_ep. If interrupts are not disabled, it can potentially lead to a deadlock. The deadlock is readily reproduceable on a slower (ARM based) device such as the TI Pandaboard. Signed-off-by: Bart Westgeest Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Gortmaker commit 42585bfbff9ad0c9c03e47a1989f911a984ce618 Author: Eliad Peller Date: Thu Nov 24 18:13:56 2011 +0200 nl80211: fix MAC address validation commit e007b857e88097c96c45620bf3b04a4e309053d1 upstream. MAC addresses have a fixed length. The current policy allows passing < ETH_ALEN bytes, which might result in reading beyond the buffer. Signed-off-by: Eliad Peller Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit 89b56467c5ee10ab80c44aa1fe03d461deaf0c92 Author: Michael Büsch Date: Wed Nov 16 23:55:46 2011 +0100 p54spi: Fix workqueue deadlock commit 2d1618170eb493d18f66f2ac03775409a6fb97c6 upstream. priv->work must not be synced while priv->mutex is locked, because the mutex is taken in the work handler. Move cancel_work_sync down to after the device shutdown code. This is safe, because the work handler checks fw_state and bails out early in case of a race. Signed-off-by: Michael Buesch Acked-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit 94bad843f7453e4353703fb4b75afde2fdeb3425 Author: Michael Büsch Date: Wed Nov 16 23:48:31 2011 +0100 p54spi: Add missing spin_lock_init commit 32d3a3922d617a5a685a5e2d24b20d0e88f192a9 upstream. The tx_lock is not initialized properly. Add spin_lock_init(). Signed-off-by: Michael Buesch Acked-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker commit 7806334afcaf4f0352a9c6f813264f5ef27d00f9 Author: Hector Palacios Date: Mon Nov 14 11:15:25 2011 +0100 timekeeping: add arch_offset hook to ktime_get functions commit d004e024058a0eaca097513ce62cbcf978913e0a upstream. ktime_get and ktime_get_ts were calling timekeeping_get_ns() but later they were not calling arch_gettimeoffset() so architectures using this mechanism returned 0 ns when calling these functions. This happened for example when running Busybox's ping which calls syscall(__NR_clock_gettime, CLOCK_MONOTONIC, ts) which eventually calls ktime_get. As a result the returned ping travel time was zero. Signed-off-by: Hector Palacios Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit 30c42309ea65847d822101fe4fa4d0bce177769e Author: Trond Myklebust Date: Tue Nov 22 14:44:28 2011 +0200 SUNRPC: Ensure we return EAGAIN in xs_nospace if congestion is cleared commit 24ca9a847791fd53d9b217330b15f3c285827a18 upstream. By returning '0' instead of 'EAGAIN' when the tests in xs_nospace() fail to find evidence of socket congestion, we are making the RPC engine believe that the message was incorrectly sent and so it disconnects the socket instead of just retrying. The bug appears to have been introduced by commit 5e3771ce2d6a69e10fcc870cdf226d121d868491 (SUNRPC: Ensure that xs_nospace return values are propagated). Reported-by: Andrew Cooper Signed-off-by: Trond Myklebust Tested-by: Andrew Cooper Signed-off-by: Paul Gortmaker commit 84248cd08252b61e76a26a0d83a9596a29e4e564 Author: Tim Blechmann Date: Tue Nov 22 11:15:45 2011 +0100 ALSA: lx6464es - fix device communication via command bus commit a29878553a9a7b4c06f93c7e383527cf014d4ceb upstream. commit 6175ddf06b6172046a329e3abfd9c901a43efd2e optimized the mem*io functions that have been used to send commands to the device. these optimizations somehow corrupted the communication with the lx6464es, that resulted the device to be unusable with kernels after 2.6.33. this patch emulates the memcpy_*_io functions via a loop to avoid these problems. Signed-off-by: Tim Blechmann LKML-Reference: <4ECB5257.4040600@ladisch.de> Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit a21d3396b8150b3a776534520fc8ec29809ab4b8 Author: Will Deacon Date: Mon Nov 14 17:24:58 2011 +0100 ARM: 7161/1: errata: no automatic store buffer drain commit 11ed0ba1754841316d4095478944300acf19acc3 upstream. This patch implements a workaround for PL310 erratum 769419. On revisions of the PL310 prior to r3p2, the Store Buffer does not automatically drain. This can cause normal, non-cacheable writes to be retained when the memory system is idle, leading to suboptimal I/O performance for drivers using coherent DMA. This patch adds an optional wmb() call to the cpu_idle loop. On systems with an outer cache, this causes an explicit flush of the store buffer. Acked-by: Catalin Marinas Tested-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Paul Gortmaker commit caa381d13ab47e05230756084ca2b38505727a2e Author: Bjorn Helgaas Date: Tue Aug 23 10:16:43 2011 -0600 PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs commit 4cac2eb158c6da0c761689345c6cc5df788a6292 upstream. Previously we claimed device ID 0x7450, regardless of the vendor, which is clearly wrong. Now we'll claim that device ID only for AMD. I suspect this was just a typo in the original code, but it's possible this change will break shpchp on non-7450 AMD bridges. If so, we'll have to fix them as we find them. Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863 Reported-by: Ralf Jung Cc: Joerg Roedel Signed-off-by: Bjorn Helgaas Signed-off-by: Jesse Barnes Signed-off-by: Paul Gortmaker commit d201b43437e467efc86f0c6b66efb604652861dc Author: Tyler Hicks Date: Wed Nov 23 11:31:24 2011 -0600 eCryptfs: Extend array bounds for all filename chars commit 0f751e641a71157aa584c2a2e22fda52b52b8a56 upstream. From mhalcrow's original commit message: Characters with ASCII values greater than the size of filename_rev_map[] are valid filename characters. ecryptfs_decode_from_filename() will access kernel memory beyond that array, and ecryptfs_parse_tag_70_packet() will then decrypt those characters. The attacker, using the FNEK of the crafted file, can then re-encrypt the characters to reveal the kernel memory past the end of the filename_rev_map[] array. I expect low security impact since this array is statically allocated in the text area, and the amount of memory past the array that is accessible is limited by the largest possible ASCII filename character. This patch solves the issue reported by mhalcrow but with an implementation suggested by Linus to simply extend the length of filename_rev_map[] to 256. Characters greater than 0x7A are mapped to 0x00, which is how invalid characters less than 0x7A were previously being handled. Signed-off-by: Tyler Hicks Reported-by: Michael Halcrow Signed-off-by: Paul Gortmaker commit 50dbd6f1b370a57cd90eb49a01a5ee732242bbaf Author: Jeffrey (Sheng-Hui) Chu Date: Wed Nov 23 11:33:07 2011 +0100 i2c-algo-bit: Generate correct i2c address sequence for 10-bit target commit cc6bcf7d2ec2234e7b41770185e4dc826390185e upstream. The wrong bits were put on the wire, fix that. This fixes kernel bug #42562. Signed-off-by: Sheng-Hui J. Chu Signed-off-by: Jean Delvare Signed-off-by: Paul Gortmaker commit d7e23595aa6bc1892a46fb010832cb572023b0f2 Author: Suresh Siddha Date: Wed Oct 24 15:24:30 2012 -0700 x86, ioapic: initialize nr_ioapic_registers early in mp_register_ioapic() Lin Bao reported that one of the HP platforms failed to boot 2.6.32 kernel, when the BIOS enabled interrupt-remapping and x2apic before handing over the control to the Linux kernel. During boot, Linux kernel masks all the interrupt sources (8259, IO-APIC RTE's), setup the interrupt-remapping hardware with the OS controlled table and unmasks the 8259 interrupts but not the IO-APIC RTE's (as the newly setup interrupt-remapping table and the IO-APIC RTE's are not yet programmed by the kernel). Shortly after this, IO-APIC RTE's and the interrupt-remapping table entries are programmed based on the ACPI tables etc. So the expectation is that any interrupt during this window will be dropped and not see the intermediate configuration. In the reported problematic case, BIOS has configured the IO-APIC in virtual wire-B mode. Between the window of the kernel setting up new interrupt-remapping table and the IO-APIC RTE's are properly configured, an interrupt gets routed by the IO-APIC RTE (setup by the virtual wire-B configuration) and sees the empty interrupt-remapping table entry, resulting in vt-d fault causing the platform to generate NMI. And the OS panics on this unexpected NMI. This problem doesn't happen with more recent kernels and closer look at the 2.6.32 kernel shows that the code which masks the IO-APIC RTE's is not working as expected as the nr_ioapic_registers for each IO-APIC is not yet initialized at this point. In the later kernels we initialize nr_ioapic_registers much before and everything works as expected. For 2.6.[32..34] kernels, fix this issue by initializing nr_ioapic_registers early in mp_register_ioapic() [ Relevant upstream commit info: commit 7716a5c4ff5f1f3dc5e9edcab125cbf7fceef0af Author: Eric W. Biederman Date: Tue Mar 30 01:07:12 2010 -0700 x86, ioapic: Move nr_ioapic_registers calculation to mp_register_ioapic. As the upstream commit depends on quite a few prior commits and some followup fixes in the mainline, we just picked the smallest relevant hunk for fixing the issue at hand. Problematic platform uses ACPI for IO-APIC, VT-d enumeration etc and this hunk only touches the ACPI based platforms. nr_ioapic_reigsters initialization in enable_IO_APIC() is still retained, so that other configurations like legacy MPS table based enumeration etc works with no change. ] Reported-and-tested-by: Zhang, Lin-Bao Signed-off-by: Suresh Siddha Reviewed-by: Jonathan Nieder Acked-by: "Eric W. Biederman" Signed-off-by: Paul Gortmaker commit 3dd0cf08574f755be39ad6e17201be070b0887af Author: Xi Wang Date: Mon Dec 12 21:55:52 2011 +0000 xfs: fix acl count validation in xfs_acl_from_disk() commit 093019cf1b18dd31b2c3b77acce4e000e2cbc9ce upstream. Commit fa8b18ed didn't prevent the integer overflow and possible memory corruption. "count" can go negative and bypass the check. Signed-off-by: Xi Wang Reviewed-by: Christoph Hellwig Signed-off-by: Ben Myers [PG: in 2.6.34, xfs still had "linux-2.6" as a path component.] Signed-off-by: Paul Gortmaker commit 840d7af7a660547e5f73bdd9c1353cc2d9a271d6 Author: Christoph Hellwig Date: Sun Nov 20 15:35:32 2011 +0000 xfs: validate acl count commit fa8b18edd752a8b4e9d1ee2cd615b82c93cf8bba upstream. This prevents in-memory corruption and possible panics if the on-disk ACL is badly corrupted. Signed-off-by: Christoph Hellwig Signed-off-by: Ben Myers [PG: in 2.6.34, xfs still had "linux-2.6" as a path component.] Signed-off-by: Paul Gortmaker commit 74351de89460e502c99439c98dc134b7cf3c9a0e Author: Eric Paris Date: Tue Nov 23 18:18:37 2010 -0500 inotify: stop kernel memory leak on file creation failure commit a2ae4cc9a16e211c8a128ba10d22a85431f093ab upstream. If inotify_init is unable to allocate a new file for the new inotify group we leak the new group. This patch drops the reference on the group on file allocation failure. Reported-by: Vegard Nossum Signed-off-by: Eric Paris Signed-off-by: Paul Gortmaker commit f6c2e2e164b47b0c742ae89f266b05933e07e918 Author: Thadeu Lima de Souza Cascardo Date: Thu Oct 25 13:37:51 2012 -0700 genalloc: stop crashing the system when destroying a pool commit eedce141cd2dad8d0cefc5468ef41898949a7031 upstream. The genalloc code uses the bitmap API from include/linux/bitmap.h and lib/bitmap.c, which is based on long values. Both bitmap_set from lib/bitmap.c and bitmap_set_ll, which is the lockless version from genalloc.c, use BITMAP_LAST_WORD_MASK to set the first bits in a long in the bitmap. That one uses (1 << bits) - 1, 0b111, if you are setting the first three bits. This means that the API counts from the least significant bits (LSB from now on) to the MSB. The LSB in the first long is bit 0, then. The same works for the lookup functions. The genalloc code uses longs for the bitmap, as it should. In include/linux/genalloc.h, struct gen_pool_chunk has unsigned long bits[0] as its last member. When allocating the struct, genalloc should reserve enough space for the bitmap. This should be a proper number of longs that can fit the amount of bits in the bitmap. However, genalloc allocates an integer number of bytes that fit the amount of bits, but may not be an integer amount of longs. 9 bytes, for example, could be allocated for 70 bits. This is a problem in itself if the Least Significat Bit in a long is in the byte with the largest address, which happens in Big Endian machines. This means genalloc is not allocating the byte in which it will try to set or check for a bit. This may end up in memory corruption, where genalloc will try to set the bits it has not allocated. In fact, genalloc may not set these bits because it may find them already set, because they were not zeroed since they were not allocated. And that's what causes a BUG when gen_pool_destroy is called and check for any set bits. What really happens is that genalloc uses kmalloc_node with __GFP_ZERO on gen_pool_add_virt. With SLAB and SLUB, this means the whole slab will be cleared, not only the requested bytes. Since struct gen_pool_chunk has a size that is a multiple of 8, and slab sizes are multiples of 8, we get lucky and allocate and clear the right amount of bytes. Hower, this is not the case with SLOB or with older code that did memset after allocating instead of using __GFP_ZERO. So, a simple module as this (running 3.6.0), will cause a crash when rmmod'ed. [root@phantom-lp2 foo]# cat foo.c #include #include #include #include MODULE_LICENSE("GPL"); MODULE_VERSION("0.1"); static struct gen_pool *foo_pool; static __init int foo_init(void) { int ret; foo_pool = gen_pool_create(10, -1); if (!foo_pool) return -ENOMEM; ret = gen_pool_add(foo_pool, 0xa0000000, 32 << 10, -1); if (ret) { gen_pool_destroy(foo_pool); return ret; } return 0; } static __exit void foo_exit(void) { gen_pool_destroy(foo_pool); } module_init(foo_init); module_exit(foo_exit); [root@phantom-lp2 foo]# zcat /proc/config.gz | grep SLOB CONFIG_SLOB=y [root@phantom-lp2 foo]# insmod ./foo.ko [root@phantom-lp2 foo]# rmmod foo ------------[ cut here ]------------ kernel BUG at lib/genalloc.c:243! cpu 0x4: Vector: 700 (Program Check) at [c0000000bb0e7960] pc: c0000000003cb50c: .gen_pool_destroy+0xac/0x110 lr: c0000000003cb4fc: .gen_pool_destroy+0x9c/0x110 sp: c0000000bb0e7be0 msr: 8000000000029032 current = 0xc0000000bb0e0000 paca = 0xc000000006d30e00 softe: 0 irq_happened: 0x01 pid = 13044, comm = rmmod kernel BUG at lib/genalloc.c:243! [c0000000bb0e7ca0] d000000004b00020 .foo_exit+0x20/0x38 [foo] [c0000000bb0e7d20] c0000000000dff98 .SyS_delete_module+0x1a8/0x290 [c0000000bb0e7e30] c0000000000097d4 syscall_exit+0x0/0x94 --- Exception: c00 (System Call) at 000000800753d1a0 SP (fffd0b0e640) is in userspace Signed-off-by: Thadeu Lima de Souza Cascardo Cc: Paul Gortmaker Cc: Benjamin Gaignard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Paul Gortmaker commit 04ac97996a2b43b2f7c576795f0987f61ed177d5 Author: NeilBrown Date: Thu Aug 16 16:46:12 2012 +1000 md: Don't truncate size at 4TB for RAID0 and Linear commit 667a5313ecd7308d79629c0738b0db588b0b0a4e upstream. commit 27a7b260f71439c40546b43588448faac01adb93 md: Fix handling for devices from 2TB to 4TB in 0.90 metadata. changed 0.90 metadata handling to truncated size to 4TB as that is all that 0.90 can record. However for RAID0 and Linear, 0.90 doesn't need to record the size, so this truncation is not needed and causes working arrays to become too small. So avoid the truncation for RAID0 and Linear This bug was introduced in 3.1 and is suitable for any stable kernels from then onwards. As the offending commit was tagged for 'stable', any stable kernel that it was applied to should also get this patch. That includes at least 2.6.32, 2.6.33 and 3.0. (Thanks to Ben Hutchings for providing that list). Signed-off-by: Neil Brown Signed-off-by: Paul Gortmaker commit 9dcd6dc6505d8e7d32edb07f351694a3551e771c Author: NeilBrown Date: Sat Sep 10 17:21:28 2011 +1000 md: Fix handling for devices from 2TB to 4TB in 0.90 metadata. commit 27a7b260f71439c40546b43588448faac01adb93 upstream. 0.90 metadata uses an unsigned 32bit number to count the number of kilobytes used from each device. This should allow up to 4TB per device. However we multiply this by 2 (to get sectors) before casting to a larger type, so sizes above 2TB get truncated. Also we allow rdev->sectors to be larger than 4TB, so it is possible for the array to be resized larger than the metadata can handle. So make sure rdev->sectors never exceeds 4TB when 0.90 metadata is in used. Also the sanity check at the end of super_90_load should include level 1 as it used ->size too. (RAID0 and Linear don't use ->size at all). Reported-by: Pim Zandbergen Signed-off-by: NeilBrown Signed-off-by: Paul Gortmaker commit e4a0eea634767f19bdeb8c7044946c4a7ded542c Author: Benjamin Poirier Date: Wed Nov 30 07:47:18 2011 -0500 gro: reset vlan_tci on reuse This one liner is part of upstream commit 3701e51382a026cba10c60b03efabe534fba4ca4 Author: Jesse Gross vlan: Centralize handling of hardware acceleration. The bulk of that commit is a rework of the hardware assisted vlan tagging driver interface, and as such doesn't classify for -stable inclusion. The fix that is needed is a part of that commit but can work independently of the rest. This patch can avoid panics on the 2.6.32.y -stable kernels and is in the same spirit as mainline commits 66c46d7 gro: Reset dev pointer on reuse 6d152e2 gro: reset skb_iif on reuse which are already in -stable. For drivers using the vlan_gro_frags() interface, a packet with an invalid tci leads to GRO_DROP and napi_reuse_skb(). The skb has to be sanitized before being reused or we may send an skb with an invalid vlan_tci field up the stack where it is not expected. Signed-off-by: Benjamin Poirier Cc: Jesse Gross Acked-by: David S. Miller [PG: taken from v2.6.32.y stable, commit 5aff28abc7e] Signed-off-by: Paul Gortmaker commit 81319d39d9efdfc1e04fd1601d2893a859659c35 Author: Suresh Jayaraman Date: Fri Dec 2 16:24:56 2011 +0530 cifs: fix cifs stable patch cifs-fix-oplock-break-handling-try-2.patch commit 4708ad6374f07cdfb379c5d4100125e2cfd339d9 in v2.6.32.x stable The stable release 2.6.32.32 added the upstream commit 12fed00de963433128b5366a21a55808fab2f756. However, one of the hunks of the original patch seems missing from the stable backport which can be found here: http://permalink.gmane.org/gmane.linux.kernel.stable/5676 This hunk corresponds to the change in is_valid_oplock_break() at fs/cifs/misc.c. This patch backports the missing hunk and is against linux-2.6.32.y stable kernel. Cc: Steve French Signed-off-by: Pavel Shilovsky Signed-off-by: Suresh Jayaraman Signed-off-by: Greg Kroah-Hartman [PG: I incorrectly dropped the same hunk in v2.6.34.9-152-g0c55f20 since the code in question was relocated/rewritten in e66673e39a ] Signed-off-by: Paul Gortmaker commit f26d467257a1c27518298b26f649983a543348c5 Author: Daniel T Chen Date: Sun Dec 5 08:43:14 2010 -0500 ALSA: hda: Use position_fix=1 for Acer Aspire 5538 to enable capture on internal mic commit dd5a089edfa51a74692604b4b427953d8e16bc35 upstream. BugLink: https://launchpad.net/bugs/685161 The reporter of the bug states that he must use position_fix=1 to enable capture for the internal microphone, so set it for his machine's PCI SSID. Verified using 2.6.35 and the 2010-12-04 alsa-driver build. Reported-and-tested-by: Ralph Wabel Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 2691b134384fd84250cca21c6d8e098d990922eb Author: Seth Heasley Date: Wed Apr 20 10:59:57 2011 -0700 ALSA: hda - ALSA HD Audio patch for Intel Panther Point DeviceIDs commit d2edeb7c6f1dada8ca7d5c23e42d604e92ae0c76 upstream. This patch adds the HD Audio Controller DeviceIDs for the Intel Panther Point PCH. Signed-off-by: Seth Heasley Signed-off-by: Takashi Iwai commit f6c427256e950ab3bb80970b45a65650553684a3 Author: Takashi Iwai Date: Wed Sep 15 10:17:26 2010 +0200 ALSA: hda - Reduce pci id list for Intel with class id commit b686453543fd56332e8730a2abd7bf5bca756149 upstream. Most of Intel controllers work as generic HD-audio without quirks, and it'll be hopefully so in future. Let's mark pci id with the PCI_CLASS_MULTIMEDIA_HD_AUDIO for Intel so that the driver will work with any new control chips in future. Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit b667b4d20ef739ab2331cf04eac0a501ff81a15d Author: Bankim Bhavsar Date: Mon Jan 17 15:23:21 2011 +0100 ALSA: hda - Add support for VMware controller commit 0f0714c5ed0a98fdeaa2287d3b159989bbe6d842 upstream. Add the new PCI ID 0x15ad and device ID 0x1977 for VMware HDAudio Controller. [changed to use AZX_DRIVER_GENERIC by tiwai] Signed-off-by: Bankim Bhavsar Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit d577ff2260e16b55665cdb7946e57167395c5ba7 Author: Otavio Salvador Date: Sun Sep 26 23:35:06 2010 -0300 ALSA: hda: add Vortex86MX PCI ids commit e35d4b119578a054515ccb4ed5dddc4e8a81ec15 upstream. Signed-off-by: Otavio Salvador Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit f07432f17f8154531923da92f64c0491bf3a708c Author: Seth Heasley Date: Fri Sep 10 16:29:56 2010 -0700 ALSA: hda_intel: ALSA HD Audio patch for Intel Patsburg DeviceIDs commit cea310e8f8702226f982f09386cfd3c5793c5e2f upstream. This patch adds the Intel Patsburg (PCH) HD Audio Controller DeviceIDs. Signed-off-by: Seth Heasley Signed-off-by: Takashi Iwai Signed-off-by: Paul Gortmaker commit 7d607e3f0b69385d5bad235de855aafd724a728f Author: John Stultz Date: Mon Sep 17 21:38:47 2012 -0400 time: Move ktime_t overflow checking into timespec_valid_strict commit cee58483cf56e0ba355fdd97ff5e8925329aa936 upstream. Andreas Bombe reported that the added ktime_t overflow checking added to timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of timekeeping inputs") was causing problems with X.org because it caused timeouts larger then KTIME_T to be invalid. Previously, these large timeouts would be clamped to KTIME_MAX and would never expire, which is valid. This patch splits the ktime_t overflow checking into a new timespec_valid_strict function, and converts the timekeeping codes internal checking to use this more strict function. Reported-and-tested-by: Andreas Bombe Cc: Zhouping Liu Cc: Ingo Molnar Cc: Prarit Bhargava Cc: Thomas Gleixner Signed-off-by: John Stultz Signed-off-by: Linus Torvalds Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit b4e2564c9f5ba83af10076d029a7507b7a33b870 Author: John Stultz Date: Mon Sep 17 21:38:46 2012 -0400 time: Avoid making adjustments if we haven't accumulated anything commit bf2ac312195155511a0f79325515cbb61929898a upstream. If update_wall_time() is called and the current offset isn't large enough to accumulate, avoid re-calling timekeeping_adjust which may change the clock freq and can cause 1ns inconsistencies with CLOCK_REALTIME_COARSE/CLOCK_MONOTONIC_COARSE. Signed-off-by: John Stultz Cc: Prarit Bhargava Cc: Ingo Molnar Link: http://lkml.kernel.org/r/1345595449-34965-5-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit 11ce0e7a9396b85a6f42cec5ec009d70d7b10652 Author: John Stultz Date: Mon Sep 17 21:38:45 2012 -0400 time: Improve sanity checking of timekeeping inputs commit 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b upstream. Unexpected behavior could occur if the time is set to a value large enough to overflow a 64bit ktime_t (which is something larger then the year 2262). Also unexpected behavior could occur if large negative offsets are injected via adjtimex. So this patch improves the sanity check timekeeping inputs by improving the timespec_valid() check, and then makes better use of timespec_valid() to make sure we don't set the time to an invalid negative value or one that overflows ktime_t. Note: This does not protect from setting the time close to overflowing ktime_t and then letting natural accumulation cause the overflow. Reported-by: CAI Qian Reported-by: Sasha Levin Signed-off-by: John Stultz Cc: Peter Zijlstra Cc: Prarit Bhargava Cc: Zhouping Liu Cc: Ingo Molnar Link: http://lkml.kernel.org/r/1344454580-17031-1-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz Signed-off-by: Paul Gortmaker commit eee8446c57d5033f79086f29c7a0490a28ec5685 Author: Jason Wang Date: Wed May 30 21:18:10 2012 +0000 net: sock: validate data_len before allocating skb in sock_alloc_send_pskb() commit cc9b17ad29ecaa20bfe426a8d4dbfb94b13ff1cc upstream. We need to validate the number of pages consumed by data_len, otherwise frags array could be overflowed by userspace. So this patch validate data_len and return -EMSGSIZE when data_len may occupies more frags than MAX_SKB_FRAGS. Signed-off-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Paul Gortmaker