commit 2396403a0402caf7b9decbc5d206fa63ba62b6b7 Author: Greg Kroah-Hartman Date: Tue Apr 16 22:11:28 2013 -0700 Linux 3.8.8 commit 77d0ca8b5d7e7cd48005ddb79b05c79082a68bb5 Author: Sebastian Andrzej Siewior Date: Tue Dec 25 23:02:48 2012 +0100 tty: don't deadlock while flushing workqueue commit 852e4a8152b427c3f318bb0e1b5e938d64dcdc32 upstream. Since commit 89c8d91e31f2 ("tty: localise the lock") I see a dead lock in one of my dummy_hcd + g_nokia test cases. The first run was usually okay, the second often resulted in a splat by lockdep and the third was usually a dead lock. Lockdep complained about tty->hangup_work and tty->legacy_mutex taken both ways: | ====================================================== | [ INFO: possible circular locking dependency detected ] | 3.7.0-rc6+ #204 Not tainted | ------------------------------------------------------- | kworker/2:1/35 is trying to acquire lock: | (&tty->legacy_mutex){+.+.+.}, at: [] tty_lock_nested+0x36/0x80 | | but task is already holding lock: | ((&tty->hangup_work)){+.+...}, at: [] process_one_work+0x124/0x5e0 | | which lock already depends on the new lock. | | the existing dependency chain (in reverse order) is: | | -> #2 ((&tty->hangup_work)){+.+...}: | [] lock_acquire+0x84/0x190 | [] flush_work+0x3d/0x240 | [] tty_ldisc_flush_works+0x16/0x30 | [] tty_ldisc_release+0x21/0x70 | [] tty_release+0x35c/0x470 | [] __fput+0xd8/0x270 | [] ____fput+0xd/0x10 | [] task_work_run+0xb9/0xf0 | [] do_notify_resume+0x51/0x80 | [] work_notifysig+0x35/0x3b | | -> #1 (&tty->legacy_mutex/1){+.+...}: | [] lock_acquire+0x84/0x190 | [] mutex_lock_nested+0x6c/0x2f0 | [] tty_lock_nested+0x36/0x80 | [] tty_lock_pair+0x29/0x70 | [] tty_release+0x118/0x470 | [] __fput+0xd8/0x270 | [] ____fput+0xd/0x10 | [] task_work_run+0xb9/0xf0 | [] do_notify_resume+0x51/0x80 | [] work_notifysig+0x35/0x3b | | -> #0 (&tty->legacy_mutex){+.+.+.}: | [] __lock_acquire+0x1189/0x16a0 | [] lock_acquire+0x84/0x190 | [] mutex_lock_nested+0x6c/0x2f0 | [] tty_lock_nested+0x36/0x80 | [] tty_lock+0xf/0x20 | [] __tty_hangup+0x54/0x410 | [] do_tty_hangup+0x12/0x20 | [] process_one_work+0x1a3/0x5e0 | [] worker_thread+0x119/0x3a0 | [] kthread+0x94/0xa0 | [] ret_from_kernel_thread+0x1b/0x28 | |other info that might help us debug this: | |Chain exists of: | &tty->legacy_mutex --> &tty->legacy_mutex/1 --> (&tty->hangup_work) | | Possible unsafe locking scenario: | | CPU0 CPU1 | ---- ---- | lock((&tty->hangup_work)); | lock(&tty->legacy_mutex/1); | lock((&tty->hangup_work)); | lock(&tty->legacy_mutex); | | *** DEADLOCK *** Before the path mentioned tty_ldisc_release() look like this: | tty_ldisc_halt(tty); | tty_ldisc_flush_works(tty); | tty_lock(); As it can be seen, it first flushes the workqueue and then grabs the tty_lock. Now we grab the lock first: | tty_lock_pair(tty, o_tty); | tty_ldisc_halt(tty); | tty_ldisc_flush_works(tty); so lockdep's complaint seems valid. The earlier version of this patch took the ldisc_mutex since the other user of tty_ldisc_flush_works() (tty_set_ldisc()) did this. Peter Hurley then said that it is should not be requried. Since it wasn't done earlier, I dropped this part. The code under tty_ldisc_kill() was executed earlier with the tty lock taken so it is taken again. I was able to reproduce the deadlock on v3.8-rc1, this patch fixes the problem in my testcase. I didn't notice any problems so far. Signed-off-by: Sebastian Andrzej Siewior Cc: Alan Cox Cc: Peter Hurley Cc: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit 00c33275b78637fc5423ce05dd5e886836544eb1 Author: Boris Ostrovsky Date: Sat Mar 23 09:36:36 2013 -0400 x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal commit 511ba86e1d386f671084b5d0e6f110bb30b8eeb2 upstream. Invoking arch_flush_lazy_mmu_mode() results in calls to preempt_enable()/disable() which may have performance impact. Since lazy MMU is not used on bare metal we can patch away arch_flush_lazy_mmu_mode() so that it is never called in such environment. [ hpa: the previous patch "Fix vmalloc_fault oops during lazy MMU updates" may cause a minor performance regression on bare metal. This patch resolves that performance regression. It is somewhat unclear to me if this is a good -stable candidate. ] Signed-off-by: Boris Ostrovsky Link: http://lkml.kernel.org/r/1364045796-10720-2-git-send-email-konrad.wilk@oracle.com Tested-by: Josh Boyer Tested-by: Konrad Rzeszutek Wilk Acked-by: Borislav Petkov Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit a1df5f936a0aea88cbc41555e473c89f1384a64d Author: Samu Kallio Date: Sat Mar 23 09:36:35 2013 -0400 x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates commit 1160c2779b826c6f5c08e5cc542de58fd1f667d5 upstream. In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops when lazy MMU updates are enabled, because set_pgd effects are being deferred. One instance of this problem is during process mm cleanup with memory cgroups enabled. The chain of events is as follows: - zap_pte_range enables lazy MMU updates - zap_pte_range eventually calls mem_cgroup_charge_statistics, which accesses the vmalloc'd mem_cgroup per-cpu stat area - vmalloc_fault is triggered which tries to sync the corresponding PGD entry with set_pgd, but the update is deferred - vmalloc_fault oopses due to a mismatch in the PUD entries The OOPs usually looks as so: ------------[ cut here ]------------ kernel BUG at arch/x86/mm/fault.c:396! invalid opcode: 0000 [#1] SMP .. snip .. CPU 1 Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1 RIP: e030:[] [] vmalloc_fault+0x11f/0x208 .. snip .. Call Trace: [] do_page_fault+0x399/0x4b0 [] ? xen_mc_extend_args+0xec/0x110 [] page_fault+0x25/0x30 [] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50 [] __mem_cgroup_uncharge_common+0xd8/0x350 [] mem_cgroup_uncharge_page+0x57/0x60 [] page_remove_rmap+0xe0/0x150 [] ? vm_normal_page+0x1a/0x80 [] unmap_single_vma+0x531/0x870 [] unmap_vmas+0x52/0xa0 [] ? pte_mfn_to_pfn+0x72/0x100 [] exit_mmap+0x98/0x170 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e [] mmput+0x83/0xf0 [] exit_mm+0x104/0x130 [] do_exit+0x15a/0x8c0 [] do_group_exit+0x3f/0xa0 [] sys_exit_group+0x17/0x20 [] system_call_fastpath+0x16/0x1b Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the changes visible to the consistency checks. RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737 Tested-by: Josh Boyer Reported-and-Tested-by: Krishna Raman Signed-off-by: Samu Kallio Link: http://lkml.kernel.org/r/1364045796-10720-1-git-send-email-konrad.wilk@oracle.com Tested-by: Konrad Rzeszutek Wilk Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 092c48c05b0b25fdfca630441f34fd99b83deb1c Author: Thomas Gleixner Date: Sat Apr 6 10:10:27 2013 +0200 sched_clock: Prevent 64bit inatomicity on 32bit systems commit a1cbcaa9ea87b87a96b9fc465951dcf36e459ca2 upstream. The sched_clock_remote() implementation has the following inatomicity problem on 32bit systems when accessing the remote scd->clock, which is a 64bit value. CPU0 CPU1 sched_clock_local() sched_clock_remote(CPU0) ... remote_clock = scd[CPU0]->clock read_low32bit(scd[CPU0]->clock) cmpxchg64(scd->clock,...) read_high32bit(scd[CPU0]->clock) While the update of scd->clock is using an atomic64 mechanism, the readout on the remote cpu is not, which can cause completely bogus readouts. It is a quite rare problem, because it requires the update to hit the narrow race window between the low/high readout and the update must go across the 32bit boundary. The resulting misbehaviour is, that CPU1 will see the sched_clock on CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value to this bogus timestamp. This stays that way due to the clamping implementation for about 4 seconds until the synchronization with CLOCK_MONOTONIC undoes the problem. The issue is hard to observe, because it might only result in a less accurate SCHED_OTHER timeslicing behaviour. To create observable damage on realtime scheduling classes, it is necessary that the bogus update of CPU1 sched_clock happens in the context of an realtime thread, which then gets charged 4 seconds of RT runtime, which results in the RT throttler mechanism to trigger and prevent scheduling of RT tasks for a little less than 4 seconds. So this is quite unlikely as well. The issue was quite hard to decode as the reproduction time is between 2 days and 3 weeks and intrusive tracing makes it less likely, but the following trace recorded with trace_clock=global, which uses sched_clock_local(), gave the final hint: -0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80 -0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ... irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0 -0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80 What happens is that CPU0 goes idle and invokes sched_clock_idle_sleep_event() which invokes sched_clock_local() and CPU1 runs a remote wakeup for CPU0 at the same time, which invokes sched_remote_clock(). The time jump gets propagated to CPU0 via sched_remote_clock() and stays stale on both cores for ~4 seconds. There are only two other possibilities, which could cause a stale sched clock: 1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic wrong value. 2) sched_clock() which reads the TSC returns a sporadic wrong value. #1 can be excluded because sched_clock would continue to increase for one jiffy and then go stale. #2 can be excluded because it would not make the clock jump forward. It would just result in a stale sched_clock for one jiffy. After quite some brain twisting and finding the same pattern on other traces, sched_clock_remote() remained the only place which could cause such a problem and as explained above it's indeed racy on 32bit systems. So while on 64bit systems the readout is atomic, we need to verify the remote readout on 32bit machines. We need to protect the local->clock readout in sched_clock_remote() on 32bit as well because an NMI could hit between the low and the high readout, call sched_clock_local() and modify local->clock. Thanks to Siegfried Wulsch for bearing with my debug requests and going through the tedious tasks of running a bunch of reproducer systems to generate the debug information which let me decode the issue. Reported-by: Siegfried Wulsch Acked-by: Peter Zijlstra Cc: Steven Rostedt Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 103d7cb05682db5a57e40b96f2029be91171c112 Author: Steven Rostedt (Red Hat) Date: Fri Apr 12 16:40:13 2013 -0400 ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section commit 7f49ef69db6bbf756c0abca7e9b65b32e999eec8 upstream. As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the ftrace_pid_fops is defined when DYNAMIC_FTRACE is not. Signed-off-by: Steven Rostedt Cc: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit 69bcccfef278d0b58b684fbd3ead0c52e4384d53 Author: Dave Airlie Date: Fri Apr 12 13:25:20 2013 +1000 udl: handle EDID failure properly. commit 1baee58638fc58248625255f5c5fcdb987f11b1f upstream. Don't oops seems proper. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit bea692a5004128c029112632c546e320d71fe99d Author: Namhyung Kim Date: Thu Apr 11 15:55:01 2013 +0900 tracing: Fix possible NULL pointer dereferences commit 6a76f8c0ab19f215af2a3442870eeb5f0e81998d upstream. Currently set_ftrace_pid and set_graph_function files use seq_lseek for their fops. However seq_open() is called only for FMODE_READ in the fops->open() so that if an user tries to seek one of those file when she open it for writing, it sees NULL seq_file and then panic. It can be easily reproduced with following command: $ cd /sys/kernel/debug/tracing $ echo 1234 | sudo tee -a set_ftrace_pid In this example, GNU coreutils' tee opens the file with fopen(, "a") and then the fopen() internally calls lseek(). Link: http://lkml.kernel.org/r/1365663302-2170-1-git-send-email-namhyung@kernel.org Signed-off-by: Namhyung Kim Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: stable@vger.kernel.org Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 324cdc3f7e6a752fe0e95fa7b5c9664171a34ded Author: Dave Hansen Date: Fri Apr 12 16:23:54 2013 -0700 x86-32: Fix possible incomplete TLB invalidate with PAE pagetables commit 1de14c3c5cbc9bb17e9dcc648cda51c0c85d54b9 upstream. This patch attempts to fix: https://bugzilla.kernel.org/show_bug.cgi?id=56461 The symptom is a crash and messages like this: chrome: Corrupted page table at address 34a03000 *pdpt = 0000000000000000 *pde = 0000000000000000 Bad pagetable: 000f [#1] PREEMPT SMP Ingo guesses this got introduced by commit 611ae8e3f520 ("x86/tlb: enable tlb flush range support for x86") since that code started to free unused pagetables. On x86-32 PAE kernels, that new code has the potential to free an entire PMD page and will clear one of the four page-directory-pointer-table (aka pgd_t entries). The hardware aggressively "caches" these top-level entries and invlpg does not actually affect the CPU's copy. If we clear one we *HAVE* to do a full TLB flush, otherwise we might continue using a freed pmd page. (note, we do this properly on the population side in pud_populate()). This patch tracks whenever we clear one of these entries in the 'struct mmu_gather', and ensures that we follow up with a full tlb flush. BTW, I disassembled and checked that: if (tlb->fullmm == 0) and if (!tlb->fullmm && !tlb->need_flush_all) generate essentially the same code, so there should be zero impact there to the !PAE case. Signed-off-by: Dave Hansen Cc: Peter Anvin Cc: Ingo Molnar Cc: Artem S Tashkinov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit aabc281d18eef3106c9f58c06e466a9ffdf33759 Author: Haojian Zhuang Date: Sun Feb 17 19:42:48 2013 +0800 gpio: fix wrong checking condition for gpio range commit ad4e1a7caf937ad395ced585ca85a7d14395dc80 upstream. If index++ calculates from 0, the checking condition of "while (index++)" fails & it doesn't check any more. It doesn't follow the loop that used at here. Replace it by endless loop at here. Then it keeps parsing "gpio-ranges" property until it ends. Signed-off-by: Haojian Zhuang Reviewed-by: Linus Walleij Signed-off-by: Linus Walleij Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit b5caeae8219e3b90000e7413e2e0a272db8e2c20 Author: Linus Torvalds Date: Sat Apr 13 15:15:30 2013 -0700 kobject: fix kset_find_obj() race with concurrent last kobject_put() commit a49b7e82cab0f9b41f483359be83f44fbb6b4979 upstream. Anatol Pomozov identified a race condition that hits module unloading and re-loading. To quote Anatol: "This is a race codition that exists between kset_find_obj() and kobject_put(). kset_find_obj() might return kobject that has refcount equal to 0 if this kobject is freeing by kobject_put() in other thread. Here is timeline for the crash in case if kset_find_obj() searches for an object tht nobody holds and other thread is doing kobject_put() on the same kobject: THREAD A (calls kset_find_obj()) THREAD B (calls kobject_put()) splin_lock() atomic_dec_return(kobj->kref), counter gets zero here ... starts kobject cleanup .... spin_lock() // WAIT thread A in kobj_kset_leave() iterate over kset->list atomic_inc(kobj->kref) (counter becomes 1) spin_unlock() spin_lock() // taken // it does not know that thread A increased counter so it remove obj from list spin_unlock() vfree(module) // frees module object with containing kobj // kobj points to freed memory area!! kobject_put(kobj) // OOPS!!!! The race above happens because module.c tries to use kset_find_obj() when somebody unloads module. The module.c code was introduced in commit 6494a93d55fa" Anatol supplied a patch specific for module.c that worked around the problem by simply not using kset_find_obj() at all, but rather than make a local band-aid, this just fixes kset_find_obj() to be thread-safe using the proper model of refusing the get a new reference if the refcount has already dropped to zero. See examples of this proper refcount handling not only in the kref documentation, but in various other equivalent uses of this pattern by grepping for atomic_inc_not_zero(). [ Side note: the module race does indicate that module loading and unloading is not properly serialized wrt sysfs information using the module mutex. That may require further thought, but this is the correct fix at the kobject layer regardless. ] Reported-analyzed-and-tested-by: Anatol Pomozov Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7e59255a79c958e7f114f098896924ea86fc4967 Author: Suleiman Souhlal Date: Sat Apr 13 16:03:06 2013 -0700 vfs: Revert spurious fix to spinning prevention in prune_icache_sb commit 5b55d708335a9e3e4f61f2dadf7511502205ccd1 upstream. Revert commit 62a3ddef6181 ("vfs: fix spinning prevention in prune_icache_sb"). This commit doesn't look right: since we are looking at the tail of the list (sb->s_inode_lru.prev) if we want to skip an inode, we should put it back at the head of the list instead of the tail, otherwise we will keep spinning on it. Discovered when investigating why prune_icache_sb came top in perf reports of a swapping load. Signed-off-by: Suleiman Souhlal Signed-off-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 51fd56450d83624ca98c5e9e9340c3c6165ead6f Author: Nicholas Bellinger Date: Wed Apr 10 15:00:27 2013 -0700 target: Fix incorrect fallthrough of ALUA Standby/Offline/Transition CDBs commit 30f359a6f9da65a66de8cadf959f0f4a0d498bba upstream. This patch fixes a bug where a handful of informational / control CDBs that should be allowed during ALUA access state Standby/Offline/Transition where incorrectly returning CHECK_CONDITION + ASCQ_04H_ALUA_TG_PT_*. This includes INQUIRY + REPORT_LUNS, which would end up preventing LUN registration when LUN scanning occured during these ALUA access states. Signed-off-by: Nicholas Bellinger Cc: Hannes Reinecke Signed-off-by: Greg Kroah-Hartman commit 30b1addb438fe0480d6e4c78bb8f66040840f8ac Author: Sachin Prabhu Date: Tue Apr 9 18:17:41 2013 +0100 cifs: Allow passwords which begin with a delimitor commit c369c9a4a7c82d33329d869cbaf93304cc7a0c40 upstream. Fixes a regression in cifs_parse_mount_options where a password which begins with a delimitor is parsed incorrectly as being a blank password. Signed-off-by: Sachin Prabhu Acked-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 978ddcd80a05229e14d8f078ee99bbf2d0f71867 Author: Lukasz Dorau Date: Wed Apr 3 10:27:17 2013 +0200 SCSI: libsas: fix handling vacant phy in sas_set_ex_phy() commit d4a2618fa77b5e58ec15342972bd3505a1c3f551 upstream. If a result of the SMP discover function is PHY VACANT, the content of discover response structure (dr) is not valid. It sometimes happens that dr->attached_sas_addr can contain even SAS address of other phy. In such case an invalid phy is created, what causes NULL pointer dereference during destruction of expander's phys. So if a result of SMP function is PHY VACANT, the content of discover response structure (dr) must not be copied to phy structure. This patch fixes the following bug: BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 IP: [] sysfs_find_dirent+0x12/0x90 Call Trace: [] sysfs_get_dirent+0x35/0x80 [] sysfs_unmerge_group+0x1e/0xb0 [] dpm_sysfs_remove+0x24/0x90 [] device_del+0x44/0x1d0 [] sas_rphy_delete+0x9/0x20 [scsi_transport_sas] [] sas_destruct_devices+0xe6/0x110 [libsas] [] process_one_work+0x16c/0x350 [] worker_thread+0x17a/0x410 [] kthread+0x96/0xa0 [] kernel_thread_helper+0x4/0x10 Signed-off-by: Lukasz Dorau Signed-off-by: Pawel Baldysiak Reviewed-by: Maciej Patelczyk Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 16deae329e6b9a0a500d70c0cc4023c799b644d9 Author: Wei Yongjun Date: Mon Mar 11 23:01:37 2013 +0800 GFS2: return error if malloc failed in gfs2_rs_alloc() commit 441362d06be349430d06e37286adce4b90e6ce96 upstream. The error code in gfs2_rs_alloc() is set to ENOMEM when error but never be used, instead, gfs2_rs_alloc() always return 0. Fix to return 'error'. Signed-off-by: Wei Yongjun Signed-off-by: Steven Whitehouse Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit a7d0c9176bb6e15c483a020816b2ecb60716f79a Author: Steven Whitehouse Date: Thu Mar 14 15:49:59 2013 +0000 GFS2: Fix unlock of fcntl locks during withdrawn state commit c2952d202f710d326ac36a8ea6bd216b20615ec8 upstream. When withdraw occurs, we need to continue to allow unlocks of fcntl locks to occur, however these will only be local, since the node has withdrawn from the cluster. This prevents triggering a VFS level bug trap due to locks remaining when a file is closed. Signed-off-by: Steven Whitehouse Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit fccf4d03235294c978b2390a9ce575b33b0fbe5a Author: Stanislav Kinsbursky Date: Mon Apr 1 11:40:51 2013 +0400 ipc: set msg back to -EAGAIN if copy wasn't performed commit 2dc958fa2fe6987e7ab106bd97029a09a82fcd8d upstream. Make sure that msg pointer is set back to error value in case of MSG_COPY flag is set and desired message to copy wasn't found. This garantees that msg is either a error pointer or a copy address. Otherwise the last message in queue will be freed without unlinking from the queue (which leads to memory corruption) and the dummy allocated copy won't be released. Signed-off-by: Stanislav Kinsbursky Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 95ffc2b9c20c201cead468e1fe185b8c11f9a55b Author: John W. Linville Date: Wed Mar 27 10:52:11 2013 -0400 Revert "brcmsmac: support 4313iPA" commit 54683441a92ebe20c5282465ea6f21e5e74d2974 upstream. This reverts commit b6fc28a158076ca2764edc9a6d1e1402f56e1c0c. This commit is reported to cause a regression in the support for some revisions of 4313 ePA devices. http://marc.info/?l=linux-wireless&m=136360340200943&w=2 Conflicts: drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c Reported-by: David Herrmann Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit e7beff2c4534ee98a6934cf0704d5c10dd343208 Author: Huacai Chen Date: Sun Apr 7 02:14:14 2013 +0000 PM / reboot: call syscore_shutdown() after disable_nonboot_cpus() commit 6f389a8f1dd22a24f3d9afc2812b30d639e94625 upstream. As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core subsystems PM) say, syscore_ops operations should be carried with one CPU on-line and interrupts disabled. However, after commit f96972f2d (kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()), syscore_shutdown() is called before disable_nonboot_cpus(), so break the rules. We have a MIPS machine with a 8259A PIC, and there is an external timer (HPET) linked at 8259A. Since 8259A has been shutdown too early (by syscore_shutdown()), disable_nonboot_cpus() runs without timer interrupt, so it hangs and reboot fails. This patch call syscore_shutdown() a little later (after disable_nonboot_cpus()) to avoid reboot failure, this is the same way as poweroff does. For consistency, add disable_nonboot_cpus() to kernel_halt(). Signed-off-by: Huacai Chen Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 2182bc06086014173a9474e1ba4eb5c556b509f0 Author: Peter Ujfalusi Date: Tue Apr 9 16:33:06 2013 +0200 dmaengine: omap-dma: Start DMA without delay for cyclic channels commit 765024697807ad1e1cac332aa891253ca4a339da upstream. cyclic DMA is only used by audio which needs DMA to be started without a delay. If the DMA for audio is started using the tasklet we experience random channel switch (to be more precise: channel shift). Reported-by: Peter Meerwald Signed-off-by: Peter Ujfalusi Acked-by: Santosh Shilimkar Acked-by: Russell King Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit de8a06fed88ff8cfe3a26dca3775d8cc625684f2 Author: Markus Pargmann Date: Fri Mar 29 16:20:10 2013 +0100 ARM: imx35 Bugfix admux clock commit 75498083e25e96932ad998ffdeadb17234c68d3a upstream. The admux clock seems to be the audmux clock as tests show. audmux does not work without this clock enabled. Currently imx35 does not register a clock device for audmux. This patch adds this registration. imx-audmux driver already handles a clock device, so no changes are necessary there. Signed-off-by: Markus Pargmann Signed-off-by: Sascha Hauer Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 1e9c377334f3c41f9cd2c31e12b72bed13028a9a Author: Nigel Roberts Date: Mon Apr 1 23:03:22 2013 +1100 ARM: Kirkwood: Fix typo in the definition of ix2-200 rebuild LED commit 8f08d6667287241f6818d35e02b223fb5df97cf1 upstream. In the conversion to pinctrl, an error in the pins for the rebuild LED was introduced. This patch assigns the correct pins and includes the correct name for the LED in kirkwood-iomega_ix2_200.dts. Signed-off-by: Nigel Roberts Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 0678762860d16c9434b60a07312fa2c73aeefb3b Author: Namhyung Kim Date: Mon Apr 1 21:46:23 2013 +0900 tracing: Fix double free when function profile init failed commit 83e03b3fe4daffdebbb42151d5410d730ae50bd1 upstream. On the failure path, stat->start and stat->pages will refer same page. So it'll attempt to free the same page again and get kernel panic. Link: http://lkml.kernel.org/r/1364820385-32027-1-git-send-email-namhyung@kernel.org Signed-off-by: Namhyung Kim Cc: Frederic Weisbecker Cc: Namhyung Kim Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit c6277b3e6d21c46a34b31b1a1221189de5f10ec8 Author: Alban Bedel Date: Tue Apr 9 17:13:59 2013 +0200 ASoC: wm8903: Fix the bypass to HP/LINEOUT when no DAC or ADC is running commit f1ca493b0b5e8f42d3b2dc8877860db2983f47b6 upstream. The Charge Pump needs the DSP clock to work properly, without it the bypass to HP/LINEOUT is not working properly. This requirement is not mentioned in the datasheet but has been confirmed by Mark Brown from Wolfson. Signed-off-by: Alban Bedel Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit eb86a770e10a9e2f67e3c338b0eec287092dddaf Author: Mark Brown Date: Fri Apr 5 13:19:26 2013 +0100 ASoC: wm5102: Correct lookup of arizona struct in SYSCLK event commit f6f629f8332ea70255f6c60c904270640a21a114 upstream. Reported-by: Ryo Tsutsui Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8047d57ee07e9cd7f4899c1f7961f8d73faa24c8 Author: Joonyoung Shim Date: Tue Mar 26 14:41:05 2013 +0900 ASoC: core: Fix to check return value of snd_soc_update_bits_locked() commit 0eaa6cca1f75e12e4f5ec62cbe887330fe3b5fe9 upstream. It can be 0 or 1 return value of snd_soc_update_bits_locked() when it is success. So just check return value is negative. Signed-off-by: Joonyoung Shim Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 958ccdb1e6c60c9a1553963a6d7311683cd0cccc Author: Eldad Zack Date: Fri Apr 5 20:49:46 2013 +0200 ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_* commit 889d66848b12d891248b03abcb2a42047f8e172a upstream. The usb_control_msg() function expects __u16 types and performs the endianness conversions by itself. However, in three places, a conversion is performed before it is handed over to usb_control_msg(), which leads to a double conversion (= no conversion): * snd_usb_nativeinstruments_boot_quirk() * snd_nativeinstruments_control_get() * snd_nativeinstruments_control_put() Caught by sparse: sound/usb/mixer_quirks.c:512:38: warning: incorrect type in argument 6 (different base types) sound/usb/mixer_quirks.c:512:38: expected unsigned short [unsigned] [usertype] index sound/usb/mixer_quirks.c:512:38: got restricted __le16 [usertype] sound/usb/mixer_quirks.c:543:35: warning: incorrect type in argument 5 (different base types) sound/usb/mixer_quirks.c:543:35: expected unsigned short [unsigned] [usertype] value sound/usb/mixer_quirks.c:543:35: got restricted __le16 [usertype] sound/usb/mixer_quirks.c:543:56: warning: incorrect type in argument 6 (different base types) sound/usb/mixer_quirks.c:543:56: expected unsigned short [unsigned] [usertype] index sound/usb/mixer_quirks.c:543:56: got restricted __le16 [usertype] sound/usb/quirks.c:502:35: warning: incorrect type in argument 5 (different base types) sound/usb/quirks.c:502:35: expected unsigned short [unsigned] [usertype] value sound/usb/quirks.c:502:35: got restricted __le16 [usertype] Signed-off-by: Eldad Zack Acked-by: Daniel Mack Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman