commit a2cfa87491c4ef47de3c4e0973ebb457019a3963 Author: Ben Hutchings Date: Fri May 11 13:15:38 2012 +0100 Linux 3.2.17 commit 3d3b4deaea79288bad25eedf6d72de533d9eebb0 Author: Paolo Pisati Date: Mon Apr 23 04:05:20 2012 +0000 smsc95xx: mark link down on startup and let PHY interrupt deal with carrier changes commit 07d69d4238418746a7b85c5d05ec17c658a2a390 upstream. Without this patch sysfs reports the cable as present flag@flag-desktop:~$ cat /sys/class/net/eth0/carrier 1 while it's not: flag@flag-desktop:~$ sudo mii-tool eth0 eth0: no link Tested on my Beagle XM. v2: added mantainer to the list of recipient Signed-off-by: Paolo Pisati Acked-by: Steve Glendinning Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 7d97c19bdbda447053a489811763837bbab20400 Author: Larry Finger Date: Sat Feb 25 18:10:21 2012 -0600 staging: r8712u: Fix regression caused by commit 8c213fa commit 2080913e017ab9f88379d93fd09546ad95faf87b upstream. In commit 8c213fa "staging: r8712u: Use asynchronous firmware loading", the command to release the firmware was placed in the wrong routine. In combination with the bug introduced in commit a5ee652 "staging: r8712u: Interface-state not fully tracked", the driver attempts to upload firmware that had already been released. This bug is the source of one of the problems in https://bugs.archlinux.org/task/27996#comment89833. Tested-by: Alberto Lago Ballesteros Tested-by: Adrian Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 82b8227228169ca4c3b138f6ad1171913c14f784 Author: Oleg Nesterov Date: Mon Mar 19 17:03:41 2012 +0100 exit_signal: fix the "parent has changed security domain" logic commit b6e238dceed36891cc633167afe7151f1f3d83c5 upstream. exit_notify() changes ->exit_signal if the parent already did exec. This doesn't really work, we are not going to send the signal now if there is another live thread or the exiting task is traced. The parent can exec before the last dies or the tracer detaches. Move this check into do_notify_parent() which actually sends the signal. The user-visible change is that we do not change ->exit_signal, and thus the exiting task is still "clone children" for do_wait()->eligible_child(__WCLONE). Hopefully this is fine, the current logic is racy anyway. Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 3dc731904fb3bad1d3dbd8870cf4461fb2b31680 Author: Oleg Nesterov Date: Mon Mar 19 17:03:22 2012 +0100 exit_signal: simplify the "we have changed execution domain" logic commit e636825346b36a07ccfc8e30946d52855e21f681 upstream. exit_notify() checks "tsk->self_exec_id != tsk->parent_exec_id" to handle the "we have changed execution domain" case. We can change do_thread() to always set ->exit_signal = SIGCHLD and remove this check to simplify the code. We could change setup_new_exec() instead, this looks more logical because it increments ->self_exec_id. But note that de_thread() already resets ->exit_signal if it changes the leader, let's keep both changes close to each other. Note that we change ->exit_signal lockless, this changes the rules. Thereafter ->exit_signal is not stable under tasklist but this is fine, the only possible change is OLDSIG -> SIGCHLD. This can race with eligible_child() but the race is harmless. We can race with reparent_leader() which changes our ->exit_signal in parallel, but it does the same change to SIGCHLD. The noticeable user-visible change is that the execing task is not "visible" to do_wait()->eligible_child(__WCLONE) right after exec. To me this looks more logical, and this is consistent with mt case. Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 20d6f19dca576a671ab61403c366c7154f802b36 Author: Wey-Yi Guy Date: Wed Apr 25 08:10:08 2012 -0700 iwlwifi: use 6000G2B for 6030 device series commit 1ed2ec37b44e86eaa8e0a03b908a39c80f65ee45 upstream. "iwlwifi: use correct released ucode version" change the ucode api ok from 6000G2 to 6000G2B, but it shall belong to 6030 device series, not the 6005 device series. Fix it Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 37273f55830f0919d543250d191e1633ff53841c Author: Meenakshi Venkataraman Date: Sun Apr 22 07:55:27 2012 -0700 iwlwifi: use correct released ucode version commit 78cbcf2b9dbe0565820dc7721316f9c401000a68 upstream. Report correctly the latest released version of the iwlwifi firmware for all iwlwifi-supported devices. Signed-off-by: Meenakshi Venkataraman Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 13cb8e3a067538c5aacc846a032985d2b608bccd Author: Johannes Berg Date: Fri Nov 4 07:22:37 2011 -0700 iwlagn: allow up to uCode API 6 for 6000 devices commit b914811524fbe9e91fe50845f5d7bd4316b8a6ee upstream. Since the uCode hasn't been released (yet?), warn only if using older than API 4, but load anything up to API 6. Signed-off-by: Johannes Berg Signed-off-by: Wey-Yi Guy Signed-off-by: Ben Hutchings commit 6ff650218928b98fd6efbbee38b9193815c70b29 Author: Tejun Heo Date: Fri Apr 27 10:54:35 2012 -0700 percpu, x86: don't use PMD_SIZE as embedded atom_size on 32bit commit d5e28005a1d2e67833852f4c9ea8ec206ea3ff85 upstream. With the embed percpu first chunk allocator, x86 uses either PAGE_SIZE or PMD_SIZE for atom_size. PMD_SIZE is used when CPU supports PSE so that percpu areas are aligned to PMD mappings and possibly allow using PMD mappings in vmalloc areas in the future. Using larger atom_size doesn't waste actual memory; however, it does require larger vmalloc space allocation later on for !first chunks. With reasonably sized vmalloc area, PMD_SIZE shouldn't be a problem but x86_32 at this point is anything but reasonable in terms of address space and using larger atom_size reportedly leads to frequent percpu allocation failures on certain setups. As there is no reason to not use PMD_SIZE on x86_64 as vmalloc space is aplenty and most x86_64 configurations support PSE, fix the issue by always using PMD_SIZE on x86_64 and PAGE_SIZE on x86_32. v2: drop cpu_has_pse test and make x86_64 always use PMD_SIZE and x86_32 PAGE_SIZE as suggested by hpa. Signed-off-by: Tejun Heo Reported-by: Yanmin Zhang Reported-by: ShuoX Liu Acked-by: H. Peter Anvin LKML-Reference: <4F97BA98.6010001@intel.com> Signed-off-by: Ben Hutchings commit c73681795660c13d4db341de3efdbda0a03c6873 Author: David Vrabel Date: Fri May 4 14:29:46 2012 +0100 xen/pci: don't use PCI BIOS service for configuration space accesses commit 76a8df7b49168509df02461f83fab117a4a86e08 upstream. The accessing PCI configuration space with the PCI BIOS32 service does not work in PV guests. On systems without MMCONFIG or where the BIOS hasn't marked the MMCONFIG region as reserved in the e820 map, the BIOS service is probed (even though direct access is preferred) and this hangs. Acked-by: Jan Beulich Signed-off-by: David Vrabel [v1: Fixed compile error when CONFIG_PCI is not set] Signed-off-by: Konrad Rzeszutek Wilk [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit acb6f21c725ce5007397a27bd0491d857ac4cdf9 Author: Konrad Rzeszutek Wilk Date: Thu May 3 16:14:14 2012 -0400 xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs commit b7e5ffe5d83fa40d702976d77452004abbe35791 upstream. If I try to do "cat /sys/kernel/debug/kernel_page_tables" I end up with: BUG: unable to handle kernel paging request at ffffc7fffffff000 IP: [] ptdump_show+0x221/0x480 PGD 0 Oops: 0000 [#1] SMP CPU 0 .. snip.. RAX: 0000000000000000 RBX: ffffc00000000fff RCX: 0000000000000000 RDX: 0000800000000000 RSI: 0000000000000000 RDI: ffffc7fffffff000 which is due to the fact we are trying to access a PFN that is not accessible to us. The reason (at least in this case) was that PGD[256] is set to __HYPERVISOR_VIRT_START which was setup (by the hypervisor) to point to a read-only linear map of the MFN->PFN array. During our parsing we would get the MFN (a valid one), try to look it up in the MFN->PFN tree and find it invalid and return ~0 as PFN. Then pte_mfn_to_pfn would happilly feed that in, attach the flags and return it back to the caller. 'ptdump_show' bitshifts it and gets and invalid value that it tries to dereference. Instead of doing all of that, we detect the ~0 case and just return !_PAGE_PRESENT. This bug has been in existence .. at least until 2.6.37 (yikes!) Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Ben Hutchings commit 84e1b0e68a91ec1acaa322009295b7d94ef386ed Author: Daniel Vetter Date: Sun May 6 16:50:24 2012 +0200 drm/i915: Do no set Stencil Cache eviction LRA w/a on gen7+ commit 2e7a44814d802c8ba479164b8924070cd908d6b5 upstream. I've flagged this while reviewing the first version and Ken Graunke fixed it up in v2, but unfortunately Dave Airlie picked up the wrong version. Cc: Dave Airlie Cc: Kenneth Graunke Signed-Off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit 071d3744d3f0a295c9c5483bda1714124bf22a26 Author: Daniel Vetter Date: Fri May 4 11:29:56 2012 +0200 drm/i915: disable sdvo hotplug on i945g/gm commit 768b107e4b3be0acf6f58e914afe4f337c00932b upstream. Chris Wilson dug out a hw erratum saying that there's noise on the interrupt line on i945G chips. We also have a bug report from a i945GM chip with an sdvo hotplug interrupt storm (and no apparent cause). Play it safe and disable sdvo hotplug on all i945 variants. Note that this is a regression that has been introduced in 3.1, when we've enabled sdvo hotplug support with commit cc68c81aed7d892deaf12d720d5455208e94cd0a Author: Simon Farnsworth Date: Wed Sep 21 17:13:30 2011 +0100 drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442 Reported-and-tested-by: Dominik Köppl Reviewed-by: Chris Wilson Signed-Off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit 2f03a6bb3e9dc3a1b5fb10c7885033809896c4f9 Author: Colin Cross Date: Sat May 5 20:58:13 2012 +0100 ARM: 7414/1: SMP: prevent use of the console when using idmap_pgd commit fde165b2a29673aabf18ceff14dea1f1cfb0daad upstream. Commit 4e8ee7de227e3ab9a72040b448ad728c5428a042 (ARM: SMP: use idmap_pgd for mapping MMU enable during secondary booting) switched secondary boot to use idmap_pgd, which is initialized during early_initcall, instead of a page table initialized during __cpu_up. This causes idmap_pgd to contain the static mappings but be missing all dynamic mappings. If a console is registered that creates a dynamic mapping, the printk in secondary_start_kernel will trigger a data abort on the missing mapping before the exception handlers have been initialized, leading to a hang. Initial boot is not affected because no consoles have been registered, and resume is usually not affected because the offending console is suspended. Onlining a cpu with hotplug triggers the problem. A workaround is to the printk in secondary_start_kernel until after the page tables have been switched back to init_mm. Signed-off-by: Colin Cross Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit 3e9221a04341a2e8380ad7f391c4c61cd4126387 Author: Tim Bird Date: Wed May 2 22:55:39 2012 +0100 ARM: 7410/1: Add extra clobber registers for assembly in kernel_execve commit e787ec1376e862fcea1bfd523feb7c5fb43ecdb9 upstream. The inline assembly in kernel_execve() uses r8 and r9. Since this code sequence does not return, it usually doesn't matter if the register clobber list is accurate. However, I saw a case where a particular version of gcc used r8 as an intermediate for the value eventually passed to r9. Because r8 is used in the inline assembly, and not mentioned in the clobber list, r9 was set to an incorrect value. This resulted in a kernel panic on execution of the first user-space program in the system. r9 is used in ret_to_user as the thread_info pointer, and if it's wrong, bad things happen. Signed-off-by: Tim Bird Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit 2fb30df3db02941cc3e0c2286faedcfd273855b4 Author: Kusanagi Kouichi Date: Sun Apr 1 17:29:32 2012 +0900 x86, relocs: Remove an unused variable commit 7c77cda0fe742ed07622827ce80963bbeebd1e3f upstream. sh_symtab is set but not used. [ hpa: putting this in urgent because of the sheer harmlessness of the patch: it quiets a build warning but does not change any generated code. ] Signed-off-by: Kusanagi Kouichi Link: http://lkml.kernel.org/r/20120401082932.D5E066FC03D@msa105.auone-net.jp Signed-off-by: H. Peter Anvin Signed-off-by: Ben Hutchings commit 7cfc66de8e3d207afacd8bca77c31cc21b4599df Author: H. Peter Anvin Date: Thu Apr 26 11:45:16 2012 -0700 asm-generic: Use __BITS_PER_LONG in statfs.h commit f5c2347ee20a8d6964d6a6b1ad04f200f8d4dfa7 upstream. is exported to userspace, so using BITS_PER_LONG is invalid. We need to use __BITS_PER_LONG instead. This is kernel bugzilla 43165. Reported-by: H.J. Lu Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/r/1335465916-16965-1-git-send-email-hpa@linux.intel.com Acked-by: Arnd Bergmann Signed-off-by: Ben Hutchings commit 76437939b2805edbbdd3ad658ccaaf4963b309f8 Author: Eric Bénard Date: Sun Apr 29 17:37:57 2012 +0200 ASoC: tlv312aic23: unbreak resume commit e875c1e3e758447ba81ca450d89434b3b0496d37 upstream. * commit f9dfbf9 "ASoC: tlv320aic23: convert to soc-cache" leads to a bug preventing resumeof the codec as regmap expects a 9 bits data register but 0xFFFF is passed in tlv320aic23_set_bias_level and this values gets cached preventing any write to the TLV320AIC23_PWR register as the final value produced by regmap is (register << 9) | value * this patch solves the problem by only working on the 9 bits the register contains. Signed-off-by: Eric Bénard Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit d4af6eb924ce29b9e46037134ca69ce085b5c36c Author: Greg Kroah-Hartman Date: Fri May 4 12:09:39 2012 -0700 hfsplus: Fix potential buffer overflows commit 6f24f892871acc47b40dd594c63606a17c714f77 upstream. Commit ec81aecb2966 ("hfs: fix a potential buffer overflow") fixed a few potential buffer overflows in the hfs filesystem. But as Timo Warns pointed out, these changes also need to be made on the hfsplus filesystem as well. Reported-by: Timo Warns Acked-by: WANG Cong Cc: Alexey Khoroshilov Cc: Miklos Szeredi Cc: Sage Weil Cc: Eugene Teo Cc: Roman Zippel Cc: Al Viro Cc: Christoph Hellwig Cc: Alexey Dobriyan Cc: Dave Anderson Cc: Andrew Morton Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit e4c7f8df58b0edfa1912cd54bded9d543693903e Author: Johannes Berg Date: Mon Apr 23 14:17:50 2012 -0700 iwlwifi: fix hardware queue programming commit 5ef4acd58ab2abd0dd0c8e3cacd61a0dc5d73646 upstream. Newer devices have 20 (5000 series) or 30 (6000 series) hardware queues, rather than the 16 that 4965 had. This was added to the driver a long time ago, but improperly: the queue registers for the higher queues aren't just continuations of the registers for the first 16 queues, they are in other places. Therefore, the hardware would lock up when trying to activate queue 16 or above and the device would have to be restarted. Thanks goes to Emmanuel who identified this and told me how the queue programming should be done. Note that we don't use queues 20 and higher today and doing so needs more work than this. Signed-off-by: Johannes Berg Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 77a23ae9ae9e552e885292b120d19434c25aad89 Author: Stanislaw Gruszka Date: Wed Apr 18 08:01:15 2012 -0700 iwlwifi: do not nulify ctx->vif on reset commit 8db4c7e25d153fb049e81715d72fa3be3a0c3b69 upstream. ctx->vif is dereferenced in different part of iwlwifi code, so do not nullify it. This should address at least one of the possible reasons of WARNING at iwlagn_mac_remove_interface, and perhaps some random crashes when firmware reset is performed. Signed-off-by: Stanislaw Gruszka Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville [bwh: Backported to 3.2: - Change filename iwl-mac80211.c to iwl-core.c - Change context in iwlagn_prepare_restart()] Signed-off-by: Ben Hutchings commit 5183d50f79157ba0c0e4fcdf882421e6bdabc562 Author: Grazvydas Ignotas Date: Thu Apr 26 23:07:44 2012 +0300 wl1251: fix crash on remove due to leftover work item commit 4c1bcdb5a3354b250b82a67549f57ac27a3bb85f upstream. This driver currently leaves elp_work behind when stopping, which occasionally results in data corruption because work function ends up accessing freed memory, typical symptoms of this are various worker_thread crashes. Fix it by cancelling elp_work. Signed-off-by: Grazvydas Ignotas Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 3c94aaf04ec842bbbf400277b09ec570874868d2 Author: Grazvydas Ignotas Date: Thu Apr 26 23:07:43 2012 +0300 wl1251: fix crash on remove due to premature kfree commit 328c32f0f85467af5a6c4c3289e168d9ad2555af upstream. Currently SDIO glue frees it's own structure before calling wl1251_free_hw(), which in turn calls ieee80211_unregister_hw(). The later call may result in a need to communicate with the chip to stop it (as it happens now if the interface is still up before rmmod), which means calls are made back to the glue, resulting in freed memory access. Fix this by freeing glue data last. Signed-off-by: Grazvydas Ignotas Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit f4f204d6a435431cee1f8a0d21417eaf4c53ef55 Author: Larry Finger Date: Thu Apr 19 21:39:06 2012 -0500 rtlwifi: Fix oops on unload commit 44eb65cfd8da4b9c231238998729e858e963a980 upstream. Under some circumstances, a PCI-based driver reports the following OOPs: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Oops: 0000 [#1] SMP --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Pid: 19627, comm: rmmod Not tainted 3.2.9-2.fc16.x86_64 #1 LENOVO 05962RU/05962RU Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP: 0010:[] [] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Process rmmod (pid: 19627, threadinfo ffff880050262000, task ffff8801156d5cc0) Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Stack: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000002 ffff8801176c2540 ffff880050263ca8 ffffffffa03348e7 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000282 0000000180150014 ffff880050263fd8 ffff8801176c2810 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] ffff880050263bc8 ffffffff810550e2 00000000000002c0 ffff8801176c0d40 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Call Trace: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] [] _rtl_pci_rx_interrupt+0x187/0x650 [rtlwifi] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Code: ff 09 d0 89 07 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 40 84 f6 89 d3 74 13 84 d2 75 57 <8b> 07 48 83 c4 08 5b 5d c1 e8 1f c3 0f 1f 00 84 d2 74 ed 80 fa Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP [] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RSP Mar 19 08:14:35 kvothe kernel: [ 6584.626011] CR2: 00000000000006e0 Mar 19 08:14:35 kvothe kernel: [ 6584.646491] ---[ end trace 8636c766dcfbe0e6 ]--- This oops is due to interrupts not being disabled in this particular path. Reported-by: Dave Airlie Tested-by: Dave Airlie Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit c2e6d36a26e541d06b75f69b4bf58c9a1f7285b4 Author: Felix Fietkau Date: Sun Apr 29 15:44:16 2012 +0200 mac80211: fix AP mode EAP tx for VLAN stations commit 66f2c99af3d6f2d0aa1120884cf1c60613ef61c0 upstream. EAP frames for stations in an AP VLAN are sent on the main AP interface to avoid race conditions wrt. moving stations. For that to work properly, sta_info_get_bss must be used instead of sta_info_get when sending EAP packets. Previously this was only done for cooked monitor injected packets, so this patch adds a check for tx->skb->protocol to the same place. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 12427fbf470faaf535915f4efc878eb46cb74c8c Author: Stanislav Yakovlev Date: Thu Apr 19 15:55:09 2012 -0400 ipw2200: Fix race condition in the command completion acknowledge commit dd447319895d0c0af423e483d9b63f84f3f8869a upstream. Driver incorrectly validates command completion: instead of waiting for a command to be acknowledged it continues execution. Most of the time driver gets acknowledge of the command completion in a tasklet before it executes the next one. But sometimes it sends the next command before it gets acknowledge for the previous one. In such a case one of the following error messages appear in the log: Failed to send SYSTEM_CONFIG: Already sending a command. Failed to send ASSOCIATE: Already sending a command. Failed to send TX_POWER: Already sending a command. After that you need to reload the driver to get it working again. This bug occurs during roaming (reported by Sam Varshavchik) https://bugzilla.redhat.com/show_bug.cgi?id=738508 and machine booting (reported by Tom Gundersen and Mads Kiilerich) https://bugs.archlinux.org/task/28097 https://bugzilla.redhat.com/show_bug.cgi?id=802106 This patch doesn't fix the delay issue during firmware load. But at least device now works as usual after boot. Signed-off-by: Stanislav Yakovlev Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit b110a7c55ab6ad4dc953396236451ff885326e5b Author: Roland Stigge Date: Wed Apr 4 10:34:37 2012 +0200 i2c: pnx: Disable clk in suspend commit 6c557cfee08751d22aed34840f389b846f0f4508 upstream. In the driver's suspend function, clk_enable() was used instead of clk_disable(). This is corrected with this patch. Signed-off-by: Roland Stigge Reviewed-by: Arnd Bergmann [wsa: reworded commit header slightly] Signed-off-by: Wolfram Sang Signed-off-by: Ben Hutchings commit 3123627c1824ab82fd08001c145d595d42f67def Author: Seth Forshee Date: Wed Apr 25 17:28:00 2012 -0500 b43: only reload config after successful initialization commit dbdedbdf4fbff3d4962a0786f37aa86dfdc48a7e upstream. Commit 2a19032 (b43: reload phy and bss settings after core restarts) introduced an unconditional call to b43_op_config() at the end of b43_op_start(). When firmware fails to load this can wedge the system. There's no need to reload the configuration after a failed initialization anyway, so only make the call if initialization was successful. BugLink: http://bugs.launchpad.net/bugs/950295 Cc: Felix Fietkau Signed-off-by: Seth Forshee Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 9846235aec215c33af3ed3758b67e31ff6981089 Author: Lin Ming Date: Thu May 3 22:15:07 2012 +0800 libata: skip old error history when counting probe trials commit 6868225e3e92399068be9a5f1635752d91012ad5 upstream. Commit d902747("[libata] Add ATA transport class") introduced ATA_EFLAG_OLD_ER to mark entries in the error ring as cleared. But ata_count_probe_trials_cb() didn't check this flag and it still counts the old error history. So wrong probe trials count is returned and it causes problem, for example, SATA link speed is slowed down from 3.0Gbps to 1.5Gbps. Fix it by checking ATA_EFLAG_OLD_ER in ata_count_probe_trials_cb(). Signed-off-by: Lin Ming Signed-off-by: Jeff Garzik Signed-off-by: Ben Hutchings commit f1f1ed7959ff53a7f7c15baf044964d3603f63ae Author: Kirill A. Shutemov Date: Mon Apr 30 09:18:01 2012 -0400 hwmon: (coretemp) fix oops on cpu unplug commit b704871124b477807966f06789c2b32f2de58bf7 upstream. coretemp tries to access core_data array beyond bounds on cpu unplug if core id of the cpu if more than NUM_REAL_CORES-1. BUG: unable to handle kernel NULL pointer dereference at 000000000000013c IP: [] coretemp_cpu_callback+0x93/0x1ba [coretemp] PGD 673e5a067 PUD 66e9b3067 PMD 0 Oops: 0000 [#1] SMP CPU 79 Modules linked in: sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter nf_conntrack_ipv4 nf_defrag_ipv4 ip6_tables xt_state nf_conntrack coretemp crc32c_intel asix tpm_tis pcspkr usbnet iTCO_wdt i2c_i801 microcode mii joydev tpm i2c_core iTCO_vendor_support tpm_bios i7core_edac igb ioatdma edac_core dca megaraid_sas [last unloaded: oprofile] Pid: 3315, comm: set-cpus Tainted: G W 3.4.0-rc5+ #2 QCI QSSC-S4R/QSSC-S4R RIP: 0010:[] [] coretemp_cpu_callback+0x93/0x1ba [coretemp] RSP: 0018:ffff880472fb3d48 EFLAGS: 00010246 RAX: 0000000000000124 RBX: 0000000000000034 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246 RBP: ffff880472fb3d88 R08: ffff88077fcd36c0 R09: 0000000000000001 R10: ffffffff8184bc48 R11: 0000000000000000 R12: ffff880273095800 R13: 0000000000000013 R14: ffff8802730a1810 R15: 0000000000000000 FS: 00007f694a20f720(0000) GS:ffff88077fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000000013c CR3: 000000067209b000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process set-cpus (pid: 3315, threadinfo ffff880472fb2000, task ffff880471fa0000) Stack: ffff880277b4c308 0000000000000003 ffff880472fb3d88 0000000000000005 0000000000000034 00000000ffffffd1 ffffffff81cadc70 ffff880472fb3e14 ffff880472fb3dc8 ffffffff8161f48d ffff880471fa0000 0000000000000034 Call Trace: [] notifier_call_chain+0x4d/0x70 [] __raw_notifier_call_chain+0xe/0x10 [] __cpu_notify+0x20/0x40 [] _cpu_down+0x81/0x270 [] cpu_down+0x37/0x50 [] store_online+0x63/0xc0 [] dev_attr_store+0x18/0x30 [] sysfs_write_file+0xef/0x170 [] vfs_write+0xb3/0x180 [] sys_write+0x4a/0x90 [] system_call_fastpath+0x16/0x1b Code: 48 c7 c7 94 60 01 a0 44 0f b7 ac 10 ac 00 00 00 31 c0 e8 41 b7 5f e1 41 83 c5 02 49 63 c5 49 8b 44 c4 10 48 85 c0 74 56 45 31 ff <39> 58 18 75 4e eb 1f 49 63 d7 4c 89 f7 48 89 45 c8 48 6b d2 28 RIP [] coretemp_cpu_callback+0x93/0x1ba [coretemp] RSP CR2: 000000000000013c Signed-off-by: Kirill A. Shutemov Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit a22a75f744a4bd1bfd489afd0fd0fa6f3226d328 Author: Dave Airlie Date: Wed May 2 20:26:24 2012 +0100 nouveau: initialise has_optimus variable. commit addde4ec31456c5f1e9b61aae3edcfeb0f338f87 upstream. We should initialise this to 0 really to avoid getting false positives. Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 3218e944179b9ec3bff649c78d54928f94c69cee Author: Guenter Roeck Date: Tue May 1 08:15:42 2012 -0700 hwmon: (coretemp) Increase CPU core limit commit bdc71c9a87b898e4c380c23b2e3e18071312ecde upstream. CPU core ID is used to index the core_data[] array. The core ID is, however, not sequential; 10-core CPUS can have a core ID as high as 25. Increase the limit to 32 to be able to deal with current CPUs. Signed-off-by: Guenter Roeck Acked-by: Jean Delvare Acked-by: Durgadoss R Signed-off-by: Ben Hutchings commit 32b216a576ef1bf96c1434578c4c978c2b863e92 Author: Linus Torvalds Date: Fri May 4 14:46:02 2012 -0700 Fix __read_seqcount_begin() to use ACCESS_ONCE for sequence value read commit 2f624278626677bfaf73fef97f86b37981621f5c upstream. We really need to use a ACCESS_ONCE() on the sequence value read in __read_seqcount_begin(), because otherwise the compiler might end up reloading the value in between the test and the return of it. As a result, it might end up returning an odd value (which means that a write is in progress). If the reader is then fast enough that that odd value is still the current one when the read_seqcount_retry() is done, we might end up with a "successful" read sequence, even despite the concurrent write being active. In practice this probably never really happens - there just isn't anything else going on around the read of the sequence count, and the common case is that we end up having a read barrier immediately afterwards. So the code sequence in which gcc might decide to reaload from memory is small, and there's no reason to believe it would ever actually do the reload. But if the compiler ever were to decide to do so, it would be incredibly annoying to debug. Let's just make sure. Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 5feaf04c7b68d401b17255958432f0d89dd9d7ad Author: Stefan Metzmacher Date: Fri May 4 00:19:28 2012 +0200 fs/cifs: fix parsing of dfs referrals commit d8f2799b105a24bb0bbd3380a0d56e6348484058 upstream. The problem was that the first referral was parsed more than once and so the caller tried the same referrals multiple times. The problem was introduced partly by commit 066ce6899484d9026acd6ba3a8dbbedb33d7ae1b, where 'ref += le16_to_cpu(ref->Size);' got lost, but that was also wrong... Signed-off-by: Stefan Metzmacher Tested-by: Björn Jacke Reviewed-by: Jeff Layton Signed-off-by: Steve French [bwh: Backport to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 103f468a50f7bd31eb6f47f2f3dc4a4009d9f470 Author: Matthew Garrett Date: Thu May 3 16:50:46 2012 -0400 efivars: Improve variable validation commit 54b3a4d311c98ad94b737802a8b5f2c8c6bfd627 upstream. Ben Hutchings pointed out that the validation in efivars was inadequate - most obviously, an entry with size 0 would server as a DoS against the kernel. Improve this based on his suggestions. Signed-off-by: Matthew Garrett Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 5e2d50da11f0e6ec3ce8fe658d7c83b0b4346c68 Author: Peter Zijlstra Date: Thu Mar 1 15:04:46 2012 +0100 sched: Fix nohz load accounting -- again! commit c308b56b5398779cd3da0f62ab26b0453494c3d4 upstream. Various people reported nohz load tracking still being wrecked, but Doug spotted the actual problem. We fold the nohz remainder in too soon, causing us to loose samples and under-account. So instead of playing catch-up up-front, always do a single load-fold with whatever state we encounter and only then fold the nohz remainder and play catch-up. Reported-by: Doug Smythies Reported-by: LesÅ=82aw Kope=C4=87 Reported-by: Aman Gupta Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/n/tip-4v31etnhgg9kwd6ocgx3rxl8@git.kernel.org Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: change filename] Signed-off-by: Ben Hutchings commit cab35eb95d74609cd26ad8a2084659ec4a65fe12 Author: Paulo Zanoni Date: Wed May 2 22:55:43 2012 -0300 drm/i915: enable dip before writing data on gen4 commit c1230df7e19e0f27655c0eb9d966c7e03be7cc50 upstream. While testing with the intel_infoframes tool on gen4, I see that when video DIP is disabled, what we write to the DATA memory is not exactly what we read back later. This regression has been introduce in commit 64a8fc0145a1d0fdc25fc9367c2e6c621955fb3b Author: Jesse Barnes Date: Thu Sep 22 11:16:00 2011 +0530 drm/i915: fix ILK+ infoframe support That commit was setting VIDEO_DIP_CTL to 0 when initializing, which caused the problem. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43947 Tested-by: Yang Guang Signed-off-by: Paulo Zanoni Reviewed-by: Eugeni Dodonov [danvet: Pimped commit message by using the usual commit citation layout.] Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit e0791b5ffb456aa7de29391297e5dc93c1d123ff Author: Bojan Smojver Date: Tue Apr 24 23:53:28 2012 +0200 PM / Hibernate: fix the number of pages used for hibernate/thaw buffering commit f8262d476823a7ea1eb497ff9676d1eab2393c75 upstream. Hibernation regression fix, since 3.2. Calculate the number of required free pages based on non-high memory pages only, because that is where the buffers will come from. Commit 081a9d043c983f161b78fdc4671324d1342b86bc introduced a new buffer page allocation logic during hibernation, in order to improve the performance. The amount of pages allocated was calculated based on total amount of pages available, although only non-high memory pages are usable for this purpose. This caused hibernation code to attempt to over allocate pages on platforms that have high memory, which led to hangs. Signed-off-by: Bojan Smojver Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit bb1e005ee88b73be502eb42ca6bdb4c7295b7b3c Author: Matthew Garrett Date: Mon Apr 30 16:11:30 2012 -0400 efi: Validate UEFI boot variables commit fec6c20b570bcf541e581fc97f2e0cbdb9725b98 upstream. A common flaw in UEFI systems is a refusal to POST triggered by a malformed boot variable. Once in this state, machines may only be restored by reflashing their firmware with an external hardware device. While this is obviously a firmware bug, the serious nature of the outcome suggests that operating systems should filter their variable writes in order to prevent a malicious user from rendering the machine unusable. Signed-off-by: Matthew Garrett Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 3a91135a4b1720f83810399e596937598b38b158 Author: Matthew Garrett Date: Mon Apr 30 16:11:29 2012 -0400 efi: Add new variable attributes commit 41b3254c93acc56adc3c4477fef7c9512d47659e upstream. More recent versions of the UEFI spec have added new attributes for variables. Add them. Signed-off-by: Matthew Garrett Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 6c25e70f9026d5aa39fb2cb18f66454fd077d1b2 Author: Dan Williams Date: Tue Mar 20 10:50:27 2012 -0700 libsas: fix false positive 'device attached' conditions commit 7d1d865181185bdf1316d236b1b4bd02c9020729 upstream. Normalize phy->attached_sas_addr to return a zero-address in the case when device-type == NO_DEVICE or the linkrate is invalid to handle expanders that put non-zero sas addresses in the discovery response: sas: ex 5001b4da000f903f phy02:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy01:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy03:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy00:U:0 attached: 0100000000000000 (no device) Reported-by: Andrzej Jakowski Signed-off-by: Dan Williams Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit aa60a4b796e450c561fb070cbd23c4650896cb67 Author: Thomas Jackson Date: Fri Feb 17 18:33:10 2012 -0800 libsas: fix sas_find_bcast_phy() in the presence of 'vacant' phys commit 1699490db339e2c6b3037ea8e7dcd6b2755b688e upstream. If an expander reports 'PHY VACANT' for a phy index prior to the one that generated a BCN libsas fails rediscovery. Since a vacant phy is defined as a valid phy index that will never have an attached device just continue the search. Signed-off-by: Thomas Jackson Signed-off-by: Dan Williams Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit 586e76ea0975340dd826e36522ac162e83d90962 Author: Will Deacon Date: Fri Apr 27 12:56:24 2012 +0100 ARM: 7406/1: hotplug: copy the affinity mask when forcefully migrating IRQs commit 5e7371ded05adfcfcee44a8bc070bfc37979b8f2 upstream. When a CPU is hotplugged off, we migrate any IRQs currently affine to it away and onto another online CPU by calling the irq_set_affinity function of the relevant interrupt controller chip. This function returns either IRQ_SET_MASK_OK or IRQ_SET_MASK_OK_NOCOPY, to indicate whether irq_data.affinity was updated. If we are forcefully migrating an interrupt (because the affinity mask no longer identifies any online CPUs) then we should update the IRQ affinity mask to reflect the new CPU set. Failure to do so can potentially leave /proc/irq/n/smp_affinity identifying only offline CPUs, which may confuse userspace IRQ balancing daemons. This patch updates migrate_one_irq to copy the affinity mask when the interrupt chip returns IRQ_SET_MASK_OK after forcefully changing the affinity of an interrupt. Reported-by: Leif Lindholm Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit fdd90d60811d751c71e8fd19235fabc9cd7d4307 Author: Will Deacon Date: Fri Apr 27 12:45:07 2012 +0100 ARM: 7403/1: tls: remove covert channel via TPIDRURW commit 6a1c53124aa161eb624ce7b1e40ade728186d34c upstream. TPIDRURW is a user read/write register forming part of the group of thread registers in more recent versions of the ARM architecture (~v6+). Currently, the kernel does not touch this register, which allows tasks to communicate covertly by reading and writing to the register without context-switching affecting its contents. This patch clears TPIDRURW when TPIDRURO is updated via the set_tls macro, which is called directly from __switch_to. Since the current behaviour makes the register useless to userspace as far as thread pointers are concerned, simply clearing the register (rather than saving and restoring it) will not cause any problems to userspace. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit 989046b49627c1beacad7517d044401f14bbd53c Author: Will Deacon Date: Fri Apr 20 17:22:11 2012 +0100 ARM: 7398/1: l2x0: only write to debug registers on PL310 commit ab4d536890853ab6675ede65db40e2c0980cb0ea upstream. PL310 errata #588369 and #727915 require writes to the debug registers of the cache controller to work around known problems. Writing these registers on L220 may cause deadlock, so ensure that we only perform this operation when we identify a PL310 at probe time. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit 721293c3ce382a69b89a743e25aaff6553ad2079 Author: Will Deacon Date: Fri Apr 20 17:21:08 2012 +0100 ARM: 7397/1: l2x0: only apply workaround for erratum #753970 on PL310 commit f154fe9b806574437b47f08e924ad10c0e240b23 upstream. The workaround for PL310 erratum #753970 can lead to deadlock on systems with an L220 cache controller. This patch makes the workaround effective only when the cache controller is identified as a PL310 at probe time. Signed-off-by: Will Deacon Signed-off-by: Russell King [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 28bd5ddf286b858b8148c3de5854cbc00e701229 Author: Will Deacon Date: Fri Apr 20 17:20:08 2012 +0100 ARM: 7396/1: errata: only handle ARM erratum #326103 on affected cores commit f0c4b8d653f5ee091fb8d4d02ed7eaad397491bb upstream. Erratum #326103 ("FSR write bit incorrect on a SWP to read-only memory") only affects the ARM 1136 core prior to r1p0. The workaround disassembles the faulting instruction to determine whether it was a read or write access on all v6 cores. An issue has been reported on the ARM 11MPCore whereby loading the faulting instruction may happen in parallel with that page being unmapped, resulting in a deadlock due to the lack of TLB broadcasting in hardware: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/091561.html This patch limits the workaround so that it is only used on affected cores, which are known to be UP only. Other v6 cores can rely on the FSR to indicate the access type correctly. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit fd81c41a855b671788991872ab0a0dcdcc6ee1fa Author: Linus Torvalds Date: Sun Apr 29 13:30:08 2012 -0700 autofs: make the autofsv5 packet file descriptor use a packetized pipe commit 64f371bc3107e69efce563a3d0f0e6880de0d537 upstream. The autofs packet size has had a very unfortunate size problem on x86: because the alignment of 'u64' differs in 32-bit and 64-bit modes, and because the packet data was not 8-byte aligned, the size of the autofsv5 packet structure differed between 32-bit and 64-bit modes despite looking otherwise identical (300 vs 304 bytes respectively). We first fixed that up by making the 64-bit compat mode know about this problem in commit a32744d4abae ("autofs: work around unhappy compat problem on x86-64"), and that made a 32-bit 'systemd' work happily on a 64-bit kernel because everything then worked the same way as on a 32-bit kernel. But it turned out that 'automount' had actually known and worked around this problem in user space, so fixing the kernel to do the proper 32-bit compatibility handling actually *broke* 32-bit automount on a 64-bit kernel, because it knew that the packet sizes were wrong and expected those incorrect sizes. As a result, we ended up reverting that compatibility mode fix, and thus breaking systemd again, in commit fcbf94b9dedd. With both automount and systemd doing a single read() system call, and verifying that they get *exactly* the size they expect but using different sizes, it seemed that fixing one of them inevitably seemed to break the other. At one point, a patch I seriously considered applying from Michael Tokarev did a "strcmp()" to see if it was automount that was doing the operation. Ugly, ugly. However, a prettier solution exists now thanks to the packetized pipe mode. By marking the communication pipe as being packetized (by simply setting the O_DIRECT flag), we can always just write the bigger packet size, and if user-space does a smaller read, it will just get that partial end result and the extra alignment padding will simply be thrown away. This makes both automount and systemd happy, since they now get the size they asked for, and the kernel side of autofs simply no longer needs to care - it could pad out the packet arbitrarily. Of course, if there is some *other* user of autofs (please, please, please tell me it ain't so - and we haven't heard of any) that tries to read the packets with multiple writes, that other user will now be broken - the whole point of the packetized mode is that one system call gets exactly one packet, and you cannot read a packet in pieces. Tested-by: Michael Tokarev Cc: Alan Cox Cc: David Miller Cc: Ian Kent Cc: Thomas Meyer Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 39bcf98adc9432136e3b6a54881dcf703b7fcb63 Author: Linus Torvalds Date: Sun Apr 29 13:12:42 2012 -0700 pipes: add a "packetized pipe" mode for writing commit 9883035ae7edef3ec62ad215611cb8e17d6a1a5d upstream. The actual internal pipe implementation is already really about individual packets (called "pipe buffers"), and this simply exposes that as a special packetized mode. When we are in the packetized mode (marked by O_DIRECT as suggested by Alan Cox), a write() on a pipe will not merge the new data with previous writes, so each write will get a pipe buffer of its own. The pipe buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn will tell the reader side to break the read at that boundary (and throw away any partial packet contents that do not fit in the read buffer). End result: as long as you do writes less than PIPE_BUF in size (so that the pipe doesn't have to split them up), you can now treat the pipe as a packet interface, where each read() system call will read one packet at a time. You can just use a sufficiently big read buffer (PIPE_BUF is sufficient, since bigger than that doesn't guarantee atomicity anyway), and the return value of the read() will naturally give you the size of the packet. NOTE! We do not support zero-sized packets, and zero-sized reads and writes to a pipe continue to be no-ops. Also note that big packets will currently be split at write time, but that the size at which that happens is not really specified (except that it's bigger than PIPE_BUF). Currently that limit is the system page size, but we might want to explicitly support bigger packets some day. The main user for this is going to be the autofs packet interface, allowing us to stop having to care so deeply about exact packet sizes (which have had bugs with 32/64-bit compatibility modes). But user space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will fail with an EINVAL on kernels that do not support this interface. Tested-by: Michael Tokarev Cc: Alan Cox Cc: David Miller Cc: Ian Kent Cc: Thomas Meyer Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit cbc0551878f39fce33be5dd54ec6773664498386 Author: Laurent Pinchart Date: Tue Apr 24 11:29:42 2012 +0200 usb gadget: uvc: uvc_request_data::length field must be signed commit 6f6543f53f9ce136e01d7114bf6f0818ca54fb41 upstream. The field is used to pass the UVC request data length, but can also be used to signal an error when setting it to a negative value. Switch from unsigned int to __s32. Reported-by: Fernandez Gonzalo Signed-off-by: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 30b770c334f69cf5bc8ce4e277084b6205ce34ef Author: Felipe Balbi Date: Wed Apr 18 13:59:30 2012 +0300 usb: gadget: dummy: do not call pullup() on udc_stop() commit 15b120d67019d691e4389372967332d74a80522a upstream. pullup() is already called properly by udc-core.c and there's no need to call it from udc_stop(), in fact that will cause issues. Reviewed-by: Alexander Shishkin Acked-by: Alan Stern Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit 4c3fbeafa241fbead0d8724c3d5ea9da96151a74 Author: Alan Stern Date: Wed Apr 11 16:09:10 2012 -0400 USB: gadget: storage gadgets send wrong error code for unknown commands commit c85dcdac5852295cf6822f5c4331a6ddab72581f upstream. This patch (as1539) fixes a minor bug in the mass-storage gadget drivers. When an unknown command is received, the error code sent back is "Invalid Field in CDB" rather than "Invalid Command". This is because the bitmask of CDB bytes allowed to be nonzero is incorrect. When handling an unknown command, we don't care which command bytes are nonzero. All the bits in the mask should be set, not just eight of them. Signed-off-by: Alan Stern CC: Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit f845dfabaf943e9d1bd97c1c023ee5c58ba04352 Author: Alan Stern Date: Tue Apr 24 14:07:22 2012 -0400 USB: EHCI: fix crash during suspend on ASUS computers commit 151b61284776be2d6f02d48c23c3625678960b97 upstream. This patch (as1545) fixes a problem affecting several ASUS computers: The machine crashes or corrupts memory when going into suspend if the ehci-hcd driver is bound to any controllers. Users have been forced to unbind or unload ehci-hcd before putting their systems to sleep. After extensive testing, it was determined that the machines don't like going into suspend when any EHCI controllers are in the PCI D3 power state. Presumably this is a firmware bug, but there's nothing we can do about it except to avoid putting the controllers in D3 during system sleep. The patch adds a new flag to indicate whether the problem is present, and avoids changing the controller's power state if the flag is set. Runtime suspend is unaffected; this matters only for system suspend. However as a side effect, the controller will not respond to remote wakeup requests while the system is asleep. Hence USB wakeup is not functional -- but of course, this is already true in the current state of affairs. This fixes Bugzilla #42728. Signed-off-by: Alan Stern Tested-by: Steven Rostedt Tested-by: Andrey Rahmatullin Tested-by: Oleksij Rempel (fishor) Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 670515c56290b7b7435f066e9bc0999fa1fc29b7 Author: Oliver Neukum Date: Thu Apr 26 21:59:10 2012 +0200 USB: cdc-wdm: fix race leading leading to memory corruption commit 5c22837adca7c30b66121cf18ad3e160134268d4 upstream. This patch fixes a race whereby a pointer to a buffer would be overwritten while the buffer was in use leading to a double free and a memory leak. This causes crashes. This bug was introduced in 2.6.34 Signed-off-by: Oliver Neukum Tested-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 54f74773233a4ac43bd5149aa2cb1734da37506b Author: David Henningsson Date: Fri Apr 20 10:01:46 2012 +0200 ALSA: HDA: Add external mic quirk for Asus Zenbook UX31E commit 5ac57550f279c3d991ef0b398681bcaca18169f7 upstream. According to the reporter, external mic starts to work if the laptop-dmic model is used. According to BIOS pin config, all pins are consistent with the alc269vb_laptop_dmic fixup, except for the external mic, which is not present. BugLink: https://bugs.launchpad.net/bugs/950490 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 84e1fbf5681e877ff227432918ffd4b5c6f6f228 Author: Johannes Berg Date: Mon Apr 2 10:51:55 2012 +0200 nl80211: ensure interface is up in various APIs commit 2b5f8b0b44e17e625cfba1e7b88db44f4dcc0441 upstream. [backported by Ben Greear] The nl80211 handling code should ensure as much as it can that the interface is in a valid state, it can certainly ensure the interface is running. Not doing so can cause calls through mac80211 into the driver that result in warnings and unspecified behaviour in the driver. Reported-by: Ben Greear Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Ben Greear Signed-off-by: Ben Hutchings commit c9b310ee2b2a50ffaa6ea0ca9226c64a12ed0c54 Author: Xi Wang Date: Mon Apr 23 04:06:42 2012 -0400 drm/i915: fix integer overflow in i915_gem_do_execbuffer() commit 44afb3a04391a74309d16180d1e4f8386fdfa745 upstream. On 32-bit systems, a large args->num_cliprects from userspace via ioctl may overflow the allocation size, leading to out-of-bounds access. This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid allocation for execbuffer object list"). Signed-off-by: Xi Wang Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit a9206caacef21a1eeee7083d8fb188cfeb15fd52 Author: Xi Wang Date: Mon Apr 23 04:06:41 2012 -0400 drm/i915: fix integer overflow in i915_gem_execbuffer2() commit ed8cd3b2cd61004cab85380c52b1817aca1ca49b upstream. On 32-bit systems, a large args->buffer_count from userspace via ioctl may overflow the allocation size, leading to out-of-bounds access. This vulnerability was introduced in commit 8408c282 ("drm/i915: First try a normal large kmalloc for the temporary exec buffers"). Signed-off-by: Xi Wang Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 95053b00dba206bb36217801c60bbb612d8160e0 Author: Kenneth Graunke Date: Fri Apr 27 12:44:41 2012 -0700 drm/i915: Set the Stencil Cache eviction policy to non-LRA mode. commit 3a69ddd6f872180b6f61fda87152b37202118fbc upstream. Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when using separate stencil buffers. Without it, the GPU tries to use the LRA eviction policy, which isn't supported. This was supposed to be off by default, but seems to be on for many machines. This cannot be done in gen6_init_clock_gating with most of the other workaround bits; the render ring needs to exist. Otherwise, the register write gets dropped on the floor (one printk will show it changed, but a second printk immediately following shows the value reverts to the old one). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535 Cc: Rob Castle Cc: Eric Appleman Cc: aaron667@gmx.net Cc: Keith Packard Signed-off-by: Kenneth Graunke Reviewed-by: Daniel Vetter Acked-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 487020e781b754a33510169f05d08f07ca83979f Author: Ben Widawsky Date: Mon Dec 12 19:21:58 2011 -0800 drm/i915: Force sync command ordering (Gen6+) commit 84f9f938be4156e4baea466688bd6abae1c9e6ba upstream. The docs say this is required for Gen7, and since the bit was added for Gen6, we are also setting it there pit pf paranoia. Particularly as Chris points out, if PIPE_CONTROL counts as a 3d state packet. This was found through doc inspection by Ken and applies to Gen6+; Reported-by: Kenneth Graunke Signed-off-by: Ben Widawsky Reviewed-by: Chris Wilson Reviewed-by: Daniel Vetter Reviewed-by: Eric Anholt Signed-off-by: Keith Packard Signed-off-by: Ben Hutchings commit 4829cd25743cd337e484b8cd69e3f434c577f0cb Author: Ben Widawsky Date: Mon Dec 12 19:21:57 2011 -0800 drm/i915: relative_constants_mode race fix commit e2971bdab2b761683353da383c0fd5ac704d1cca upstream. dev_priv keeps track of the current addressing mode that gets set at execbuffer time. Unfortunately the existing code was doing this before acquiring struct_mutex which leaves a race with another thread also doing an execbuffer. If that wasn't bad enough, relocate_slow drops struct_mutex which opens a much more likely error where another thread comes in and modifies the state while relocate_slow is being slow. The solution here is to just defer setting this state until we absolutely need it, and we know we'll have struct_mutex for the remainder of our code path. v2: Keith noticed a bug in the original patch. Signed-off-by: Ben Widawsky Reviewed-by: Daniel Vetter Signed-off-by: Keith Packard Signed-off-by: Ben Hutchings commit 4174dcc99576772d477a0686f84658e38c0c69d3 Author: Daniel Vetter Date: Sun Apr 1 19:16:18 2012 +0200 drm/i915: handle input/output sdvo timings separately in mode_set commit 6651819b4b4fc3caa6964c5d825eb4bb996f3905 upstream. We seem to have a decent confusion between the output timings and the input timings of the sdvo encoder. If I understand the code correctly, we use the original mode unchanged for the output timings, safe for the lvds case. And we should use the adjusted mode for input timings. Clarify the situation by adding an explicit output_dtd to the sdvo mode_set function and streamline the code-flow by moving the input and output mode setting in the sdvo encode together. Furthermore testing showed that the sdvo input timing needs the unadjusted dotclock, the sdvo chip will automatically compute the required pixel multiplier to get a dotclock above 100 MHz. Fix this up when converting a drm mode to an sdvo dtd. This regression was introduced in commit c74696b9c890074c1e1ee3d7496fc71eb3680ced Author: Pavel Roskin Date: Thu Sep 2 14:46:34 2010 -0400 i915: revert some checks added by commit 32aad86f particularly the following hunk: > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c > b/drivers/gpu/drm/i915/intel_sdvo.c > index 093e914..62d22ae 100644 > --- a/drivers/gpu/drm/i915/intel_sdvo.c > +++ b/drivers/gpu/drm/i915/intel_sdvo.c > @@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder, > > /* We have tried to get input timing in mode_fixup, and filled into > adjusted_mode */ > - if (intel_sdvo->is_tv || intel_sdvo->is_lvds) { > - intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); > + intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); > + if (intel_sdvo->is_tv || intel_sdvo->is_lvds) > input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags; > - } else > - intel_sdvo_get_dtd_from_mode(&input_dtd, mode); > > /* If it's a TV, we already set the output timing in mode_fixup. > * Otherwise, the output timing is equal to the input timing. Due to questions raised in review, below a more elaborate analysis of the bug at hand: Sdvo seems to have two timings, one is the output timing which will be sent over whatever is connected on the other side of the sdvo chip (panel, hdmi screen, tv), the other is the input timing which will be generated by the gmch pipe. It looks like sdvo is expected to scale between the two. To make things slightly more complicated, we have a bunch of special cases: - For lvds panel we always use a fixed output timing, namely intel_sdvo->sdvo_lvds_fixed_mode, hence that special case. - Sdvo has an interface to generate a preferred input timing for a given output timing. This is the confusing thing that I've tried to clear up with the follow-on patches. - A special requirement is that the input pixel clock needs to be between 100MHz and 200MHz (likely to keep it within the electromechanical design range of PCIe), 270MHz on later gen4+. Lower pixel clocks are doubled/quadrupled. The thing this patch tries to fix is that the pipe needs to be explicitly instructed to double/quadruple the pixels and needs the correspondingly higher pixel clock, whereas the sdvo adaptor seems to do that itself and needs the unadjusted pixel clock. For the sdvo encode side we already set the pixel mutliplier with a different command (0x21). This patch tries to fix this mess by: - Keeping the output mode timing in the unadjusted plain mode, safe for the lvds case. - Storing the input timing in the adjusted_mode with the adjusted pixel clock. This way we don't need to frob around with the core crtc mode set code. - Fixing up the pixelclock when constructing the sdvo dtd timing struct. This is why the first hunk of the patch is an integral part of the series. - Dropping the is_tv special case because input_dtd is equivalent to adjusted_mode after these changes. Follow-up patches clear this up further (by simply ripping out intel_sdvo->input_dtd because it's not needed). v2: Extend commit message with an in-depth bug analysis. Reported-and-Tested-by: Bernard Blackham Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157 Reviewed-by: Jesse Barnes Signed-off-by: Daniel Vetter [bwh: Indented the hunk quoted above so quilt doesn't try to apply it] Signed-off-by: Ben Hutchings commit 0479c2ecc3d0958900a13a02017956270fcbacb1 Author: Alex Deucher Date: Fri Apr 27 17:18:59 2012 -0400 drm/radeon/kms: need to set up ss on DP bridges as well commit 700698e7c303f5095107c62a81872c2c3dad1702 upstream. Makes Nutmeg DP to VGA bridges work for me. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=42490 Noticed by Jerome Glisse (after weeks of debugging). Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit a12b704ea7b8cf2620915a6202e68953b6c61bd7 Author: Martin Nyhus Date: Thu Mar 15 18:25:48 2012 +0100 dell-laptop: Terminate quirks list properly commit d62d421b071b08249361044d8e56c8b5c3ed6aa7 upstream. Add missing DMI_NONE entry to end of the quirks list so dmi_check_system() won't read past the end of the list. Signed-off-by: Martin Nyhus Signed-off-by: Matthew Garrett Signed-off-by: Ben Hutchings commit a3d96e2fff39b1b16f4440cfa6796d12e9d20dcf Author: Guenter Roeck Date: Wed Apr 25 13:44:20 2012 -0700 hwmon: (fam15h_power) Fix pci_device_id array commit c3e40a9972428d6e2d8e287ed0233a57a218c30f upstream. pci_match_id() takes an *array* of IDs which must be properly zero- terminated. Reported-by: Ben Hutchings Signed-off-by: Guenter Roeck Acked-by: Jean Delvare Signed-off-by: Ben Hutchings commit 8198e9bfd86f983380946965d825972fe432cc0c Author: Andre Przywara Date: Mon Apr 9 18:16:34 2012 -0400 hwmon: fam15h_power: fix bogus values with current BIOSes commit 00250ec90963b7ef6678438888f3244985ecde14 upstream. Newer BKDG[1] versions recommend a different initialization value for the running average range register in the northbridge. This improves the power reading by avoiding counter saturations resulting in bogus values for anything below about 80% of TDP power consumption. Updated BIOSes will have this new value set up from the beginning, but meanwhile we correct this value ourselves. This needs to be done on all northbridges, even on those where the driver itself does not register at. This fixes the driver on all current machines to provide proper values for idle load. [1] http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf Chapter 3.8: D18F5xE0 Processor TDP Running Average (p. 452) Signed-off-by: Andre Przywara Acked-by: Jean Delvare [guenter.roeck@ericsson.com: Removed unnecessary return statement] Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit cce53871300df0290a1b4d1708f385c323d02c77 Author: Steven Rostedt Date: Thu Apr 19 10:31:47 2012 -0400 tracing: Fix stacktrace of latency tracers (irqsoff and friends) commit db4c75cbebd7e5910cd3bcb6790272fcc3042857 upstream. While debugging a latency with someone on IRC (mirage335) on #linux-rt (OFTC), we discovered that the stacktrace output of the latency tracers (preemptirqsoff) was empty. This bug was caused by the creation of the dynamic length stack trace again (like commit 12b5da3 "tracing: Fix ent_size in trace output" was). This bug is caused by the latency tracers requiring the next event to determine the time between the current event and the next. But by grabbing the next event, the iter->ent_size is set to the next event instead of the current one. As the stacktrace event is the last event, this makes the ent_size zero and causes nothing to be printed for the stack trace. The dynamic stacktrace uses the ent_size to determine how much of the stack can be printed. The ent_size of zero means no stack. The simple fix is to save the iter->ent_size before finding the next event. Note, mirage335 asked to remain anonymous from LKML and git, so I will not add the Reported-by and Tested-by tags, even though he did report the issue and tested the fix. Signed-off-by: Steven Rostedt Signed-off-by: Ben Hutchings commit 4e577871ae58c6f4d3b08d31883f876eed5d0fa3 Author: he, bo Date: Wed Apr 25 19:59:21 2012 +0800 sched: Fix OOPS when build_sched_domains() percpu allocation fails commit fb2cf2c660971bea0ad86a9a5c19ad39eab61344 upstream. Under extreme memory used up situations, percpu allocation might fail. We hit it when system goes to suspend-to-ram, causing a kworker panic: EIP: [] build_sched_domains+0x23a/0xad0 Kernel panic - not syncing: Fatal exception Pid: 3026, comm: kworker/u:3 3.0.8-137473-gf42fbef #1 Call Trace: [] panic+0x66/0x16c [...] [] partition_sched_domains+0x287/0x4b0 [] cpuset_update_active_cpus+0x1fe/0x210 [] cpuset_cpu_inactive+0x1d/0x30 [...] With this fix applied build_sched_domains() will return -ENOMEM and the suspend attempt fails. Signed-off-by: he, bo Reviewed-by: Zhang, Yanmin Reviewed-by: Srivatsa S. Bhat Signed-off-by: Peter Zijlstra Cc: Linus Torvalds Cc: Andrew Morton Link: http://lkml.kernel.org/r/1335355161.5892.17.camel@hebo [ So, we fail to deallocate a CPU because we cannot allocate RAM :-/ I don't like that kind of sad behavior but nevertheless it should not crash under high memory load. ] Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: change filename] Signed-off-by: Ben Hutchings commit 39fd81649ec76c39861105e9713adedba6e5432b Author: Nicolas Ferre Date: Mon Apr 16 14:46:30 2012 +0200 dmaengine: at_hdmac: remove clear-on-read in atc_dostart() commit ed8b0d67f33518a16c6b2450fe5ebebf180c2d04 upstream. This loop on EBCISR register was designed to clear IRQ sources before enabling a DMA channel. This register is clear-on-read so a race condition can appear if another channel is already active and has just finished its transfer. Removing this read on EBCISR is fixing the issue as there is no case where an IRQ could be pending: we already make sure that this register is drained at probe() time and during resume. Signed-off-by: Nicolas Ferre Signed-off-by: Vinod Koul Signed-off-by: Ben Hutchings commit 75da54d1e53bc81447e82c5f5d0f5112d7a3aed5 Author: Mark Brown Date: Thu Apr 12 19:47:11 2012 +0100 ASoC: wm8994: Improve sequencing of AIF channel enables commit 1a38336b8611a04f0a624330c1f815421f4bf5f4 upstream. This ensures a clean startup of the channels, without this change some use cases could result in issues in a small proportion of cases. Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit bbbf5d671870294c29bf32e4cb3ca3d9be455952 Author: Mark Brown Date: Thu Apr 12 17:29:36 2012 +0100 ASoC: dapm: Ensure power gets managed for line widgets commit 7e1f7c8a6e517900cd84da1b8ae020f08f286c3b upstream. Line widgets had not been included in either the power up or power down sequences so if a widget had an event associated with it that event would never be run. Fix this minimally by adding them to the sequences, we should probably be doing away with the specific widget types as they all have the same priority anyway. Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit 66cd7284eee5935fa9878573ebf9b57f8db4ce2d Author: Konrad Rzeszutek Wilk Date: Thu Apr 26 13:50:03 2012 -0400 xen/smp: Fix crash when booting with ACPI hotplug CPUs. commit cf405ae612b0f7e2358db7ff594c0e94846137aa upstream. When we boot on a machine that can hotplug CPUs and we are using 'dom0_max_vcpus=X' on the Xen hypervisor line to clip the amount of CPUs available to the initial domain, we get this: (XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all .. snip.. DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011 .. snip. SMP: Allowing 64 CPUs, 32 hotplug CPUs installing Xen timer for CPU 7 cpu 7 spinlock event irq 361 NMI watchdog: disabled (cpu7): hardware events not enabled Brought up 8 CPUs .. snip.. [acpi processor finds the CPUs are not initialized and starts calling arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online] CPU 8 got hotplugged CPU 9 got hotplugged CPU 10 got hotplugged .. snip.. initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs calling erst_init+0x0/0x2bb @ 1 [and the scheduler sticks newly started tasks on the new CPUs, but said CPUs cannot be initialized b/c the hypervisor has limited the amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag. The spinlock tries to kick the other CPU, but the structure for that is not initialized and we crash.] BUG: unable to handle kernel paging request at fffffffffffffed8 IP: [] xen_spin_lock+0x29/0x60 PGD 180d067 PUD 180e067 PMD 0 Oops: 0002 [#1] SMP CPU 7 Modules linked in: Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP RIP: e030:[] [] xen_spin_lock+0x29/0x60 RSP: e02b:ffff8801fb9b3a70 EFLAGS: 00010282 With this patch, we cap the amount of vCPUS that the initial domain can run, to exactly what dom0_max_vcpus=X has specified. In the future, if there is a hypercall that will allow a running domain to expand past its initial set of vCPUS, this patch should be re-evaluated. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Ben Hutchings commit 585bfaac76e8392e83e82b7457de2f326f29fded Author: David Vrabel Date: Thu Apr 26 19:44:06 2012 +0100 xen: correctly check for pending events when restoring irq flags commit 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac upstream. In xen_restore_fl_direct(), xen_force_evtchn_callback() was being called even if no events were pending. This resulted in (depending on workload) about a 100 times as many xen_version hypercalls as necessary. Fix this by correcting the sense of the conditional jump. This seems to give a significant performance benefit for some workloads. There is some subtle tricksy "..since the check here is trying to check both pending and masked in a single cmpw, but I think this is correct. It will call check_events now only when the combined mask+pending word is 0x0001 (aka unmasked, pending)." (Ian) Acked-by: Ian Campbell Signed-off-by: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Ben Hutchings commit 72f1409d18618284d29f22823270ad8c370911a0 Author: Linus Torvalds Date: Sat Apr 28 08:29:56 2012 -0700 Revert "autofs: work around unhappy compat problem on x86-64" commit fcbf94b9dedd2ce08e798a99aafc94fec8668161 upstream. This reverts commit a32744d4abae24572eff7269bc17895c41bd0085. While that commit was technically the right thing to do, and made the x86-64 compat mode work identically to native 32-bit mode (and thus fixing the problem with a 32-bit systemd install on a 64-bit kernel), it turns out that the automount binaries had workarounds for this compat problem. Now, the workarounds are disgusting: doing an "uname()" to find out the architecture of the kernel, and then comparing it for the 64-bit cases and fixing up the size of the read() in automount for those. And they were confused: it's not actually a generic 64-bit issue at all, it's very much tied to just x86-64, which has different alignment for an 'u64' in 64-bit mode than in 32-bit mode. But the end result is that fixing the compat layer actually breaks the case of a 32-bit automount on a x86-64 kernel. There are various approaches to fix this (including just doing a "strcmp()" on current->comm and comparing it to "automount"), but I think that I will do the one that teaches pipes about a special "packet mode", which will allow user space to not have to care too deeply about the padding at the end of the autofs packet. That change will make the compat workaround unnecessary, so let's revert it first, and get automount working again in compat mode. The packetized pipes will then fix autofs for systemd. Reported-and-requested-by: Michael Tokarev Cc: Ian Kent Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 5b13871a6f0c65eef175caad5158aeb75d079e14 Author: Bryan O'Donoghue Date: Wed Apr 18 17:37:39 2012 +0100 x86, apic: APIC code touches invalid MSR on P5 class machines commit cbf2829b61c136edcba302a5e1b6b40e97d32c00 upstream. Current APIC code assumes MSR_IA32_APICBASE is present for all systems. Pentium Classic P5 and friends didn't have this MSR. MSR_IA32_APICBASE was introduced as an architectural MSR by Intel @ P6. Code paths that can touch this MSR invalidly are when vendor == Intel && cpu-family == 5 and APIC bit is set in CPUID - or when you simply pass lapic on the kernel command line, on a P5. The below patch stops Linux incorrectly interfering with the MSR_IA32_APICBASE for P5 class machines. Other code paths exist that touch the MSR - however those paths are not currently reachable for a conformant P5. Signed-off-by: Bryan O'Donoghue Link: http://lkml.kernel.org/r/4F8EEDD3.1080404@linux.intel.com Signed-off-by: H. Peter Anvin Signed-off-by: Ben Hutchings commit 31114c4a00db7d7fc730648906bab2a343e22150 Author: Andreas Herrmann Date: Thu Apr 12 16:48:01 2012 +0200 x86, microcode: Fix sysfs warning during module unload on unsupported CPUs commit a956bd6f8583326b18348ab1452b4686778f785d upstream. Loading the microcode driver on an unsupported CPU and subsequently unloading the driver causes WARNING: at fs/sysfs/group.c:138 mc_device_remove+0x5f/0x70 [microcode]() Hardware name: 01972NG sysfs group ffffffffa00013d0 not found for kobject 'cpu0' Modules linked in: snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel btusb snd_hda_codec bluetooth thinkpad_acpi rfkill microcode(-) [last unloaded: cfg80211] Pid: 4560, comm: modprobe Not tainted 3.4.0-rc2-00002-g258f742 #5 Call Trace: [] ? warn_slowpath_common+0x7b/0xc0 [] ? warn_slowpath_fmt+0x45/0x50 [] ? sysfs_remove_group+0x34/0x120 [] ? mc_device_remove+0x5f/0x70 [microcode] [] ? subsys_interface_unregister+0x69/0xa0 [] ? mutex_lock+0x16/0x40 [] ? microcode_exit+0x50/0x92 [microcode] [] ? sys_delete_module+0x16d/0x260 [] ? wait_iff_congested+0x45/0x110 [] ? page_fault+0x1f/0x30 [] ? system_call_fastpath+0x16/0x1b on recent kernels. This is due to commit 8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck' sysdev_class to a regular subsystem") which renders commit 6c53cbfced04 ("x86, microcode: Correct sysdev_add error path") useless. See http://marc.info/?l=linux-kernel&m=133416246406478 Avoid above warning by restoring the old driver behaviour before 6c53cbfced04 ("x86, microcode: Correct sysdev_add error path"). Cc: Tigran Aivazian Signed-off-by: Andreas Herrmann Acked-by: Greg Kroah-Hartman Link: http://lkml.kernel.org/r/20120411163849.GE4794@alberich.amd.com Signed-off-by: Borislav Petkov [bwh: Backported to 3.2: deleted line uses sys_dev, not dev] Signed-off-by: Ben Hutchings commit 749ff0d78dd4a808d6b27d459025c0f3a9ac4092 Author: Fred Isaman Date: Fri Apr 20 14:47:35 2012 -0400 NFS: put open context on error in nfs_flush_multi commit 8ccd271f7a3a846ce6f85ead0760d9d12994a611 upstream. Signed-off-by: Fred Isaman Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings commit 54b7ca35018246febfb9825204749b923f5cce19 Author: Fred Isaman Date: Fri Apr 20 14:47:34 2012 -0400 NFS: put open context on error in nfs_pagein_multi commit 73fb7bc7c57d971b11f2e00536ac2d3e316e0609 upstream. Signed-off-by: Fred Isaman Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings commit 6262ff01162e8582122f9792b6d9d55ec7425da3 Author: Trond Myklebust Date: Wed Apr 18 12:48:35 2012 -0400 NFSv4: Ensure that we check lock exclusive/shared type against open modes commit 55725513b5ef9d462aa3e18527658a0362aaae83 upstream. Since we may be simulating flock() locks using NFS byte range locks, we can't rely on the VFS having checked the file open mode for us. Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings commit 91dd866b788cfcbe9642adb201f281b386084c81 Author: Trond Myklebust Date: Wed Apr 18 12:20:10 2012 -0400 NFSv4: Ensure that the LOCK code sets exception->inode commit 05ffe24f5290dc095f98fbaf84afe51ef404ccc5 upstream. All callers of nfs4_handle_exception() that need to handle NFS4ERR_OPENMODE correctly should set exception->inode Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings commit bcd008fcd3c3d6e50ffc4eb5cf6b7f25f3d1d1dd Author: Jan Kara Date: Sat Sep 3 01:09:43 2011 +0200 nfs: Enclose hostname in brackets when needed in nfs_do_root_mount commit 98a2139f4f4d7b5fcc3a54c7fddbe88612abed20 upstream. When hostname contains colon (e.g. when it is an IPv6 address) it needs to be enclosed in brackets to make parsing of NFS device string possible. Fix nfs_do_root_mount() to enclose hostname properly when needed. NFS code actually does not need this as it does not parse the string passed by nfs_do_root_mount() but the device string is exposed to userspace in /proc/mounts. CC: Josh Boyer CC: Trond Myklebust Signed-off-by: Jan Kara Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings commit 0d8421fee40cb7a579e3793957b6f74b259fb1b9 Author: Neal Cardwell Date: Sun Apr 22 09:45:47 2012 +0000 tcp: fix TCP_MAXSEG for established IPv6 passive sockets [ Upstream commit d135c522f1234f62e81be29cebdf59e9955139ad ] Commit f5fff5d forgot to fix TCP_MAXSEG behavior IPv6 sockets, so IPv6 TCP server sockets that used TCP_MAXSEG would find that the advmss of child sockets would be incorrect. This commit mirrors the advmss logic from tcp_v4_syn_recv_sock in tcp_v6_syn_recv_sock. Eventually this logic should probably be shared between IPv4 and IPv6, but this at least fixes this issue. Signed-off-by: Neal Cardwell Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 8629ca8e378bf28312de1674d3a610b75e35fb18 Author: Eric W. Biederman Date: Wed Apr 18 16:11:23 2012 +0000 net ax25: Reorder ax25_exit to remove races. [ Upstream commit 3adadc08cc1e2cbcc15a640d639297ef5fcb17f5 ] While reviewing the sysctl code in ax25 I spotted races in ax25_exit where it is possible to receive notifications and packets after already freeing up some of the data structures needed to process those notifications and updates. Call unregister_netdevice_notifier early so that the rest of the cleanup code does not need to deal with network devices. This takes advantage of my recent enhancement to unregister_netdevice_notifier to send unregister notifications of all network devices that are current registered. Move the unregistration for packet types, socket types and protocol types before we cleanup any of the ax25 data structures to remove the possibilities of other races. Signed-off-by: Eric W. Biederman Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 427b96e9f08f7b44d83ef695930813f3fa8dfca3 Author: Dan Carpenter Date: Thu Apr 19 10:00:19 2012 +0300 ksz884x: don't copy too much in netdev_set_mac_address() [ Upstream commit 716af4abd6e6370226f567af50bfaca274515980 ] MAX_ADDR_LEN is 32. ETH_ALEN is 6. mac->sa_data is a 14 byte array, so the memcpy() is doing a read past the end of the array. I asked about this on netdev and Ben Hutchings told me it's supposed to be copying ETH_ALEN bytes (thanks Ben). Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 8c78926f1ce54c0766700efb5a4fcd2ee7c0edff Author: Julian Anastasov Date: Mon Apr 16 04:43:15 2012 +0000 netns: do not leak net_generic data on failed init [ Upstream commit b922934d017f1cc831b017913ed7d1a56c558b43 ] ops_init should free the net_generic data on init failure and __register_pernet_operations should not call ops_free when NET_NS is not enabled. Signed-off-by: Julian Anastasov Reviewed-by: "Eric W. Biederman" Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit f8f811922bb85977a1c30f4788cca14b5741f9b9 Author: Eric Dumazet Date: Mon Apr 16 23:28:07 2012 +0000 tcp: fix tcp_grow_window() for large incoming frames [ Upstream commit 4d846f02392a710f9604892ac3329e628e60a230 ] tcp_grow_window() has to grow rcv_ssthresh up to window_clamp, allowing sender to increase its window. tcp_grow_window() still assumes a tcp frame is under MSS, but its no longer true with LRO/GRO. This patch fixes one of the performance issue we noticed with GRO on. Signed-off-by: Eric Dumazet Cc: Neal Cardwell Cc: Tom Herbert Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 829a94ac60173dca2a30b65ea43c5c01150bd233 Author: Hiroaki SHIMODA Date: Sun Apr 15 13:26:01 2012 +0000 dummy: Add ndo_uninit(). commit 890fdf2a0cb88202d1427589db2cf29c1bdd3c1d upstream. In register_netdevice(), when ndo_init() is successful and later some error occurred, ndo_uninit() will be called. So dummy deivce is desirable to implement ndo_uninit() method to free percpu stats for this case. And, ndo_uninit() is also called along with dev->destructor() when device is unregistered, so in order to prevent dev->dstats from being freed twice, dev->destructor is modified to free_netdev(). Signed-off-by: Hiroaki SHIMODA Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 888580ee7e7377ff8feb098a1f1150946abc105b Author: Stephane Fillod Date: Sun Apr 15 11:38:29 2012 +0000 net: usb: smsc75xx: fix mtu [ Upstream commit a99ff7d0123b19ecad3b589480b6542716ab6b52 ] Make smsc75xx recalculate the hard_mtu after adjusting the hard_header_len. Without this, usbnet adjusts the MTU down to 1492 bytes, and the host is unable to receive standard 1500-byte frames from the device. Inspired by same fix on cdc_eem 78fb72f7936c01d5b426c03a691eca082b03f2b9. Tested on ARM/Omap3 with EVB-LAN7500-LC. Signed-off-by: Stephane Fillod Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 815feaa2e5733a772b8df9b3010008f7fb332341 Author: David Ward Date: Sun Apr 15 12:31:45 2012 +0000 net_sched: gred: Fix oops in gred_dump() in WRED mode [ Upstream commit 244b65dbfede788f2fa3fe2463c44d0809e97c6b ] A parameter set exists for WRED mode, called wred_set, to hold the same values for qavg and qidlestart across all VQs. The WRED mode values had been previously held in the VQ for the default DP. After these values were moved to wred_set, the VQ for the default DP was no longer created automatically (so that it could be omitted on purpose, to have packets in the default DP enqueued directly to the device without using RED). However, gred_dump() was overlooked during that change; in WRED mode it still reads qavg/qidlestart from the VQ for the default DP, which might not even exist. As a result, this command sequence will cause an oops: tc qdisc add dev $DEV handle $HANDLE parent $PARENT gred setup \ DPs 3 default 2 grio tc qdisc change dev $DEV handle $HANDLE gred DP 0 prio 8 $RED_OPTIONS tc qdisc change dev $DEV handle $HANDLE gred DP 1 prio 8 $RED_OPTIONS This fixes gred_dump() in WRED mode to use the values held in wred_set. Signed-off-by: David Ward Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 464f9a7c469124bb0f29fdd2d15aad8af16522ef Author: Davide Ciminaghi Date: Fri Apr 13 04:48:25 2012 +0000 net/ethernet: ks8851_mll fix rx frame buffer overflow [ Upstream commit 8a9a0ea6032186e3030419262678d652b88bf6a8 ] At the beginning of ks_rcv(), a for loop retrieves the header information relevant to all the frames stored in the mac's internal buffers. The number of pending frames is stored as an 8 bits field in KS_RXFCTR. If interrupts are disabled long enough to allow for more than 32 frames to accumulate in the MAC's internal buffers, a buffer overflow occurs. This patch fixes the problem by making the driver's frame_head_info buffer big enough. Well actually, since the chip appears to have 12K of internal rx buffers and the shortest ethernet frame should be 64 bytes long, maybe the limit could be set to 12*1024/64 = 192 frames, but 255 should be safer. Signed-off-by: Davide Ciminaghi Signed-off-by: Raffaele Recalcati Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit e09252e4613a16a79dfa15df731cb0e6f7f57118 Author: Will Deacon Date: Thu Apr 12 05:54:09 2012 +0000 net: smsc911x: fix skb handling in receive path [ Upstream commit 3c5e979bd037888dd7d722da22da4b43659af485 ] The SMSC911x driver resets the ->head, ->data and ->tail pointers in the skb on the reset path in order to avoid buffer overflow due to packet padding performed by the hardware. This patch fixes the receive path so that the skb pointers are fixed up after the data has been read from the device, The error path is also fixed to use number of words consistently and prevent erroneous FIFO fastforwarding when skipping over bad data. Signed-off-by: Will Deacon Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 71335bb4ceec1191b26eeb068a3877918cb066d6 Author: Jason Wang Date: Wed Apr 11 22:10:54 2012 +0000 8139cp: set intr mask after its handler is registered [ Upstream commit a8c9cb106fe79c28d6b7f1397652cadd228715ff ] We set intr mask before its handler is registered, this does not work well when 8139cp is sharing irq line with other devices. As the irq could be enabled by the device before 8139cp's hander is registered which may lead unhandled irq. Fix this by introducing an helper cp_irq_enable() and call it after request_irq(). Signed-off-by: Jason Wang Reviewed-by: Flavio Leitner Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2f69fc5ed7e603d90aeb088fe5989701a903f14b Author: Tony Zelenoff Date: Wed Apr 11 06:15:03 2012 +0000 atl1: fix kernel panic in case of DMA errors [ Upstream commit 03662e41c7cff64a776bfb1b3816de4be43de881 ] Problem: There was two separate work_struct structures which share one handler. Unfortunately getting atl1_adapter structure from work_struct in case of DMA error was done from incorrect offset which cause kernel panics. Solution: The useless work_struct for DMA error removed and handler name changed to more generic one. Signed-off-by: Tony Zelenoff Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 8d34d1f1b61169add8bdcad2e8b9ddf4f52889cd Author: Eric Dumazet Date: Tue Apr 24 23:01:22 2012 -0400 tcp: avoid order-1 allocations on wifi and tx path [ This combines upstream commit a21d45726acacc963d8baddf74607d9b74e2b723 and the follow-on bug fix commit 22b4a4f22da4b39c6f7f679fd35f3d35c91bf851 ] Marc Merlin reported many order-1 allocations failures in TX path on its wireless setup, that dont make any sense with MTU=1500 network, and non SG capable hardware. After investigation, it turns out TCP uses sk_stream_alloc_skb() and used as a convention skb_tailroom(skb) to know how many bytes of data payload could be put in this skb (for non SG capable devices) Note : these skb used kmalloc-4096 (MTU=1500 + MAX_HEADER + sizeof(struct skb_shared_info) being above 2048) Later, mac80211 layer need to add some bytes at the tail of skb (IEEE80211_ENCRYPT_TAILROOM = 18 bytes) and since no more tailroom is available has to call pskb_expand_head() and request order-1 allocations. This patch changes sk_stream_alloc_skb() so that only sk->sk_prot->max_header bytes of headroom are reserved, and use a new skb field, avail_size to hold the data payload limit. This way, order-0 allocations done by TCP stack can leave more than 2 KB of tailroom and no more allocation is performed in mac80211 layer (or any layer needing some tailroom) avail_size is unioned with mark/dropcount, since mark will be set later in IP stack for output packets. Therefore, skb size is unchanged. Reported-by: Marc MERLIN Tested-by: Marc MERLIN Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller [bwh: Correct commit hash for follow-on bug fix] Signed-off-by: Ben Hutchings commit 91bb95f240936feb98f7d540027c78773e4b84cb Author: Eric Dumazet Date: Sun Dec 4 08:51:08 2011 +0000 tcp: fix tcp_trim_head() [ Upstream commit 4fa48bf3c75069d636fc8830743c929a062e80dc ] commit f07d960df3 (tcp: avoid frag allocation for small frames) breaked assumption in tcp stack that skb is either linear (skb->data_len == 0), or fully fragged (skb->data_len == skb->len) tcp_trim_head() made this assumption, we must fix it. Thanks to Vijay for providing a very detailed explanation. Reported-by: Vijay Subramanian Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 34b0788a13e9c65440e3d736a91f75964356ad67 Author: Eric Dumazet Date: Tue Apr 10 20:08:39 2012 +0000 net: allow pskb_expand_head() to get maximum tailroom [ Upstream commit 87151b8689d890dfb495081f7be9b9e257f7a2df ] Marc Merlin reported many order-1 allocations failures in TX path on its wireless setup, that dont make any sense with MTU=1500 network, and non SG capable hardware. Turns out part of the problem comes from pskb_expand_head() not using ksize() to get exact head size given by kmalloc(). Doing the same thing than __alloc_skb() allows more tailroom in skb and can prevent future reallocations. As a bonus, struct skb_shared_info becomes cache line aligned. Reported-by: Marc MERLIN Tested-by: Marc MERLIN Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 65355aea86b2a70cbc7cbe14466702bc5a4e2217 Author: Neal Cardwell Date: Tue Apr 10 07:59:20 2012 +0000 tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample [ Upstream commit 18a223e0b9ec8979320ba364b47c9772391d6d05 ] Fix a code path in tcp_rcv_rtt_update() that was comparing scaled and unscaled RTT samples. The intent in the code was to only use the 'm' measurement if it was a new minimum. However, since 'm' had not yet been shifted left 3 bits but 'new_sample' had, this comparison would nearly always succeed, leading us to erroneously set our receive-side RTT estimate to the 'm' sample when that sample could be nearly 8x too high to use. The overall effect is to often cause the receive-side RTT estimate to be significantly too large (up to 40% too large for brief periods in my tests). Signed-off-by: Neal Cardwell Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 8a0885b2113dfe7d1fb4f981a3d3c712ad90619c Author: Eric Dumazet Date: Fri Apr 6 10:49:10 2012 +0200 net: fix a race in sock_queue_err_skb() [ Upstream commit 110c43304db6f06490961529536c362d9ac5732f ] As soon as an skb is queued into socket error queue, another thread can consume it, so we are not allowed to reference skb anymore, or risk use after free. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit d6465c3d0237438855ba4adfbdee210d3220ca77 Author: Eric Dumazet Date: Thu Apr 5 22:17:46 2012 +0000 netlink: fix races after skb queueing [ Upstream commit 4a7e7c2ad540e54c75489a70137bf0ec15d3a127 ] As soon as an skb is queued into socket receive_queue, another thread can consume it, so we are not allowed to reference skb anymore, or risk use after free. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 24ac0fa638baec69f527eff78663a2f383014c90 Author: Phil Sutter Date: Mon Mar 26 09:01:30 2012 +0000 wimax: i2400m - prevent a possible kernel bug due to missing fw_name string [ Upstream commit 4eee6a3a04e8bb53fbe7de0f64d0524d3fbe3f80 ] This happened on a machine with a custom hotplug script calling nameif, probably due to slow firmware loading. At the time nameif uses ethtool to gather interface information, i2400m->fw_name is zero and so a null pointer dereference occurs from within i2400m_get_drvinfo(). Signed-off-by: Phil Sutter Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 873f40f17a6a7063af86befe4ffe4f70d98a1b1b Author: Veaceslav Falico Date: Thu Apr 5 03:47:43 2012 +0000 bonding: properly unset current_arp_slave on slave link up [ Upstream commit 5a4309746cd74734daa964acb02690c22b3c8911 ] When a slave comes up, we're unsetting the current_arp_slave without removing active flags from it, which can lead to situations where we have more than one slave with active flags in active-backup mode. To avoid this situation we must remove the active flags from a slave before removing it as a current_arp_slave. Signed-off-by: Veaceslav Falico Signed-off-by: Jay Vosburgh Signed-off-by: Andy Gospodarek Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 1bf5e1db2f65033fb7b80f63fabbe2b8bf2f0936 Author: Sasha Levin Date: Thu Apr 5 12:07:45 2012 +0000 phonet: Check input from user before allocating [ Upstream commit bcf1b70ac6eb0ed8286c66e6bf37cb747cbaa04c ] A phonet packet is limited to USHRT_MAX bytes, this is never checked during tx which means that the user can specify any size he wishes, and the kernel will attempt to allocate that size. In the good case, it'll lead to the following warning, but it may also cause the kernel to kick in the OOM and kill a random task on the server. [ 8921.744094] WARNING: at mm/page_alloc.c:2255 __alloc_pages_slowpath+0x65/0x730() [ 8921.749770] Pid: 5081, comm: trinity Tainted: G W 3.4.0-rc1-next-20120402-sasha #46 [ 8921.756672] Call Trace: [ 8921.758185] [] warn_slowpath_common+0x87/0xb0 [ 8921.762868] [] warn_slowpath_null+0x15/0x20 [ 8921.765399] [] __alloc_pages_slowpath+0x65/0x730 [ 8921.769226] [] ? zone_watermark_ok+0x1a/0x20 [ 8921.771686] [] ? get_page_from_freelist+0x625/0x660 [ 8921.773919] [] __alloc_pages_nodemask+0x1f8/0x240 [ 8921.776248] [] kmalloc_large_node+0x70/0xc0 [ 8921.778294] [] __kmalloc_node_track_caller+0x34/0x1c0 [ 8921.780847] [] ? sock_alloc_send_pskb+0xbc/0x260 [ 8921.783179] [] __alloc_skb+0x75/0x170 [ 8921.784971] [] sock_alloc_send_pskb+0xbc/0x260 [ 8921.787111] [] ? release_sock+0x7e/0x90 [ 8921.788973] [] sock_alloc_send_skb+0x10/0x20 [ 8921.791052] [] pep_sendmsg+0x60/0x380 [ 8921.792931] [] ? pn_socket_bind+0x156/0x180 [ 8921.794917] [] ? pn_socket_autobind+0x3f/0x90 [ 8921.797053] [] pn_socket_sendmsg+0x4f/0x70 [ 8921.798992] [] sock_aio_write+0x187/0x1b0 [ 8921.801395] [] ? sub_preempt_count+0xae/0xf0 [ 8921.803501] [] ? __lock_acquire+0x42c/0x4b0 [ 8921.805505] [] ? __sock_recv_ts_and_drops+0x140/0x140 [ 8921.807860] [] do_sync_readv_writev+0xbc/0x110 [ 8921.809986] [] ? might_fault+0x97/0xa0 [ 8921.811998] [] ? security_file_permission+0x1e/0x90 [ 8921.814595] [] do_readv_writev+0xe2/0x1e0 [ 8921.816702] [] ? do_setitimer+0x1ac/0x200 [ 8921.818819] [] ? get_parent_ip+0x11/0x50 [ 8921.820863] [] ? sub_preempt_count+0xae/0xf0 [ 8921.823318] [] vfs_writev+0x46/0x60 [ 8921.825219] [] sys_writev+0x4f/0xb0 [ 8921.827127] [] system_call_fastpath+0x16/0x1b [ 8921.829384] ---[ end trace dffe390f30db9eb7 ]--- Signed-off-by: Sasha Levin Acked-by: Rémi Denis-Courmont Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 02c4182997a7f38938b2a606bb3cbe37c73ca203 Author: RongQing.Li Date: Wed Apr 4 16:47:04 2012 +0000 ipv6: fix array index in ip6_mc_add_src() [ Upstream commit 78d50217baf36093ab320f95bae0d6452daec85c ] Convert array index from the loop bound to the loop index. And remove the void type conversion to ip6_mc_del1_src() return code, seem it is unnecessary, since ip6_mc_del1_src() does not use __must_check similar attribute, no compiler will report the warning when it is removed. v2: enrich the commit header Signed-off-by: RongQing.Li Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit d30dd36de48371f56bedcd1ac90e96e6a9d235c8 Author: Herbert Xu Date: Wed Apr 4 01:01:20 2012 +0000 bridge: Do not send queries on multicast group leaves [ Upstream commit 996304bbea3d2a094b7ba54c3bd65d3fffeac57b ] As it stands the bridge IGMP snooping system will respond to group leave messages with queries for remaining membership. This is both unnecessary and undesirable. First of all any multicast routers present should be doing this rather than us. What's more the queries that we send may end up upsetting other multicast snooping swithces in the system that are buggy. In fact, we can simply remove the code that send these queries because the existing membership expiry mechanism doesn't rely on them anyway. So this patch simply removes all code associated with group queries in response to group leave messages. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit a13e640b8d17e0a5ab4b388431f877e2feef7abf Author: Thomas Graf Date: Tue Apr 3 22:17:53 2012 +0000 sctp: Allow struct sctp_event_subscribe to grow without breaking binaries [ Upstream commit acdd5985364f8dc511a0762fab2e683f29d9d692 ] getsockopt(..., SCTP_EVENTS, ...) performs a length check and returns an error if the user provides less bytes than the size of struct sctp_event_subscribe. Struct sctp_event_subscribe needs to be extended by an u8 for every new event or notification type that is added. This obviously makes getsockopt fail for binaries that are compiled against an older versions of which do not contain all event types. This patch changes getsockopt behaviour to no longer return an error if not enough bytes are being provided by the user. Instead, it returns as much of sctp_event_subscribe as fits into the provided buffer. This leads to the new behavior that users see what they have been aware of at compile time. The setsockopt(..., SCTP_EVENTS, ...) API is already behaving like this. Signed-off-by: Thomas Graf Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 0d63a9816f225228d72461444c6b1e5f58c6f90b Author: Eric Dumazet Date: Tue Apr 24 22:12:06 2012 -0400 tcp: allow splice() to build full TSO packets [ This combines upstream commit 2f53384424251c06038ae612e56231b96ab610ee and the follow-on bug fix commit 35f9c09fe9c72eb8ca2b8e89a593e1c151f28fc2 ] vmsplice()/splice(pipe, socket) call do_tcp_sendpages() one page at a time, adding at most 4096 bytes to an skb. (assuming PAGE_SIZE=4096) The call to tcp_push() at the end of do_tcp_sendpages() forces an immediate xmit when pipe is not already filled, and tso_fragment() try to split these skb to MSS multiples. 4096 bytes are usually split in a skb with 2 MSS, and a remaining sub-mss skb (assuming MTU=1500) This makes slow start suboptimal because many small frames are sent to qdisc/driver layers instead of big ones (constrained by cwnd and packets in flight of course) In fact, applications using sendmsg() (adding an additional memory copy) instead of vmsplice()/splice()/sendfile() are a bit faster because of this anomaly, especially if serving small files in environments with large initial [c]wnd. Call tcp_push() only if MSG_MORE is not set in the flags parameter. This bit is automatically provided by splice() internals but for the last page, or on all pages if user specified SPLICE_F_MORE splice() flag. In some workloads, this can reduce number of sent logical packets by an order of magnitude, making zero-copy TCP actually faster than one-copy :) Reported-by: Tom Herbert Cc: Nandita Dukkipati Cc: Neal Cardwell Cc: Tom Herbert Cc: Yuchung Cheng Cc: H.K. Jerry Chu Cc: Maciej Żenczykowski Cc: Mahesh Bandewar Cc: Ilpo Järvinen Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 410322fe638452e1e444093033937965bc68a0db Author: David Woodhouse Date: Tue Apr 24 22:09:47 2012 -0400 ppp: Don't stop and restart queue on every TX packet [ This combines upstream commit e675f0cc9a872fd152edc0c77acfed19bf28b81e and follow-on bug fix commit 9a5d2bd99e0dfe9a31b3c160073ac445ba3d773f ] For every transmitted packet, ppp_start_xmit() will stop the netdev queue and then, if appropriate, restart it. This causes the TX softirq to run, entirely gratuitously. This is "only" a waste of CPU time in the normal case, but it's actively harmful when the PPP device is a TEQL slave — the wakeup will cause the offending device to receive the next TX packet from the TEQL queue, when it *should* have gone to the next slave in the list. We end up seeing large bursts of packets on just *one* slave device, rather than using the full available bandwidth over all slaves. This patch fixes the problem by *not* unconditionally stopping the queue in ppp_start_xmit(). It adds a return value from ppp_xmit_process() which indicates whether the queue should be stopped or not. It *doesn't* remove the call to netif_wake_queue() from ppp_xmit_process(), because other code paths (especially from ppp_output_wakeup()) need it there and it's messy to push it out to the other callers to do it based on the return value. So we leave it in place — it's a no-op in the case where the queue wasn't stopped, so it's harmless in the TX path. Signed-off-by: David Woodhouse Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 4ce56133a793c97f5995181504ca9a16146a521f Author: J. Bruce Fields Date: Mon Apr 9 18:06:49 2012 -0400 nfsd: don't fail unchecked creates of non-special files commit 9dc4e6c4d1182d34604ea40fef641775f5b15456 upstream. Allow a v3 unchecked open of a non-regular file succeed as if it were a lookup; typically a client in such a case will want to fall back on a local open, so succeeding and giving it the filehandle is more useful than failing with nfserr_exist, which makes it appear that nothing at all exists by that name. Similarly for v4, on an open-create, return the same errors we would on an attempt to open a non-regular file, instead of returning nfserr_exist. This fixes a problem found doing a v4 open of a symlink with O_RDONLY|O_CREAT, which resulted in the current client returning EEXIST. Thanks also to Trond for analysis. Reported-by: Orion Poplawski Tested-by: Orion Poplawski Signed-off-by: J. Bruce Fields [bwh: Backported to 3.2: use &resfh, not resfh] Signed-off-by: Ben Hutchings commit 205648388f15b1ccf92b09ba0cf141cdd62bf711 Author: Eric Dumazet Date: Mon Apr 2 22:33:02 2012 +0000 net: fix /proc/net/dev regression [ Upstream commit 2def16ae6b0c77571200f18ba4be049b03d75579 ] Commit f04565ddf52 (dev: use name hash for dev_seq_ops) added a second regression, as some devices are missing from /proc/net/dev if many devices are defined. When seq_file buffer is filled, the last ->next/show() method is canceled (pos value is reverted to value prior ->next() call) Problem is after above commit, we dont restart the lookup at right position in ->start() method. Fix this by removing the internal 'pos' pointer added in commit, since we need to use the 'loff_t *pos' provided by seq_file layer. This also reverts commit 5cac98dd0 (net: Fix corruption in /proc/*/net/dev_mcast), since its not needed anymore. Reported-by: Ben Greear Signed-off-by: Eric Dumazet Cc: Mihai Maruseac Tested-by: Ben Greear Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 0ae5d66e40cde5a95ed16d28a480d2ce91834bfc Author: Felipe Balbi Date: Wed Mar 21 11:44:00 2012 +0200 usb: dwc3: ep0: increment "actual" on bounced ep0 case commit cd423dd3634a5232a3019eb372b144619a61cd16 upstream. due to a HW limitation we have a bounce buffer for ep0 out transfers which are not aligned with MaxPacketSize. On such case we were not increment r->actual as we should. This patch fixes that mistake. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 4d0892e26975d5664bdf127646f8d3988c99e98e Author: Al Viro Date: Fri Apr 13 13:49:47 2012 -0400 lockd: fix the endianness bug commit e847469bf77a1d339274074ed068d461f0c872bc upstream. comparing be32 values for < is not doing the right thing... Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit d78cd96d3300d63d574821d8f09a20cb1dd91277 Author: Al Viro Date: Fri Apr 13 12:30:02 2012 -0400 ocfs2: ->e_leaf_clusters endianness breakage commit 72094e43e3af5020510f920321d71f1798fa896d upstream. le16, not le32... Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit 69b90b529cdcbf9cada6f61a12258d0566e7dfd9 Author: Al Viro Date: Fri Apr 13 12:28:21 2012 -0400 ocfs2: ->rl_count endianness breakage commit 28748b325dc2d730ccc312830a91c4ae0c0d9379 upstream. le16, not le32... Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit 56d36f3247cb52050cbd31b214fb7dd76505c72f Author: Al Viro Date: Fri Apr 13 12:27:11 2012 -0400 ocfs: ->rl_used breakage on big-endian commit e1bf4cc620fd143766ddfcee3b004a1d1bb34fd0 upstream. it's le16, not le32 or le64... Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit f7fb2214b45dc499517d60ca59e01ffe23868084 Author: Al Viro Date: Fri Apr 13 12:22:00 2012 -0400 ocfs2: ->l_next_free_req breakage on big-endian commit 3a251f04fe97c3d335b745c98e4b377e3c3899f2 upstream. It's le16, not le32... Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit e8488d51a55aa5f87369e3ad9bda8969b0d4feb2 Author: Al Viro Date: Fri Apr 13 11:49:04 2012 -0400 btrfs: btrfs_root_readonly() broken on big-endian commit 6ed3cf2cdfce4c9f1d73171bd3f27d9cb77b734e upstream. ->root_flags is __le64 and all accesses to it go through the helpers that do proper conversions. Except for btrfs_root_readonly(), which checks bit 0 as in host-endian... Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit 120aa796a02fbe93143bdb1fe2b1d313e41b85b1 Author: Al Viro Date: Fri Apr 13 00:32:14 2012 -0400 nfsd: fix compose_entry_fh() failure exits commit efe39651f08813180f37dc508d950fc7d92b29a8 upstream. Restore the original logics ("fail on mountpoints, negatives and in case of fh_compose() failures"). Since commit 8177e (nfsd: clean up readdirplus encoding) that got broken - rv = fh_compose(fhp, exp, dchild, &cd->fh); if (rv) goto out; if (!dchild->d_inode) goto out; rv = 0; out: is equivalent to rv = fh_compose(fhp, exp, dchild, &cd->fh); out: and the second check has no effect whatsoever... Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit 618b2439559333942fe8debd369a1b313da8286e Author: Al Viro Date: Fri Apr 13 00:10:34 2012 -0400 nfsd: fix endianness breakage in TEST_STATEID handling commit 02f5fde5df0ea930e70f93763dd48beff182b208 upstream. ->ts_id_status gets nfs errno, i.e. it's already big-endian; no need to apply htonl() to it. Broken by commit 174568 (NFSD: Added TEST_STATEID operation) last year... Signed-off-by: Al Viro Cc: "J. Bruce Fields" Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e840ed85f05ecddb718b6e83373974453aedb9a5 Author: Al Viro Date: Fri Apr 13 00:00:04 2012 -0400 nfsd: fix error values returned by nfsd4_lockt() when nfsd_open() fails commit 04da6e9d63427b2d0fd04766712200c250b3278f upstream. nfsd_open() already returns an NFS error value; only vfs_test_lock() result needs to be fed through nfserrno(). Broken by commit 55ef12 (nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT) three years ago... Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit 0d476b05b6ca6709547c729fd19f4b82f7020fdd Author: Al Viro Date: Fri Apr 27 17:42:43 2012 -0500 nfsd: fix b0rken error value for setattr on read-only mount commit 96f6f98501196d46ce52c2697dd758d9300c63f5 upstream. ..._want_write() returns -EROFS on failure, _not_ an NFS error value. Signed-off-by: Al Viro Signed-off-by: Jonathan Nieder Signed-off-by: Ben Hutchings commit 7af21761eb33fb6087679299019c3010ce120381 Author: Gertjan van Wingerde Date: Wed Dec 28 01:53:18 2011 +0100 rt2x00: Identify rt2800usb chipsets. commit bc93eda7e903ff75cefcb6e247ed9b8e9f8e9783 upstream. According to the latest USB ID database these are all RT2770 / RT2870 / RT307x devices. Signed-off-by: Gertjan van Wingerde Acked-by: Ivo van Doorn Signed-off-by: John W. Linville [bwh: Backported to 3.2: adjust context for previously cherry-picked commit d42a179b941a9e4cc6cf41d0f3cbadd75fc48a89 'rt2x00: Add support for D-Link DWA-127 to rt2800usb'] Signed-off-by: Ben Hutchings commit 3b6c21f3a2371dc461e77d86abd5a82443c010ee Author: Alan Cox Date: Mon Dec 19 21:07:33 2011 +0000 rt2800: Add support for the Fujitsu Stylistic Q550 commit 3ac44670ad0fca8b6c43b3e4d8494c67c419f494 upstream. Just another USB identifier. Signed-off-by: Alan Cox Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 2b1d2ce2393718972e2d1df85ad1830a4dd26e88 Author: Kenth Eriksson Date: Fri Mar 30 17:05:30 2012 +0200 spi/mpc83xx: fix NULL pdata dereference bug commit 5039a86973cd35bdb2f64d28ee12f13fe2bb5a4c upstream. Commit 178db7d3, "spi: Fix device unregistration when unregistering the bus master", changed device initialization to be children of the bus master, not children of the bus masters parent device. The pdata pointer used in fsl_spi_chipselect must updated to reflect the changed initialization. Signed-off-by: Kenth Eriksson Acked-by: Joakim Tjernlund Signed-off-by: Grant Likely Signed-off-by: Ben Hutchings commit 4cfa4199d07dfbb9ff3b0f84857a4c81c8b17cae Author: Laurent Pinchart Date: Mon Dec 12 01:15:06 2011 +0100 spi: Fix device unregistration when unregistering the bus master commit 178db7d30f94707efca1a189753c105ef69942ed upstream. Device are added as children of the bus master's parent device, but spi_unregister_master() looks for devices to unregister in the bus master's children. This results in the child devices not being unregistered. Fix this by registering devices as direct children of the bus master. Signed-off-by: Laurent Pinchart Signed-off-by: Grant Likely Signed-off-by: Ben Hutchings commit e4a81003b038ab31ba745f8b93398f2016f55623 Author: Jason Baron Date: Fri Mar 16 16:34:03 2012 -0400 Don't limit non-nested epoll paths commit 93dc6107a76daed81c07f50215fa6ae77691634f upstream. Commit 28d82dc1c4ed ("epoll: limit paths") that I did to limit the number of possible wakeup paths in epoll is causing a few applications to longer work (dovecot for one). The original patch is really about limiting the amount of epoll nesting (since epoll fds can be attached to other fds). Thus, we probably can allow an unlimited number of paths of depth 1. My current patch limits it at 1000. And enforce the limits on paths that have a greater depth. This is captured in: https://bugzilla.redhat.com/show_bug.cgi?id=681578 Signed-off-by: Jason Baron Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jonathan Nieder Signed-off-by: Ben Hutchings commit 40cf2cc442076b3d276e96c1622205123cc27a9a Author: AceLan Kao Date: Wed Mar 28 10:25:36 2012 +0800 Bluetooth: Add support for Atheros [04ca:3005] commit 55ed7d4d1469eafbe3ad7e8fcd44f5af27845a81 upstream. Add another vendor specific ID for Atheros AR3012 device. This chip is wrapped by Lite-On Technology Corp. output of usb-devices: T: Bus=04 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3005 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: AceLan Kao Signed-off-by: Gustavo Padovan Signed-off-by: Ben Hutchings commit 395402e9004e376bc741d7d7cb78087e20fe9e53 Author: AceLan Kao Date: Tue Jan 17 16:18:06 2012 +0800 dell-laptop: touchpad LED should persist its status after S3 commit 2d5de9e84928e35b4d9b46b4d8d5dcaac1cff1fa upstream. Touchpad LED will not turn on after S3, it will make the touchpad status doesn't consist with the LED. By adding one flag to let the LED device restore it's status. Signed-off-by: AceLan Kao Signed-off-by: Matthew Garrett Signed-off-by: Ben Hutchings commit c9d8f95079dce15a34c7048e586ea896466075e2 Author: AceLan Kao Date: Thu Nov 17 15:30:42 2011 +0800 dell-laptop: add 3 machines that has touchpad LED commit 2a748853ca395c48ea75baa250f7cea6f0f23dbf upstream. Add "Vostro 3555", "Inspiron N311z", and "Inspiron M5110" into quirks, so that they could have touchpad LED function work. Signed-off-by: AceLan Kao Signed-off-by: Matthew Garrett Signed-off-by: Ben Hutchings commit 1e57aab4e6c549804298f07fac0b6fc77f10fab2 Author: Alex Williamson Date: Fri Apr 27 16:54:08 2012 -0500 KVM: unmap pages from the iommu when slots are removed commit 32f6daad4651a748a58a3ab6da0611862175722f upstream. We've been adding new mappings, but not destroying old mappings. This can lead to a page leak as pages are pinned using get_user_pages, but only unpinned with put_page if they still exist in the memslots list on vm shutdown. A memslot that is destroyed while an iommu domain is enabled for the guest will therefore result in an elevated page reference count that is never cleared. Additionally, without this fix, the iommu is only programmed with the first translation for a gpa. This can result in peer-to-peer errors if a mapping is destroyed and replaced by a new mapping at the same gpa as the iommu will still be pointing to the original, pinned memory address. Signed-off-by: Alex Williamson Signed-off-by: Marcelo Tosatti Signed-off-by: Jonathan Nieder Signed-off-by: Ben Hutchings commit 4cd37e4fc23fe6cc7aa933e75dc794c85d0f330a Author: Al Viro Date: Thu Apr 12 20:32:25 2012 -0400 ext4: fix endianness breakage in ext4_split_extent_at() commit af1584f570b19b0285e4402a0b54731495d31784 upstream. ->ee_len is __le16, so assigning cpu_to_le32() to it is going to do Bad Things(tm) on big-endian hosts... Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit 52b7f704efa589dcef1cdbda8accad9d251c20e6 Author: Thomas Jarosch Date: Wed Dec 7 22:08:11 2011 +0100 PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs commit f67fd55fa96f7d7295b43ffbc4a97d8f55e473aa upstream. Some BIOS implementations leave the Intel GPU interrupts enabled, even though no one is handling them (f.e. i915 driver is never loaded). Additionally the interrupt destination is not set up properly and the interrupt ends up -somewhere-. These spurious interrupts are "sticky" and the kernel disables the (shared) interrupt line after 100.000+ generated interrupts. Fix it by disabling the still enabled interrupts. This resolves crashes often seen on monitor unplug. Tested on the following boards: - Intel DH61CR: Affected - Intel DH67BL: Affected - Intel S1200KP server board: Affected - Asus P8H61-M LE: Affected, but system does not crash. Probably the IRQ ends up somewhere unnoticed. According to reports on the net, the Intel DH61WW board is also affected. Many thanks to Jesse Barnes from Intel for helping with the register configuration and to Intel in general for providing public hardware documentation. Signed-off-by: Thomas Jarosch Tested-by: Charlie Suffin Signed-off-by: Jesse Barnes [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 2e67ffa6107563e7c147d3648d7b457c0ac571d8 Author: Shubhrajyoti D Date: Thu Mar 22 12:48:06 2012 +0530 usb: musb: omap: fix the error check for pm_runtime_get_sync commit ad579699c4f0274bf522a9252ff9b20c72197e48 upstream. pm_runtime_get_sync returns a signed integer. In case of errors it returns a negative value. This patch fixes the error check by making it signed instead of unsigned thus preventing register access if get_sync_fails. Also passes the error cause to the debug message. Cc: Kishon Vijay Abraham I Signed-off-by: Shubhrajyoti D Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit f48a6c0a5a021f575ca37d923b4149317bcb4c63 Author: Kishon Vijay Abraham I Date: Wed Mar 21 21:30:20 2012 +0530 usb: musb: omap: fix crash when musb glue (omap) gets initialized commit 3006dc8c627d738693e910c159630e4368c9e86c upstream. pm_runtime_enable is being called after omap2430_musb_init. Hence pm_runtime_get_sync in omap2430_musb_init does not have any effect (does not enable clocks) resulting in a crash during register access. It is fixed here. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit 5292bdd3ee31c6893a62df34b39e3814bfa4b553 Author: Andrzej Pietrasiewicz Date: Wed Mar 28 09:30:50 2012 +0200 usb: gadget: eliminate NULL pointer dereference (bugfix) commit 92b0abf80c5c5f0e0d71d1309688a330fd74731b upstream. usb: gadget: eliminate NULL pointer dereference (bugfix) This patch fixes a bug which causes NULL pointer dereference in ffs_ep0_ioctl. The bug happens when the FunctionFS is not bound (either has not been bound yet or has been bound and then unbound) and can be reproduced with running the following commands: $ insmod g_ffs.ko $ mount -t functionfs func /dev/usbgadget $ ./null where null.c is: #include #include int main(void) { int fd = open("/dev/usbgadget/ep0", O_RDWR); ioctl(fd, FUNCTIONFS_CLEAR_HALT); return 0; } Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Kyungmin Park Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit 2eefeef94ff4472fb873c5803122358ba43a66db Author: Alan Stern Date: Thu Apr 26 11:31:57 2012 -0400 usb: gadget: udc-core: fix incompatibility with dummy-hcd commit 320cd1e750f1bf3e47eb41209dcb2be07264cb76 upstream. This patch (as1548) fixes a recently-introduced incompatibility between the UDC core and the dummy-hcd driver. Commit 8ae8090c82eb407267001f75b3d256b3bd4ae691 (usb: gadget: udc-core: fix asymmetric calls in remove_driver) moved the usb_gadget_udc_stop() call in usb_gadget_remove_driver() below the usb_gadget_disconnect() call. As a result, usb_gadget_disconnect() gets called at a time when the gadget driver believes it has been unbound but dummy-hcd believes it has not. A nasty error ensues when dummy-hcd calls the gadget driver's disconnect method a second time. To fix the problem, this patch moves the gadget driver's unbind notification after the usb_gadget_disconnect() call. Now nothing happens between the two unbind notifications, so nothing goes wrong. Signed-off-by: Alan Stern Tested-by: Alexander Shishkin Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit 8945357368ceff19178f11eb2851f22460ce71d2 Author: Felipe Balbi Date: Fri Apr 27 11:02:15 2012 +0300 usb: gadget: udc-core: fix wrong call order commit 83a787a71e034244a9fd1d5988fe18f226341417 upstream. commit 6d258a4 (usb: gadget: udc-core: stop UDC on device-initiated disconnect) introduced another case of asymmetric calls when issuing a device-initiated disconnect. Fix it. Reported-by: Ben Hutchings Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit d3c291109eabed083b51c07805ccd6a595c62293 Author: Kishon Vijay Abraham I Date: Wed Mar 21 21:34:30 2012 +0530 usb: gadget: udc-core: fix asymmetric calls in remove_driver commit 8ae8090c82eb407267001f75b3d256b3bd4ae691 upstream. During modprobe of gadget driver, pullup is called after udc_start. In order to make the exit path symmetric when removing a gadget driver, call pullup before ->udc_stop. This is needed to avoid issues with PM where udc_stop disables the module completely (put IP in reset state, cut functional and interface clocks, and so on), which prevents us from accessing the IP's address space, thus creating the possibility of an abort exception when we try to access IP's address space after clocks are off. Signed-off-by: Partha Basak Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit cae3fe8f1d95bf654378f9dc8b3404348ac7225c Author: Felipe Balbi Date: Thu Mar 15 16:37:18 2012 +0200 usb: gadget: udc-core: stop UDC on device-initiated disconnect commit 6d258a4c42089229b855fd706622029decf316d6 upstream. When we want to do device-initiated disconnect, let's make sure we stop the UDC in order to e.g. allow lower power states to be achieved by turning off unnecessary clocks and/or stoping PHYs. When reconnecting, call ->udc_start() again to make sure UDC is reinitialized. Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit 90114113b4dc19abc832f03f1c1b7b837ba00af0 Author: Alan Stern Date: Tue Apr 17 15:22:39 2012 -0400 USB: fix deadlock in bConfigurationValue attribute method commit 8963c487a80b4688c9e68dcc504a90074aacc145 upstream. This patch (as154) fixes a self-deadlock that occurs when userspace writes to the bConfigurationValue sysfs attribute for a hub with children. The task tries to lock the bandwidth_mutex at a time when it already owns the lock: The attribute's method calls usb_set_configuration(), which calls usb_disable_device() with the bandwidth_mutex held. usb_disable_device() unregisters the existing interfaces, which causes the hub driver to be unbound. The hub_disconnect() routine calls hub_quiesce(), which calls usb_disconnect() for each of the hub's children. usb_disconnect() attempts to acquire the bandwidth_mutex around a call to usb_disable_device(). The solution is to make usb_disable_device() acquire the mutex for itself instead of requiring the caller to hold it. Then the mutex can cover only the bandwidth deallocation operation and not the region where the interfaces are unregistered. This has the potential to change system behavior slightly when a config change races with another config or altsetting change. Some of the bandwidth released from the old config might get claimed by the other config or altsetting, make it impossible to restore the old config in case of a failure. But since we don't try to recover from config-change failures anyway, this doesn't matter. [This should be marked for stable kernels that contain the commit fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when usb_disable_device is called." That commit was marked for stable kernels as old as 2.6.32.] Signed-off-by: Alan Stern Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 03668ebf38dcb0add8c2e55f1c6f02dcd4f16494 Author: Alan Stern Date: Wed Apr 18 11:33:00 2012 -0400 EHCI: always clear the STS_FLR status bit commit 2fbe2bf1fd37f9d99950bd8d8093623cf22cf08b upstream. This patch (as1544) fixes a problem affecting some EHCI controllers. They can generate interrupts whenever the STS_FLR status bit is turned on, even though that bit is masked out in the Interrupt Enable register. Since the driver doesn't use STS_FLR anyway, the patch changes the interrupt routine to clear that bit whenever it is set, rather than leaving it alone. Signed-off-by: Alan Stern Reported-and-tested-by: Tomoya MORINAGA Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 1c09b62a4c42d7049e433458859f1c4e61467693 Author: Alan Stern Date: Tue Apr 17 15:24:15 2012 -0400 EHCI: fix criterion for resuming the root hub commit dc75ce9d929aabeb0843a6b1a4ab320e58ba1597 upstream. This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended. Right now the driver tests whether the root hub is running, and that is not the correct test. In particular, if the controller has died then the root hub should not be restarted. In addition, some buggy hardware occasionally requires the root hub to be running and sending out SOF packets even while it is nominally supposed to be suspended. In the end, the test needs to be changed. Rather than checking whether the root hub is currently running, the driver will now check whether the root hub is currently suspended. This will yield the correct behavior in all cases. Signed-off-by: Alan Stern CC: Peter Chen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit a7e8b05866d9ab6b9f01bd56f3c1abe5af2500bb Author: Bjørn Mork Date: Tue Apr 17 21:37:29 2012 +0200 USB: sierra: avoid QMI/wwan interface on MC77xx commit 749541d19e70905e3971f2a08335a206a98e4d0c upstream. These devices have a number of non serial interfaces as well. Use the existing "Direct IP" blacklist to prevent binding to interfaces which are handled by other drivers. We also extend the "Direct IP" blacklist with with interfaces only seen in "QMI" mode, assuming that these devices use the same interface numbers for serial interfaces both in "Direct IP" and in "QMI" mode. Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 6e59e5037a68d230884c279f4e2b8d8ca60c3f29 Author: Julia Lawall Date: Thu Apr 19 18:12:40 2012 +0200 drivers/tty/amiserial.c: add missing tty_unlock commit d3a7b83f865b46bb7b5e1ed18a129ce1af349db4 upstream. tty_unlock is used on all other exits from the function. Signed-off-by: Julia Lawall Acked-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 493fe64b95d87298d19d5390f82d822ff37cc38d Author: Tomoya MORINAGA Date: Thu Apr 12 10:47:50 2012 +0900 pch_uart: Fix dma channel unallocated issue commit af6d17cdc8c89aeb3101f0d27cd32fc0592b40b2 upstream. This driver anticipates pch_uart_verify_port() is not called during installation. However, actually pch_uart_verify_port() is called during installation. As a result, memory access violation occurs like below. 0. initial value: use_dma=0 1. starup() - dma channel is not allocated because use_dma=0 2. pch_uart_verify_port() - Set use_dma=1 3. UART processing acts DMA mode because use_dma=1 - memory access violation occurs! This patch fixes the issue. Solution: Whenever pch_uart_verify_port() is called and then dma channel is not allocated, the channel should be allocated. Signed-off-by: Tomoya MORINAGA Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 022666433f5a7f8bf7e075ab4814061a824dd236 Author: Yuri Matylitski Date: Fri Apr 20 12:38:32 2012 +0300 USB: serial: cp210x: Fixed usb_control_msg timeout values commit 2d5733fcd33dd451022d197cb6b476e970519ca7 upstream. Fixed too small hardcoded timeout values for usb_control_msg in driver for SiliconLabs cp210x-based usb-to-serial adapters. Replaced with USB_CTRL_GET_TIMEOUT/USB_CTRL_SET_TIMEOUT. Signed-off-by: Yuri Matylitski Acked-by: Kirill A. Shutemov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit f25543699889485de366c0ccf311fc593946c96e Author: Shaohua Li Date: Fri Apr 13 10:27:35 2012 +0800 jbd2: use GFP_NOFS for blkdev_issue_flush commit 99aa78466777083255b876293e9e83dec7cd809a upstream. flush request is issued in transaction commit code path, so looks using GFP_KERNEL to allocate memory for flush request bio falls into the classic deadlock issue. I saw btrfs and dm get it right, but ext4, xfs and md are using GFP. Signed-off-by: Shaohua Li Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Signed-off-by: Ben Hutchings commit 31097a1c490c409385e28a64284bde16a4bfe76b Author: NeilBrown Date: Tue Apr 24 10:23:16 2012 +1000 md: fix possible corruption of array metadata on shutdown. commit 30b8aa9172dfeaac6d77897c67ee9f9fc574cdbb upstream. commit c744a65c1e2d59acc54333ce8 md: don't set md arrays to readonly on shutdown. removed the possibility of a 'BUG' when data is written to an array that has just been switched to read-only, but also introduced the possibility that the array metadata could be corrupted. If, when md_notify_reboot gets the mddev lock, the array is in a state where it is assembled but hasn't been started (as can happen if the personality module is not available, or in other unusual situations), then incorrect metadata will be written out making it impossible to re-assemble the array. So only call __md_stop_writes() if the array has actually been activated. This patch is needed for any stable kernel which has had the above commit applied. Reported-by: Christoph Nelles Signed-off-by: NeilBrown Signed-off-by: Ben Hutchings commit 4f75fb8504bd41f9fbb455188b3e75f8d248737e Author: Hugh Dickins Date: Mon Apr 23 11:14:50 2012 -0700 mm: fix s390 BUG by __set_page_dirty_no_writeback on swap commit aca50bd3b4c4bb5528a1878158ba7abce41de534 upstream. Mel reports a BUG_ON(slot == NULL) in radix_tree_tag_set() on s390 3.0.13: called from __set_page_dirty_nobuffers() when page_remove_rmap() tries to transfer dirty flag from s390 storage key to struct page and radix_tree. That would be because of reclaim's shrink_page_list() calling add_to_swap() on this page at the same time: first PageSwapCache is set (causing page_mapping(page) to appear as &swapper_space), then page->private set, then tree_lock taken, then page inserted into radix_tree - so there's an interval before taking the lock when the radix_tree slot is empty. We could fix this by moving __add_to_swap_cache()'s spin_lock_irq up before the SetPageSwapCache. But a better fix is simply to do what's five years overdue: Ken Chen introduced __set_page_dirty_no_writeback() (if !PageDirty TestSetPageDirty) for tmpfs to skip all the radix_tree overhead, and swap is just the same - it ignores the radix_tree tag, and does not participate in dirty page accounting, so should be using __set_page_dirty_no_writeback() too. s390 testing now confirms that this does indeed fix the problem. Reported-by: Mel Gorman Signed-off-by: Hugh Dickins Acked-by: Mel Gorman Cc: Andrew Morton Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Rik van Riel Cc: Ken Chen Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit c2ea42542f001d57d32cf5c0300e31fb4af3f610 Author: David Miller Date: Wed Apr 25 19:41:32 2012 -0500 Fix modpost failures in fedora 17 commit e88aa7bbbe3046a125ea1936b16bb921cc9c6349 upstream. The symbol table on x86-64 starts to have entries that have names like: _GLOBAL__sub_I_65535_0___mod_x86cpu_device_table They are of type STT_FUNCTION and this one had a length of 18. This matched the device ID validation logic and it barfed because the length did not meet the device type's criteria. -------------------- FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18. Fix definition of struct x86cpu_device_id in mod_devicetable.h -------------------- These are some kind of compiler tool internal stuff being emitted and not something we want to inspect in modpost's device ID table validation code. So skip the symbol if it is not of type STT_OBJECT. Signed-off-by: David S. Miller Acked-by: Sam Ravnborg Signed-off-by: Michal Marek Signed-off-by: Jonathan Nieder Signed-off-by: Ben Hutchings commit aed107521ffe75c69f5fb6e77e7bbbadbbcc7cea Author: Lukasz Kucharczyk Date: Wed Apr 11 14:55:10 2012 +0200 cfg80211: fix interface combinations check. commit e55a4046dab28c440c96890bdddcf02dc8981f2d upstream. Signed-off-by: Lukasz Kucharczyk Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 2c51332d50dd5eba50821d0decc4f64e4b71226e Author: Alexey Khoroshilov Date: Thu Apr 5 18:53:20 2012 -0300 drxk: Does not unlock mutex if sanity check failed in scu_command() commit e4459e1682c107d7ee1bf102c1ba534230e9b50b upstream. If sanity check fails in scu_command(), goto error leads to unlock of an unheld mutex. The check should not fail in reality, but it nevertheless worth fixing. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit a15d032c254a9d0cd0640190cef33a5b840290c7 Author: David Härdeman Date: Sun Apr 8 06:13:04 2012 -0300 rc-core: set mode for winbond-cir commit d9b786955f80fb306471fdb9ea24c6d03af6ca36 upstream. Setting the correct mode is required by rc-core or scancodes won't be generated (which isn't very user-friendly). This one-line fix should be suitable for 3.4-rc2. Signed-off-by: David Härdeman Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit d609909f0d6c69937057237b3eff577311d08d07 Author: Arend van Spriel Date: Wed Apr 11 11:52:51 2012 +0200 brcm80211: smac: resume transmit fifo upon receiving frames commit badc4f07622f0f7093a201638f45e85765f1b5e4 upstream. There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211. This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3. Tested-by: Francesco Saverio Schiavarelli Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Brett Rudley Signed-off-by: Arend van Spriel Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit a5f948e19be44b5fda9e07c34979dee0126199cd Author: Bing Zhao Date: Thu Apr 12 19:00:35 2012 -0700 mwifiex: update pcie8766 scratch register addresses commit 428ca8a7065354877db63ceabfc493107686eebe upstream. The scratch register addresses have been changed for newer chips. Since the old chip was never shipped and it will not be supported any more, just update register addresses to support the new chips. Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 25c6d69f0166cdf2e0bb69d1c41614731ec8873d Author: Christian Riesch Date: Mon Apr 16 04:35:25 2012 +0000 davinci_mdio: Fix MDIO timeout check commit 5b76d0600b2b08eef77f8e9226938b7b6bde3099 upstream. Under heavy load (flood ping) it is possible for the MDIO timeout to expire before the loop checks the GO bit again. This patch adds an additional check whether the operation was done before actually returning -ETIMEDOUT. To reproduce this bug, flood ping the device, e.g., ping -f -l 1000 After some time, a "timed out waiting for user access" warning may appear. And even worse, link may go down since the PHY reported a timeout. Signed-off-by: Christian Riesch Cc: Cyril Chemparathy Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 82738cc03fddc48211a5a5c845c192a914e4971c Author: Oliver Neukum Date: Wed Apr 18 10:05:55 2012 +0200 uwb: fix error handling commit 5bd7b419ef2eb4989b207753e088c3437159618a upstream. Fatal errors such as a device disconnect must not trigger error handling. The error returns must be checked. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 52f274aeb59471c970756082dd94c8db630495f3 Author: Oliver Neukum Date: Mon Apr 16 15:28:28 2012 +0200 uwb: fix use of del_timer_sync() in interrupt commit 9426cd05682745d1024dbabdec5631309bd2f480 upstream. del_timer_sync() cannot be used in interrupt. Replace it with del_timer() and a flag Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 8047d2777a1a75d796b20876897c166de9664937 Author: Tomoki Sekiyama Date: Fri Mar 30 08:51:36 2012 +0900 USB: yurex: Fix missing URB_NO_TRANSFER_DMA_MAP flag in urb commit 532f17b5d59bf0deb6f1ff9bc1fb27d5b5011c09 upstream. Current probing code is setting URB_NO_TRANSFER_DMA_MAP flag into a wrong urb structure, and this causes BUG_ON with some USB host implementations. This patch fixes the issue. Signed-off-by: Tomoki Sekiyama Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e0d502ac7fd46a9b1125404be1b6eeb383cdd833 Author: Tomoki Sekiyama Date: Fri Mar 30 08:51:28 2012 +0900 USB: yurex: Remove allocation of coherent buffer for setup-packet buffer commit 523fc5c14f6cad283e5a266eba0e343aed6e73d5 upstream. Removes allocation of coherent buffer for the control-request setup-packet buffer from the yurex driver. Using coherent buffers for setup-packet is obsolete and does not work with some USB host implementations. Signed-off-by: Tomoki Sekiyama Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 24815a3dbb017e5e738132882c89d3acddcf735e Author: Konrad Rzeszutek Wilk Date: Tue Apr 17 22:21:38 2012 -0400 xen/xenbus: Add quirk to deal with misconfigured backends. commit 3066616ce23aad5719c23a0f21f32676402cb44b upstream. A rather annoying and common case is when booting a PVonHVM guest and exposing the PV KBD and PV VFB - as broken toolstacks don't always initialize the backends correctly. Normally The HVM guest is using the VGA driver and the emulated keyboard for this (though upstream version of QEMU implements PV KBD, but still uses a VGA driver). We provide a very basic two-stage wait mechanism - where we wait for 30 seconds for all devices, and then for 270 for all them except the two mentioned. That allows us to wait for the essential devices, like network or disk for the full 6 minutes. To trigger this, put this in your guest config: vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1'] instead of this: vnc=1 vnclisten="0.0.0.0" Acked-by: Stefano Stabellini [v3: Split delay in non-essential (30 seconds) and essential devices per Ian and Stefano suggestion] [v4: Added comments per Stefano suggestion] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Ben Hutchings commit 25a873a89ffb910c5a28fe792b008e6a93d99242 Author: Stefano Stabellini Date: Tue Apr 3 18:05:47 2012 +0100 xen/gntdev: do not set VM_PFNMAP commit e8e937be971d706061dc56220ff3605ab77622a7 upstream. Since we are using the m2p_override we do have struct pages corresponding to the user vma mmap'ed by gntdev. Removing the VM_PFNMAP flag makes get_user_pages work on that vma. An example test case would be using a Xen userspace block backend (QDISK) on a file on NFS using O_DIRECT. Signed-off-by: Stefano Stabellini Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Ben Hutchings commit 7efde257ac4e92ca6b403b72873126ebfd0e9308 Author: Eric Bénard Date: Wed Apr 18 02:30:20 2012 +0200 mmc: unbreak sdhci-esdhc-imx on i.MX25 commit b89152824f993a9572b47eb31f4579feadeac34c upstream. This was broken by me in 37865fe91582582a6f6c00652f6a2b1ff71f8a78 ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read). Signed-off-by: Eric Bénard Acked-by: Wolfram Sang Signed-off-by: Chris Ball Signed-off-by: Ben Hutchings commit 2e4e5f0d0317d1d9b01326e79f8dce7215fc3c41 Author: Adrian Hunter Date: Thu Apr 5 14:45:48 2012 +0300 mmc: fixes for eMMC v4.5 sanitize operation commit 283028122db37621b124f079ca8eae5b64807ad4 upstream. eMMC v4.5 sanitize operation erases all copies of unmapped data. However trim or erase operations must be used first to unmap the required sectors. That was not being done. Fixes apply to linux 3.2 on. Signed-off-by: Adrian Hunter Acked-by: Jaehoon Chung Acked-by: Linus Walleij Signed-off-by: Chris Ball Signed-off-by: Ben Hutchings commit 531503404e61ab77da44f0ea7e6b2ae16bcf004a Author: Adrian Hunter Date: Thu Apr 5 14:45:47 2012 +0300 mmc: fixes for eMMC v4.5 discard operation commit 7194efb8f063ee3aa0cb50d9002348887e68ec10 upstream. eMMC v4.5 discard operation is significantly different from the existing trim operation because it is not guaranteed to work with the new sanitize operation. Consequently mmc_can_trim() is separated from mmc_can_discard(). Also the new discard operation does not result in the sectors being set to all-zeros, so discard_zeroes_data must not be set. In addition, the new discard has the same timeout as trim, but from v4.5 trim is defined to use the hc timeout. The timeout calculation is adjusted accordingly. Fixes apply to linux 3.2 on. Signed-off-by: Adrian Hunter Acked-by: Jaehoon Chung Acked-by: Linus Walleij Signed-off-by: Chris Ball Signed-off-by: Ben Hutchings commit 0226dfd2a217e1a8123e2d26c98ac4f1dadc2eea Author: Paul Walmsley Date: Tue Apr 10 18:36:02 2012 -0600 ARM: OMAP1: DMTIMER: fix broken timer clock source selection commit 6aaec67da1e41a0752a2b903b989e73b9f02e182 upstream. DMTIMER source selection on OMAP1 is broken. omap1_dm_timer_set_src() tries to use __raw_{read,write}l() to read from and write to physical addresses, but those functions take virtual addresses. sparse caught this: arch/arm/mach-omap1/timer.c:50:13: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap1/timer.c:50:13: expected void const volatile [noderef] * arch/arm/mach-omap1/timer.c:50:13: got unsigned int arch/arm/mach-omap1/timer.c:52:9: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap1/timer.c:52:9: expected void const volatile [noderef] * arch/arm/mach-omap1/timer.c:52:9: got unsigned int Fix by using omap_{read,writel}(), just like the other users of the MOD_CONF_CTRL_1 register in the OMAP1 codebase. Of course, in the long term, removing omap_{read,write}l() is the appropriate thing to do; but this will take some work to do this cleanly. Looks like this was caused by 97933d6 (ARM: OMAP1: dmtimer: conversion to platform devices) that dangerously moved code and changed it in the same patch. Signed-off-by: Paul Walmsley Cc: Tarun Kanti DebBarma [tony@atomide.com: updated comments to include the breaking commit] Signed-off-by: Tony Lindgren Signed-off-by: Ben Hutchings commit 4bbc6c95aa832cc52517d6aa7c0b9848ff6cb9bc Author: Alexander Shiyan Date: Tue Mar 27 12:22:49 2012 +0400 ARM: clps711x: serial driver hungs are a result of call disable_irq within ISR commit 7a6fbc9a887193a1e9f8658703881c528040afbc upstream. Since 2.6.30-rc1 clps711x serial driver hungs system. This is a result of call disable_irq from ISR. synchronize_irq waits for end of interrupt and goes to infinite loop. This patch fix this problem. Signed-off-by: Alexander Shiyan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 79e4f41d995c273e972563387ecadb746448c2a1 Author: Takashi Iwai Date: Thu Apr 19 15:18:08 2012 +0200 ALSA: hda/conexant - Set up the missing docking-station pins commit d70f363222ef373c2037412f09a600357cfa1c7a upstream. ThinkPad 410,420,510,520 and X201 with cx50585 & co chips have the docking-station ports, but BIOS doesn't initialize for these pins. Thus, like the former X200, we need to set up the pins manually in the driver. The odd part is that the same PCI SSID is used for X200 and T400, thus we need to prepare individual fixup tables for cx5051 and others. Bugzilla entries: https://bugzilla.redhat.com/show_bug.cgi?id=808559 https://bugzilla.redhat.com/show_bug.cgi?id=806217 https://bugzilla.redhat.com/show_bug.cgi?id=810697 Reported-by: Josh Boyer Reported-by: Jens Taprogge Tested-by: Jens Taprogge Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 78087159d096454183b0789b1a42e39a7e7505a4 Author: Takashi Iwai Date: Thu Apr 19 15:15:25 2012 +0200 ALSA: hda/conexant - Don't set HP pin-control bit unconditionally commit ca3649de026ff95c6f2847e8d096cf2f411c02b3 upstream. Some output pins on Conexant chips have no HP control bit, but the auto-parser initializes these pins unconditionally with PIN_HP. Check the pin-capability and avoid the HP bit if not supported. Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit eea1acbaf0cd548972b40827c37667dcfdf5cbe5 Author: Kent Yoder Date: Thu Apr 5 20:34:20 2012 +0800 crypto: sha512 - Fix byte counter overflow in SHA-512 commit 25c3d30c918207556ae1d6e663150ebdf902186b upstream. The current code only increments the upper 64 bits of the SHA-512 byte counter when the number of bytes hashed happens to hit 2^64 exactly. This patch increments the upper 64 bits whenever the lower 64 bits overflows. Signed-off-by: Kent Yoder Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit 7001ddb0b258c86ba43df349ff0462e69a8221f7 Author: Zeev Tarantov Date: Mon Apr 23 09:37:04 2012 +0300 Perf: fix build breakage [Patch not needed upstream as this is a backport build bugfix - gregkh gcc correctly complains: util/hist.c: In function ‘__hists__add_entry’: util/hist.c:240:27: error: invalid type argument of ‘->’ (have ‘struct hist_entry’) util/hist.c:241:23: error: invalid type argument of ‘->’ (have ‘struct hist_entry’) for this new code: + if (he->ms.map != entry->ms.map) { + he->ms.map = entry->ms.map; + if (he->ms.map) + he->ms.map->referenced = true; + } because "entry" is a "struct hist_entry", not a pointer to a struct. In mainline, "entry" is a pointer to struct passed as argument to the function. So this is broken during backporting. But obviously not compile tested. Signed-off-by: Zeev Tarantov Cc: Signed-off-by: David S. Miller Cc: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings