commit 1569265782ef26ed77ce45ebeb0676f11d4c114a Author: Greg Kroah-Hartman Date: Thu Feb 6 11:08:34 2014 -0800 Linux 3.10.29 commit fcac46cc8cc4f25028a91cda57c67f8469cbdbe1 Author: Borislav Petkov Date: Wed Jan 15 00:07:11 2014 +0100 x86, cpu, amd: Add workaround for family 16h, erratum 793 commit 3b56496865f9f7d9bcb2f93b44c63f274f08e3b6 upstream. This adds the workaround for erratum 793 as a precaution in case not every BIOS implements it. This addresses CVE-2013-6885. Erratum text: [Revision Guide for AMD Family 16h Models 00h-0Fh Processors, document 51810 Rev. 3.04 November 2013] 793 Specific Combination of Writes to Write Combined Memory Types and Locked Instructions May Cause Core Hang Description Under a highly specific and detailed set of internal timing conditions, a locked instruction may trigger a timing sequence whereby the write to a write combined memory type is not flushed, causing the locked instruction to stall indefinitely. Potential Effect on System Processor core hang. Suggested Workaround BIOS should set MSR C001_1020[15] = 1b. Fix Planned No fix planned [ hpa: updated description, fixed typo in MSR name ] Signed-off-by: Borislav Petkov Link: http://lkml.kernel.org/r/20140114230711.GS29865@pd.tnic Tested-by: Aravind Gopalakrishnan Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 04c12b6842995e685eee6570c9615e7702e09c78 Author: Paul Mackerras Date: Sat Jan 18 21:14:47 2014 +1100 powerpc: Make sure "cache" directory is removed when offlining cpu commit 91b973f90c1220d71923e7efe1e61f5329806380 upstream. The code in remove_cache_dir() is supposed to remove the "cache" subdirectory from the sysfs directory for a CPU when that CPU is being offlined. It tries to do this by calling kobject_put() on the kobject for the subdirectory. However, the subdirectory only gets removed once the last reference goes away, and the reference being put here may well not be the last reference. That means that the "cache" subdirectory may still exist when the offlining operation has finished. If the same CPU subsequently gets onlined, the code tries to add a new "cache" subdirectory. If the old subdirectory has not yet been removed, we get a WARN_ON in the sysfs code, with stack trace, and an error message printed on the console. Further, we ultimately end up with an online cpu with no "cache" subdirectory. This fixes it by doing an explicit kobject_del() at the point where we want the subdirectory to go away. kobject_del() removes the sysfs directory even though the object still exists in memory. The object will get freed at some point in the future. A subsequent onlining operation can create a new sysfs directory, even if the old object still exists in memory, without causing any problems. Signed-off-by: Paul Mackerras Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit df8042baf0473019037c5221c942087afb089df4 Author: Srivatsa S. Bhat Date: Mon Dec 30 17:05:34 2013 +0530 powerpc: Fix the setup of CPU-to-Node mappings during CPU online commit d4edc5b6c480a0917e61d93d55531d7efa6230be upstream. On POWER platforms, the hypervisor can notify the guest kernel about dynamic changes in the cpu-numa associativity (VPHN topology update). Hence the cpu-to-node mappings that we got from the firmware during boot, may no longer be valid after such updates. This is handled using the arch_update_cpu_topology() hook in the scheduler, and the sched-domains are rebuilt according to the new mappings. But unfortunately, at the moment, CPU hotplug ignores these updated mappings and instead queries the firmware for the cpu-to-numa relationships and uses them during CPU online. So the kernel can end up assigning wrong NUMA nodes to CPUs during subsequent CPU hotplug online operations (after booting). Further, a particularly problematic scenario can result from this bug: On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8) threads per core. The switch to Single-Threaded (ST) mode is performed by offlining all except the first CPU thread in each core. Switching back to SMT mode involves onlining those other threads back, in each core. Now consider this scenario: 1. During boot, the kernel gets the cpu-to-node mappings from the firmware and assigns the CPUs to NUMA nodes appropriately, during CPU online. 2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and communicates this update to the kernel. The kernel in turn updates its cpu-to-node associations and rebuilds its sched domains. Everything is fine so far. 3. Now, the user switches the machine from SMT to ST mode (say, by running ppc64_cpu --smt=1). This involves offlining all except 1 thread in each core. 4. The user then tries to switch back from ST to SMT mode (say, by running ppc64_cpu --smt=4), and this involves onlining those threads back. Since CPU hotplug ignores the new mappings, it queries the firmware and tries to associate the newly onlined sibling threads to the old NUMA nodes. This results in sibling threads within the same core getting associated with different NUMA nodes, which is incorrect. The scheduler's build-sched-domains code gets thoroughly confused with this and enters an infinite loop and causes soft-lockups, as explained in detail in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings). So to fix this, use the numa_cpu_lookup_table to remember the updated cpu-to-node mappings, and use them during CPU hotplug online operations. Further, we also need to ensure that all threads in a core are assigned to a common NUMA node, irrespective of whether all those threads were online during the topology update. To achieve this, we take care not to use cpu_sibling_mask() since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread() and set up the mappings manually using the 'threads_per_core' value for that particular platform. This helps us ensure that we don't hit this bug with any combination of CPU hotplug and SMT mode switching. Signed-off-by: Srivatsa S. Bhat Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit f0cea52a481c749ac0ed4cf0fd8a00f90306ebd5 Author: David Sterba Date: Wed Jan 15 18:15:52 2014 +0100 btrfs: restrict snapshotting to own subvolumes commit d024206133ce21936b3d5780359afc00247655b7 upstream. Currently, any user can snapshot any subvolume if the path is accessible and thus indirectly create and keep files he does not own under his direcotries. This is not possible with traditional directories. In security context, a user can snapshot root filesystem and pin any potentially buggy binaries, even if the updates are applied. All the snapshots are visible to the administrator, so it's possible to verify if there are suspicious snapshots. Another more practical problem is that any user can pin the space used by eg. root and cause ENOSPC. Original report: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/484786 Signed-off-by: David Sterba Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 5c61a3d3ff81ddb53006bbc84aca8363b4f2841b Author: Wang Shilong Date: Tue Jan 7 17:26:58 2014 +0800 Btrfs: handle EAGAIN case properly in btrfs_drop_snapshot() commit 90515e7f5d7d24cbb2a4038a3f1b5cfa2921aa17 upstream. We may return early in btrfs_drop_snapshot(), we shouldn't call btrfs_std_err() for this case, fix it. Signed-off-by: Wang Shilong Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 85c3c54bf969f0fd9ba59ee3f6e9849b53428412 Author: Andy Grover Date: Fri Jan 24 16:18:54 2014 -0800 target/iscsi: Fix network portal creation race commit ee291e63293146db64668e8d65eb35c97e8324f4 upstream. When creating network portals rapidly, such as when restoring a configuration, LIO's code to reuse existing portals can return a false negative if the thread hasn't run yet and set np_thread_state to ISCSI_NP_THREAD_ACTIVE. This causes an error in the network stack when attempting to bind to the same address/port. This patch sets NP_THREAD_ACTIVE before the np is placed on g_np_list, so even if the thread hasn't run yet, iscsit_get_np will return the existing np. Also, convert np_lock -> np_mutex + hold across adding new net portal to g_np_list to prevent a race where two threads may attempt to create the same network portal, resulting in one of them failing. (nab: Add missing mutex_unlocks in iscsit_add_np failure paths) (DanC: Fix incorrect spin_unlock -> spin_unlock_bh) Signed-off-by: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 26996fcd25dda2f6d34d1888d26585cd519f6af5 Author: Asias He Date: Thu Jan 16 10:18:48 2014 +1030 virtio-scsi: Fix hotcpu_notifier use-after-free with virtscsi_freeze commit f466f75385369a181409e46da272db3de6f5c5cb upstream. vqs are freed in virtscsi_freeze but the hotcpu_notifier is not unregistered. We will have a use-after-free usage when the notifier callback is called after virtscsi_freeze. Fixes: 285e71ea6f3583a85e27cb2b9a7d8c35d4c0d558 ("virtio-scsi: reset virtqueue affinity when doing cpu hotplug") Signed-off-by: Asias He Reviewed-by: Paolo Bonzini Signed-off-by: Jason Wang Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit ed9d61e94edf066ba8a2061735899cd97292c002 Author: Vijaya Mohan Guvva Date: Wed Dec 4 05:43:58 2013 -0800 SCSI: bfa: Chinook quad port 16G FC HBA claim issue commit dcaf9aed995c2b2a49fb86bbbcfa2f92c797ab5d upstream. Bfa driver crash is observed while pushing the firmware on to chinook quad port card due to uninitialized bfi_image_ct2 access which gets initialized only for CT2 ASIC based cards after request_firmware(). For quard port chinook (CT2 ASIC based), bfi_image_ct2 is not getting initialized as there is no check for chinook PCI device ID before request_firmware and instead bfi_image_cb is initialized as it is the default case for card type check. This patch includes changes to read the right firmware for quad port chinook. Signed-off-by: Vijaya Mohan Guvva Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 6f7c6ef181ee93ba87892db997d8474a094b2695 Author: Thomas Pugliese Date: Mon Dec 9 13:40:29 2013 -0600 usb: core: get config and string descriptors for unauthorized devices commit 83e83ecb79a8225e79bc8e54e9aff3e0e27658a2 upstream. There is no need to skip querying the config and string descriptors for unauthorized WUSB devices when usb_new_device is called. It is allowed by WUSB spec. The only action that needs to be delayed until authorization time is the set config. This change allows user mode tools to see the config and string descriptors earlier in enumeration which is needed for some WUSB devices to function properly on Android systems. It also reduces the amount of divergent code paths needed for WUSB devices. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman commit 6fb6cd453c656633c2f0e32d954d3d7bba66f434 Author: Emmanuel Grumbach Date: Mon Nov 11 15:23:01 2013 +0200 iwlwifi: pcie: fix interrupt coalescing for 7260 / 3160 commit 6960a059b2c618f32fe549f13287b3d2278c09e9 upstream. We changed the timeout for the interrupt coealescing for calibration, but that wasn't effective since we changed that value back before loading the firmware. Since calibrations are notification from firmware and not Rx packets, this doesn't change anyway - the firmware will fire an interrupt straight away regardless of the interrupt coalescing value. Also, a HW issue has been discovered in 7000 devices series. The work around is to disable the new interrupt coalescing timeout feature - do this by setting bit 31 in CSR_INT_COALESCING. This has been fixed in 7265 which means that we can't rely on the device family and must have a hint in the iwl_cfg structure. Fixes: 99cd47142399 ("iwlwifi: add 7000 series device configuration") Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 2b1461bbae34fc229cb5f58e5980aa32ee09ee77 Author: Stephen Warren Date: Mon Feb 3 16:54:04 2014 -0700 ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled (This is upstream 75fae117a5db "ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled", backported to stable 3.10 through 3.12. 3.13 and later can take the original patch.) Commit 384a48d71520 "ALSA: hda: HDMI: Support codecs with fewer cvts than pins" dynamically enabled each pin widget's PIN_OUT only when the pin was actively in use. This was required on certain NVIDIA CODECs for correct operation. Specifically, if multiple pin widgets each had their mux input select the same audio converter widget and each pin widget had PIN_OUT enabled, then only one of the pin widgets would actually receive the audio, and often not the one the user wanted! However, this apparently broke some Intel systems, and commit 6169b673618b "ALSA: hda - Always turn on pins for HDMI/DP" reverted the dynamic setting of PIN_OUT. This in turn broke the afore-mentioned NVIDIA CODECs. This change supports either dynamic or static handling of PIN_OUT, selected by a flag set up during CODEC initialization. This flag is enabled for all recent NVIDIA GPUs. Reported-by: Uosis Signed-off-by: Stephen Warren Signed-off-by: Greg Kroah-Hartman commit c6a3cab88784e5d6d97ef57061b8fa75a4b67726 Author: Anssi Hannula Date: Mon Feb 3 16:54:03 2014 -0700 ALSA: hda - hdmi: introduce patch_nvhdmi() (This is a backport of *part* of upstream 611885bc963a "ALSA: hda - hdmi: Disallow unsupported 2ch remapping on NVIDIA codecs" to stable 3.10 through 3.12. Later stable already contain all of the original patch.) Mainline commit 611885bc963a "ALSA: hda - hdmi: Disallow unsupported 2ch remapping on NVIDIA codecs" introduces function patch_nvhdmi(). That function is edited by 75fae117a5db "ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled". In order to backport the PIN_OUT patch, I am first back-porting just the addition of function patch_nvhdmi(), so that the conflicts applying the PIN_OUT patch are simplified. Ideally, one might backport all of 611885bc963a. However, that commit doesn't apply to stable kernels, since it relies on a chain of other patches which implement new features. Signed-off-by: Anssi Hannula Signed-off-by: Takashi Iwai [swarren, extracted just a small part of the original patch] Signed-off-by: Stephen Warren Signed-off-by: Greg Kroah-Hartman commit 5f03911e126049d7482e21099be250685c6038e7 Author: Mihai Caraman Date: Thu Jan 9 17:01:05 2014 +0200 KVM: PPC: e500: Fix bad address type in deliver_tlb_misss() commit 70713fe315ed14cd1bb07d1a7f33e973d136ae3d upstream. Use gva_t instead of unsigned int for eaddr in deliver_tlb_miss(). Signed-off-by: Mihai Caraman Signed-off-by: Alexander Graf Signed-off-by: Greg Kroah-Hartman commit 250be41c8d5e04dc17109f9a47be23545d17b35d Author: Andreas Schwab Date: Mon Dec 30 15:36:56 2013 +0100 KVM: PPC: Book3S HV: use xics_wake_cpu only when defined commit 48eaef0518a565d3852e301c860e1af6a6db5a84 upstream. Signed-off-by: Andreas Schwab Signed-off-by: Alexander Graf Signed-off-by: Greg Kroah-Hartman commit 64a0099626b2ab6403433ef25e458c4d553a81a1 Author: Helge Deller Date: Fri Jan 31 21:33:17 2014 +0100 parisc: fix cache-flushing commit 57737c49dd72c96cfbcd4f66559f3ffc399aeb4f upstream. This commit: f8dae00684d678afa13041ef170cecfd1297ed40: parisc: Ensure full cache coherency for kmap/kunmap caused negative caching side-effects, e.g. hanging processes with expect and too many inequivalent alias messages from flush_dcache_page() on Debian 5 systems. This patch now partly reverts it and has been in production use on our debian buildd makeservers since a week without any major problems. Signed-off-by: Helge Deller Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 50920a1dd85602169df04e38248fa582d523c039 Author: Emmanuel Grumbach Date: Tue Dec 24 14:15:41 2013 +0200 iwlwifi: pcie: enable oscillator for L1 exit commit 2d93aee152b1758a94a18fe15d72153ba73b5679 upstream. Enabling the oscillator consumes slightly more power (100uA) but allows to make sure that we exit from L1 on time. Not doing so might lead to a PCIe specification violation since we might wake up from L1 at the wrong time. This issue has been identified on 3160 and 7260 only. On older NICs L1 off is not enabled, on newer NICs (7265), the issue is fixed. When the bug occurs the user sees that the NIC has disappeared from the PCI bridge, any access to the device returns 0xff. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=64541 and has been extensively discussed here: http://markmail.org/thread/mfmpzqt3r333n4bo Fixes: 99cd47142399 ("iwlwifi: add 7000 series device configuration") Reported-and-tested-by: wzyboy Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 38c963f2676af60291566a1ae470b09d293adccd Author: Nicolas Dichtel Date: Fri Jan 31 09:24:06 2014 +0100 ip6tnl: fix double free of fb_tnl_dev on exit [ No relevant upstream commit. ] This problem was fixed upstream by commit 1e9f3d6f1c40 ("ip6tnl: fix use after free of fb_tnl_dev"). The upstream patch depends on upstream commit 0bd8762824e7 ("ip6tnl: add x-netns support"), which was not backported into 3.10 branch. First, explain the problem: when the ip6_tunnel module is unloaded, ip6_tunnel_cleanup() is called. rmmod ip6_tunnel => ip6_tunnel_cleanup() => rtnl_link_unregister() => __rtnl_kill_links() => for_each_netdev(net, dev) { if (dev->rtnl_link_ops == ops) ops->dellink(dev, &list_kill); } At this point, the FB device is deleted (and all ip6tnl tunnels). => unregister_pernet_device() => unregister_pernet_operations() => ops_exit_list() => ip6_tnl_exit_net() => ip6_tnl_destroy_tunnels() => t = rtnl_dereference(ip6n->tnls_wc[0]); unregister_netdevice_queue(t->dev, &list); We delete the FB device a second time here! The previous fix removes these lines, which fix this double free. But the patch introduces a memory leak when a netns is destroyed, because the FB device is never deleted. By adding an rtnl ops which delete all ip6tnl device excepting the FB device, we can keep this exlicit removal in ip6_tnl_destroy_tunnels(). CC: Steven Rostedt CC: Willem de Bruijn Signed-off-by: Nicolas Dichtel Reported-by: Steven Rostedt Tested-by: Steven Rostedt (and our entire MRG team) Tested-by: "Luis Claudio R. Goncalves" Tested-by: John Kacur Signed-off-by: Greg Kroah-Hartman commit 89ed31c6efdd50164b7731296d0a14649e1df79c Author: Nicolas Dichtel Date: Fri Jan 31 09:24:05 2014 +0100 Revert "ip6tnl: fix use after free of fb_tnl_dev" [ No relevant upstream commit. ] This reverts commit 22c3ec552c29cf4bd4a75566088950fe57d860c4. This patch is not the right fix, it introduces a memory leak when a netns is destroyed (the FB device is never deleted). Signed-off-by: Nicolas Dichtel Reported-by: Steven Rostedt Tested-by: Steven Rostedt (and our entire MRG team) Tested-by: "Luis Claudio R. Goncalves" Tested-by: John Kacur Signed-off-by: Greg Kroah-Hartman commit 1b2a58ff62aa3acc7c539b325972c9b94ce89c3d Author: Nicolas Dichtel Date: Fri Jan 31 09:24:04 2014 +0100 sit: fix double free of fb_tunnel_dev on exit [ No relevant upstream commit. ] This problem was fixed upstream by commit 9434266f2c64 ("sit: fix use after free of fb_tunnel_dev"). The upstream patch depends on upstream commit 5e6700b3bf98 ("sit: add support of x-netns"), which was not backported into 3.10 branch. First, explain the problem: when the sit module is unloaded, sit_cleanup() is called. rmmod sit => sit_cleanup() => rtnl_link_unregister() => __rtnl_kill_links() => for_each_netdev(net, dev) { if (dev->rtnl_link_ops == ops) ops->dellink(dev, &list_kill); } At this point, the FB device is deleted (and all sit tunnels). => unregister_pernet_device() => unregister_pernet_operations() => ops_exit_list() => sit_exit_net() => sit_destroy_tunnels() In this function, no tunnel is found. => unregister_netdevice_queue(sitn->fb_tunnel_dev, &list); We delete the FB device a second time here! Because we cannot simply remove the second deletion (sit_exit_net() must remove the FB device when a netns is deleted), we add an rtnl ops which delete all sit device excepting the FB device and thus we can keep the explicit deletion in sit_exit_net(). CC: Steven Rostedt Signed-off-by: Nicolas Dichtel Acked-by: Willem de Bruijn Reported-by: Steven Rostedt Tested-by: Steven Rostedt (and our entire MRG team) Tested-by: "Luis Claudio R. Goncalves" Tested-by: John Kacur Signed-off-by: Greg Kroah-Hartman commit 64cee83a9856e8fa4cb6616a072469d5eba3c1d7 Author: Annie Li Date: Tue Jan 28 11:35:42 2014 +0800 xen-netfront: fix resource leak in netfront [ Upstream commit cefe0078eea52af17411eb1248946a94afb84ca5 ] This patch removes grant transfer releasing code from netfront, and uses gnttab_end_foreign_access to end grant access since gnttab_end_foreign_access_ref may fail when the grant entry is currently used for reading or writing. * clean up grant transfer code kept from old netfront(2.6.18) which grants pages for access/map and transfer. But grant transfer is deprecated in current netfront, so remove corresponding release code for transfer. * fix resource leak, release grant access (through gnttab_end_foreign_access) and skb for tx/rx path, use get_page to ensure page is released when grant access is completed successfully. Xen-blkfront/xen-tpmfront/xen-pcifront also have similar issue, but patches for them will be created separately. V6: Correct subject line and commit message. V5: Remove unecessary change in xennet_end_access. V4: Revert put_page in gnttab_end_foreign_access, and keep netfront change in single patch. V3: Changes as suggestion from David Vrabel, ensure pages are not freed untill grant acess is ended. V2: Improve patch comments. Signed-off-by: Annie Li Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 873c4941de470ec803d409150df3d9d4b705f578 Author: Holger Eitzenberger Date: Mon Jan 27 10:33:18 2014 +0100 net: Fix memory leak if TPROXY used with TCP early demux [ Upstream commit a452ce345d63ddf92cd101e4196569f8718ad319 ] I see a memory leak when using a transparent HTTP proxy using TPROXY together with TCP early demux and Kernel v3.8.13.15 (Ubuntu stable): unreferenced object 0xffff88008cba4a40 (size 1696): comm "softirq", pid 0, jiffies 4294944115 (age 8907.520s) hex dump (first 32 bytes): 0a e0 20 6a 40 04 1b 37 92 be 32 e2 e8 b4 00 00 .. j@..7..2..... 02 00 07 01 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmem_cache_alloc+0xad/0xb9 [] sk_prot_alloc+0x29/0xc5 [] sk_clone_lock+0x14/0x283 [] inet_csk_clone_lock+0xf/0x7b [] netlink_broadcast+0x14/0x16 [] tcp_create_openreq_child+0x1b/0x4c3 [] tcp_v4_syn_recv_sock+0x38/0x25d [] tcp_check_req+0x25c/0x3d0 [] tcp_v4_do_rcv+0x287/0x40e [] ip_route_input_noref+0x843/0xa55 [] tcp_v4_rcv+0x4c9/0x725 [] ip_local_deliver_finish+0xe9/0x154 [] __netif_receive_skb+0x4b2/0x514 [] process_backlog+0xee/0x1c5 [] net_rx_action+0xa7/0x200 [] add_interrupt_randomness+0x39/0x157 But there are many more, resulting in the machine going OOM after some days. From looking at the TPROXY code, and with help from Florian, I see that the memory leak is introduced in tcp_v4_early_demux(): void tcp_v4_early_demux(struct sk_buff *skb) { /* ... */ iph = ip_hdr(skb); th = tcp_hdr(skb); if (th->doff < sizeof(struct tcphdr) / 4) return; sk = __inet_lookup_established(dev_net(skb->dev), &tcp_hashinfo, iph->saddr, th->source, iph->daddr, ntohs(th->dest), skb->skb_iif); if (sk) { skb->sk = sk; where the socket is assigned unconditionally to skb->sk, also bumping the refcnt on it. This is problematic, because in our case the skb has already a socket assigned in the TPROXY target. This then results in the leak I see. The very same issue seems to be with IPv6, but haven't tested. Reviewed-by: Florian Westphal Signed-off-by: Holger Eitzenberger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7dd52e5dcb524d6c4790a415e4d1f47e5bf01616 Author: Oliver Hartkopp Date: Thu Jan 23 10:19:34 2014 +0100 fib_frontend: fix possible NULL pointer dereference [ Upstream commit a0065f266a9b5d51575535a25c15ccbeed9a9966 ] The two commits 0115e8e30d (net: remove delay at device dismantle) and 748e2d9396a (net: reinstate rtnl in call_netdevice_notifiers()) silently removed a NULL pointer check for in_dev since Linux 3.7. This patch re-introduces this check as it causes crashing the kernel when setting small mtu values on non-ip capable netdevices. Signed-off-by: Oliver Hartkopp Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b5ac52437d8e34ea8032cfa77d6e6aa4b161aeb5 Author: Duan Jiong Date: Thu Jan 23 14:00:25 2014 +0800 ip_tunnel: clear IPCB in ip_tunnel_xmit() in case dst_link_failure() is called [ Upstream commit 11c21a307d79ea5f6b6fc0d3dfdeda271e5e65f6 ] commit a622260254ee48("ip_tunnel: fix kernel panic with icmp_dest_unreach") clear IPCB in ip_tunnel_xmit() , or else skb->cb[] may contain garbage from GSO segmentation layer. But commit 0e6fbc5b6c621("ip_tunnels: extend iptunnel_xmit()") refactor codes, and it clear IPCB behind the dst_link_failure(). So clear IPCB in ip_tunnel_xmit() just like commti a622260254ee48("ip_tunnel: fix kernel panic with icmp_dest_unreach"). Signed-off-by: Duan Jiong Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f93f502e2d6a6acb36fbac0236e6088318c6d757 Author: Heiko Carstens Date: Fri Jan 17 09:37:15 2014 +0100 s390/bpf,jit: fix 32 bit divisions, use unsigned divide instructions [ Upstream commit 3af57f78c38131b7a66e2b01e06fdacae01992a3 ] The s390 bpf jit compiler emits the signed divide instructions "dr" and "d" for unsigned divisions. This can cause problems: the dividend will be zero extended to a 64 bit value and the divisor is the 32 bit signed value as specified A or X accumulator, even though A and X are supposed to be treated as unsigned values. The divide instrunctions will generate an exception if the result cannot be expressed with a 32 bit signed value. This is the case if e.g. the dividend is 0xffffffff and the divisor either 1 or also 0xffffffff (signed: -1). To avoid all these issues simply use unsigned divide instructions. Signed-off-by: Heiko Carstens Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cd7361dc9fa60c35d011d674d48eababcc3eb767 Author: Eric Dumazet Date: Wed Jan 15 06:50:07 2014 -0800 bpf: do not use reciprocal divide [ Upstream commit aee636c4809fa54848ff07a899b326eb1f9987a2 ] At first Jakub Zawadzki noticed that some divisions by reciprocal_divide were not correct. (off by one in some cases) http://www.wireshark.org/~darkjames/reciprocal-buggy.c He could also show this with BPF: http://www.wireshark.org/~darkjames/set-and-dump-filter-k-bug.c The reciprocal divide in linux kernel is not generic enough, lets remove its use in BPF, as it is not worth the pain with current cpus. Signed-off-by: Eric Dumazet Reported-by: Jakub Zawadzki Cc: Mircea Gherzan Cc: Daniel Borkmann Cc: Hannes Frederic Sowa Cc: Matt Evans Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: David S. Miller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8c035b62e21a2d26c1a5181ee0d27a76c8996be8 Author: Christoph Paasch Date: Thu Jan 16 20:01:21 2014 +0100 tcp: metrics: Avoid duplicate entries with the same destination-IP [ Upstream commit 77f99ad16a07aa062c2d30fae57b1fee456f6ef6 ] Because the tcp-metrics is an RCU-list, it may be that two soft-interrupts are inside __tcp_get_metrics() for the same destination-IP at the same time. If this destination-IP is not yet part of the tcp-metrics, both soft-interrupts will end up in tcpm_new and create a new entry for this IP. So, we will have two tcp-metrics with the same destination-IP in the list. This patch checks twice __tcp_get_metrics(). First without holding the lock, then while holding the lock. The second one is there to confirm that the entry has not been added by another soft-irq while waiting for the spin-lock. Fixes: 51c5d0c4b169b (tcp: Maintain dynamic metrics in local cache.) Signed-off-by: Christoph Paasch Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 55157010c2f4a1a92b3e275843d8f847ac89b8d9 Author: Gerald Schaefer Date: Thu Jan 16 16:54:48 2014 +0100 net: rds: fix per-cpu helper usage [ Upstream commit c196403b79aa241c3fefb3ee5bb328aa7c5cc860 ] commit ae4b46e9d "net: rds: use this_cpu_* per-cpu helper" broke per-cpu handling for rds. chpfirst is the result of __this_cpu_read(), so it is an absolute pointer and not __percpu. Therefore, __this_cpu_write() should not operate on chpfirst, but rather on cache->percpu->first, just like __this_cpu_read() did before. Signed-off-byd Gerald Schaefer Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 45a7ed6dd0ededc3c384394fe7ccec6a06142dea Author: Richard Weinberger Date: Tue Jan 14 22:46:36 2014 +0100 net,via-rhine: Fix tx_timeout handling [ Upstream commit a926592f5e4e900f3fa903298c4619a131e60963 ] rhine_reset_task() misses to disable the tx scheduler upon reset, this can lead to a crash if work is still scheduled while we're resetting the tx queue. Fixes: [ 93.591707] BUG: unable to handle kernel NULL pointer dereference at 0000004c [ 93.595514] IP: [] rhine_napipoll+0x491/0x6 Signed-off-by: Richard Weinberger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d6489021c45ffb83bdb9d2082e5e871e4474beb5 Author: Hannes Frederic Sowa Date: Mon Jan 13 02:45:22 2014 +0100 net: avoid reference counter overflows on fib_rules in multicast forwarding [ Upstream commit 95f4a45de1a0f172b35451fc52283290adb21f6e ] Bob Falken reported that after 4G packets, multicast forwarding stopped working. This was because of a rule reference counter overflow which freed the rule as soon as the overflow happend. This patch solves this by adding the FIB_LOOKUP_NOREF flag to fib_rules_lookup calls. This is safe even from non-rcu locked sections as in this case the flag only implies not taking a reference to the rule, which we don't need at all. Rules only hold references to the namespace, which are guaranteed to be available during the call of the non-rcu protected function reg_vif_xmit because of the interface reference which itself holds a reference to the net namespace. Fixes: f0ad0860d01e47 ("ipv4: ipmr: support multiple tables") Fixes: d1db275dd3f6e4 ("ipv6: ip6mr: support multiple tables") Reported-by: Bob Falken Cc: Patrick McHardy Cc: Thomas Graf Cc: Julian Anastasov Cc: Eric Dumazet Signed-off-by: Hannes Frederic Sowa Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9ccbe0de27de9d387f480d7b721140aee68b25c4 Author: Christian Engelmayer Date: Sat Jan 11 22:19:30 2014 +0100 ieee802154: Fix memory leak in ieee802154_add_iface() [ Upstream commit 267d29a69c6af39445f36102a832b25ed483f299 ] Fix a memory leak in the ieee802154_add_iface() error handling path. Detected by Coverity: CID 710490. Signed-off-by: Christian Engelmayer Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 72abb47c577499379a83a2f065d282936b4464f4 Author: Neal Cardwell Date: Sun Feb 2 20:40:13 2014 -0500 inet_diag: fix inet_diag_dump_icsk() timewait socket state logic [ Based upon upstream commit 70315d22d3c7383f9a508d0aab21e2eb35b2303a ] Fix inet_diag_dump_icsk() to reflect the fact that both TIME_WAIT and FIN_WAIT2 connections are represented by inet_timewait_sock (not just TIME_WAIT). Thus: (a) We need to iterate through the time_wait buckets if the user wants either TIME_WAIT or FIN_WAIT2. (Before fixing this, "ss -nemoi state fin-wait-2" would not return any sockets, even if there were some in FIN_WAIT2.) (b) We need to check tw_substate to see if the user wants to dump sockets in the particular substate (TIME_WAIT or FIN_WAIT2) that a given connection is in. (Before fixing this, "ss -nemoi state time-wait" would actually return sockets in state FIN_WAIT2.) An analogous fix is in v3.13: 70315d22d3c7383f9a508d0aab21e2eb35b2303a ("inet_diag: fix inet_diag_dump_icsk() to use correct state for timewait sockets") but that patch is quite different because 3.13 code is very different in this area due to the unification of TCP hash tables in 05dbc7b ("tcp/dccp: remove twchain") in v3.13-rc1. I tested that this applies cleanly between v3.3 and v3.12, and tested that it works in both 3.3 and 3.12. It does not apply cleanly to 3.2 and earlier (though it makes semantic sense), and semantically is not the right fix for 3.13 and beyond (as mentioned above). Signed-off-by: Neal Cardwell Cc: Eric Dumazet Acked-by: Eric Dumazet Signed-off-by: Greg Kroah-Hartman commit 4369fa25d4499e63368b39523698d936b75f65fd Author: Michal Schmidt Date: Thu Jan 9 14:36:27 2014 +0100 bnx2x: fix DMA unmapping of TSO split BDs [ Upstream commit 95e92fd40c967c363ad66b2fd1ce4dcd68132e54 ] bnx2x triggers warnings with CONFIG_DMA_API_DEBUG=y: WARNING: CPU: 0 PID: 2253 at lib/dma-debug.c:887 check_unmap+0xf8/0x920() bnx2x 0000:28:00.0: DMA-API: device driver frees DMA memory with different size [device address=0x00000000da2b389e] [map size=1490 bytes] [unmap size=66 bytes] The reason is that bnx2x splits a TSO BD into two BDs (headers + data) using one DMA mapping for both, but it uses only the length of the first BD when unmapping. This patch fixes the bug by unmapping the whole length of the two BDs. Signed-off-by: Michal Schmidt Reviewed-by: Eric Dumazet Acked-by: Dmitry Kravkov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 759ebfb44b87339bb43c2674b7ab9816ffc37b7a Author: Takashi Iwai Date: Mon Jan 13 12:32:44 2014 +0100 hp_accel: Add a new PnP ID HPQ6007 for new HP laptops commit b0ad4ff35d479a46a3b995a299db9aeb097acfce upstream. The DriveGuard chips on the new HP laptops are with a new PnP ID "HPQ6007". It should be compatible with older chips. Acked-by: Éric Piel Signed-off-by: Takashi Iwai Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit f4ac67e8e7fa1c9148823da09e913e8e44a8f52b Author: Kent Overstreet Date: Tue Dec 17 17:51:02 2013 -0800 bcache: Data corruption fix commit ef71ec00002d92a08eb27e9d036e3d48835b6597 upstream. The code that handles overlapping extents that we've just read back in from disk was depending on the behaviour of the code that handles overlapping extents as we're inserting into a btree node in the case of an insert that forced an existing extent to be split: on insert, if we had to split we'd also insert a new extent to represent the top part of the old extent - and then that new extent would get written out. The code that read the extents back in thus not bother with splitting extents - if it saw an extent that ovelapped in the middle of an older extent, it would trim the old extent to only represent the bottom part, assuming that the original insert would've inserted a new extent to represent the top part. I still haven't figured out _how_ it can happen, but I'm now pretty convinced (and testing has confirmed) that there's some kind of an obscure corner case (probably involving extent merging, and multiple overwrites in different sets) that breaks this. The fix is to change the mergesort fixup code to split extents itself when required. Signed-off-by: Kent Overstreet Signed-off-by: Greg Kroah-Hartman commit 9a8bd082503f4f91176d8fe0b91a23c5b768008e Author: Eric W. Biederman Date: Mon Jan 20 15:26:15 2014 -0800 vfs: Is mounted should be testing mnt_ns for NULL or error. commit 260a459d2e39761fbd39803497205ce1690bc7b1 upstream. A bug was introduced with the is_mounted helper function in commit f7a99c5b7c8bd3d3f533c8b38274e33f3da9096e Author: Al Viro Date: Sat Jun 9 00:59:08 2012 -0400 get rid of ->mnt_longterm it's enough to set ->mnt_ns of internal vfsmounts to something distinct from all struct mnt_namespace out there; then we can just use the check for ->mnt_ns != NULL in the fast path of mntput_no_expire() Signed-off-by: Al Viro The intent was to test if the real_mount(vfsmount)->mnt_ns was NULL_OR_ERR but the code is actually testing real_mount(vfsmount) and always returning true. The result is d_absolute_path returning paths it should be hiding. Signed-off-by: "Eric W. Biederman" Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 209bd086e423d98ddf2fd52a6f1afda15b5758b1 Author: Theodore Ts'o Date: Tue Jan 7 12:58:19 2014 -0500 ext4: avoid clearing beyond i_blocks when truncating an inline data file commit 09c455aaa8f47a94d5bafaa23d58365768210507 upstream. A missing cast means that when we are truncating a file which is less than 60 bytes, we don't clear the correct area of memory, and in fact we can end up truncating the next inode in the inode table, or worse yet, some other kernel data structure. Addresses-Coverity-Id: #751987 Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit f07b772da47ad954573b1ffe6ebd4df1b59bf656 Author: Tejun Heo Date: Thu Jan 16 09:47:17 2014 -0500 libata: disable LPM for some WD SATA-I devices commit ecd75ad514d73efc1bbcc5f10a13566c3ace5f53 upstream. For some reason, some early WD drives spin up and down drives erratically when the link is put into slumber mode which can reduce the life expectancy of the device significantly. Unfortunately, we don't have full list of devices and given the nature of the issue it'd be better to err on the side of false positives than the other way around. Let's disable LPM on all WD devices which match one of the known problematic model prefixes and are SATA-I. As horkage list doesn't support matching SATA capabilities, this is implemented as two horkages - WD_BROKEN_LPM and NOLPM. The former is set for the known prefixes and sets the latter if the matched device is SATA-I. Note that this isn't optimal as this disables all LPM operations and partial link power state reportedly works fine on these; however, the way LPM is implemented in libata makes it difficult to precisely map libata LPM setting to specific link power state. Well, these devices are already fairly outdated. Let's just disable whole LPM for now. Signed-off-by: Tejun Heo Reported-and-tested-by: Nikos Barkas Reported-and-tested-by: Ioannis Barkas References: https://bugzilla.kernel.org/show_bug.cgi?id=57211 Signed-off-by: Greg Kroah-Hartman commit 6314611aeb6fab9ea75df60f6e0145cf8b07aa98 Author: Lior Amsalem Date: Tue Jan 14 20:09:57 2014 +0100 ata: sata_mv: fix disk hotplug for Armada 370/XP SoCs commit 9013d64e661fc2a37a1742670202171c27fef4b5 upstream. On Armada 370/XP SoCs, once a disk is removed from a SATA port, then the re-plug events are not detected by the sata_mv driver. This patch fixes the issue by updating the PHY speed in the LP_PHY_CTL register (0x58) according to the SControl speed. Note that this fix is only applied if the compatible string "marvell,armada-370-sata" is found in the SATA DT node. Fixes: 9ae6f740b49f ("arm: mach-mvebu: add support for Armada 370 and Armada XP with DT") Signed-off-by: Lior Amsalem Signed-off-by: Nadav Haklai Signed-off-by: Simon Guinot Cc: Thomas Petazzoni Cc: Jason Cooper Cc: Andrew Lunn Cc: Gregory Clement Cc: Sebastian Hesselbarth Acked-by: Jason Cooper Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 509e5695265037de4c7aefcf2c9c1db99babab8b Author: Simon Guinot Date: Tue Jan 14 20:04:39 2014 +0100 ata: sata_mv: introduce compatible string "marvell, armada-370-sata" commit b1f5c73bd5a4752efb7d7af019034044b08aafe9 upstream. The sata_mv driver supports the SATA IP found in several Marvell SoCs. As some new SATA registers have been introduced with the Armada 370/XP SoCs, a way to identify them is needed. This patch introduces a new compatible string for the SATA IP found in Armada 370/XP SoCs. Signed-off-by: Simon Guinot Cc: Thomas Petazzoni Cc: Jason Cooper Cc: Andrew Lunn Cc: Gregory Clement Cc: Sebastian Hesselbarth Cc: Lior Amsalem Acked-by: Jason Cooper Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 2e59688b755c3ad72103b909eeaea388a7cdab0b Author: Peter Huewe Date: Wed Oct 30 20:46:55 2013 +0100 tpm/tpm_ppi: Do not compare strcmp(a,b) == -1 commit 747d35bd9bb4ae6bd74b19baa5bbe32f3e0cee11 upstream. Depending on the implementation strcmp might return the difference between two strings not only -1,0,1 consequently if (strcmp (a,b) == -1) might lead to taking the wrong branch -> compare with < 0 instead, which in any case is more canonical. Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit 9bf4d6c3c302830f7d7ffec5f6f12948e2f53c9a Author: Peter Huewe Date: Wed Oct 30 00:54:20 2013 +0100 tpm/tpm_i2c_stm_st33: Check return code of get_burstcount commit 85c5e0d451125c6ddb78663972e40af810b83644 upstream. The 'get_burstcount' function can in some circumstances 'return -EBUSY' which in tpm_stm_i2c_send is stored in an 'u32 burstcnt' thus converting the signed value into an unsigned value, resulting in 'burstcnt' being huge. Changing the type to u32 only does not solve the problem as the signed value is converted to an unsigned in I2C_WRITE_DATA, resulting in the same effect. Thus -> Change type of burstcnt to u32 (the return type of get_burstcount) -> Add a check for the return value of 'get_burstcount' and propagate a potential error. This makes also sense in the 'I2C_READ_DATA' case, where the there is no signed/unsigned conversion. found by coverity Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit 3cf79a3cd9edc63a419ce3134ddc5b39575b0cdb Author: Adrien Vergé Date: Fri Jan 24 14:56:14 2014 -0500 ALSA: hda - Fix silent output on MacBook Air 1,1 commit e7729a415315fcd9516912050d85d5aaebcededc upstream. Similarly to other Apple products, MBA 1,1 needs a specific quirk. Pin 0x18 must be set to VREF_50 to have sound output. This was no longer done since commit 1a97b7f, resulting in a mute built-in speaker. This patch corrects the regression by creating a fixup for the MBA 1,1. Fixes: 1a97b7f22774 ("ALSA: hda/realtek - Remove the last static quirks for ALC882") Tested-by: Adrien Vergé Signed-off-by: Adrien Vergé Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6d6c9853a8484a22c3aaada5664b15afae1f31cd Author: Takashi Iwai Date: Fri Jan 10 14:20:42 2014 +0100 ALSA: Enable CONFIG_ZONE_DMA for smaller PCI DMA masks commit 80ab8eae70e51d578ebbeb228e0f7a562471b8b7 upstream. The PCI devices with DMA masks smaller than 32bit should enable CONFIG_ZONE_DMA. Since the recent change of page allocator, page allocations via dma_alloc_coherent() with the limited DMA mask bits may fail more frequently, ended up with no available buffers, when CONFIG_ZONE_DMA isn't enabled. With CONFIG_ZONE_DMA, the system has much more chance to obtain such pages. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68221 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ebd58143b76236f0c4613fc0440858a52c6d8cdf Author: Takashi Iwai Date: Tue Jan 7 18:11:44 2014 +0100 ALSA: hda - Don't create duplicated ctls for loopback paths commit 43a8e50a46a4e1dd1451e4a4ffa1f7695fb7d287 upstream. AD1986A mic pins (0x1d and 0x1f) share the same widget for controlling the loopback volume/mute, but the generic parser didn't check it. This ended up with the duplicated controls for the same effect. This patch adds the check of the duplication for avoiding it. After this fix, there will be only one control although it affects both paths; this remaining issue should be fixed later in a different patch. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ee0ba9535137239ed7a25964a075ed6b9bcad719 Author: Takashi Iwai Date: Fri Dec 27 00:13:08 2013 +0200 ALSA: rme9652: fix a missing comma in channel_map_9636_ds[] commit 770bd4bf2e664939a9dacd3d26ec9ff7a3933210 upstream. The lack of comma leads to the wrong channel for an SPDIF channel. Unfortunately this wasn't caught by compiler because it's still a valid expression. Reported-by: Alexander Aristov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 24489565e2a3400de95a269f451a79b577222f1a Author: Charles Keepax Date: Tue Jan 21 16:27:51 2014 +0000 ASoC: wm5110: Extend SYSCLK patch file for rev D commit 34354792432b6e0a3b156819a1a19716c50d3473 upstream. Latest evaluation of the the device has given some patch file additions for improved performance. Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3dfcba3dd17b4f794821caf4cd135fb30e593307 Author: Lars-Peter Clausen Date: Wed Jan 8 11:22:25 2014 +0100 ASoC: adau1701: Fix ADAU1701_SEROCTL_WORD_LEN_16 constant commit e20970ada3f699c113fe64b04492af083d11a7d8 upstream. The driver defines ADAU1701_SEROCTL_WORD_LEN_16 as 0x10 while it should be b10, so 0x2. This patch fixes it. Reported-by: Magnus Reftel Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 33e2b2c73e78379dbb2db135c490ca8ca76bfd58 Author: Krzysztof Kozlowski Date: Fri Dec 20 10:35:07 2013 +0100 mfd: max77686: Fix regmap resource leak on driver remove commit 74142ffc0b52cfe6f9d2f6f34a5f3eedbfe3ce51 upstream. The regmap used by max77686 MFD driver was not freed with regmap_exit() on driver exit. This lead to leak of resources. Replace regmap_init_i2c() call in driver probe with initialization of managed register map so the regmap will be properly freed by the device management code. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 6157969f1536f6ff772c9c3719befbb7d46261b9 Author: Dongsheng Yang Date: Fri Dec 20 13:41:47 2013 -0500 perf kvm: Fix kvm report without guestmount. commit ad85ace07a05062ef6b59c35a5e80b6eaee1eee6 upstream. Currently, if we use perf kvm --guestkallsyms --guestmodules report, we can not get the perf information from perf data file. All sample are shown as unknown. Reproducing steps: # perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules record -a sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.624 MB perf.data.guest (~27260 samples) ] # perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules report |grep % 100.00% [guest/6471] [unknown] [g] 0xffffffff8164f330 This bug was introduced by 207b57926 (perf kvm: Fix regression with guest machine creation). In original code, it uses perf_session__find_machine(), it means we deliver symbol to machine which has the same pid, if no machine found, deliver it to *default* guest. But if we use perf_session__findnew_machine() here, if no machine was found, new machine with pid will be built and added. Then the default guest which with pid == 0 will never get a symbol. And because the new machine initialized here has no kernel map created, the symbol delivered to it will be marked as "unknown". This patch here is to revert commit 207b57926 and fix the SEGFAULT bug in another way. Verification steps: # ./perf kvm --guestkallsyms /home/kallsyms --guestmodules /home/modules record -a sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.651 MB perf.data.guest (~28437 samples) ] # ./perf kvm --guestkallsyms /home/kallsyms --guestmodules /home/modules report |grep % 22.64% :6471 [guest.kernel.kallsyms] [g] update_rq_clock.part.70 19.99% :6471 [guest.kernel.kallsyms] [g] d_free 18.46% :6471 [guest.kernel.kallsyms] [g] bio_phys_segments 16.25% :6471 [guest.kernel.kallsyms] [g] dequeue_task 12.78% :6471 [guest.kernel.kallsyms] [g] __switch_to 7.91% :6471 [guest.kernel.kallsyms] [g] scheduler_tick 1.75% :6471 [guest.kernel.kallsyms] [g] native_apic_mem_write 0.21% :6471 [guest.kernel.kallsyms] [g] apic_timer_interrupt Signed-off-by: Dongsheng Yang Acked-by: David Ahern Cc: David Ahern Link: http://lkml.kernel.org/r/1387564907-3045-1-git-send-email-yangds.fnst@cn.fujitsu.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 215c54fe95ceadac56295019895688dd18f3d120 Author: Chen-Yu Tsai Date: Thu Jan 16 14:34:23 2014 +0800 pinctrl: sunxi: Honor GPIO output initial vaules commit fa8cf57c923e86a693a85aff1df579245a27cbb3 upstream. Some GPIO users, such as fixed-regulator, request GPIO output with initial value of 1. This was ignored by sunxi driver. Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 0ac9f15fbe599024fa3523c3083add257f53c849 Author: Stephen Warren Date: Thu Jan 23 15:55:19 2014 -0800 rtc: max8907: weekday encoding fixes commit 75ea799df4cb07e505c91b4abaa87bc28aad3e66 upstream. The current MAX8907 driver has two issues related to weekday value handling: 1) The HW WEEKDAY register has range 0..6 rather than 1..7 as documented. Note that I validated the actual HW range by observing the HW register roll from 6->0 rather than 6->7->1 as would otherwise be expected. This matches Linux's tm_wday range of 0..6. When the CMOS RAM content is lost, the date returned from the device is 2007-01-01 00:00:00, which is a Monday. The WEEKDAY register reads 1 in this case. This matches the numbering in Linux's tm_wday field. Hence we should write Linux's tm_wday value to the register without modifying it. Hence, remove the +1/-1 calculations for WEEKDAY/tm_wday. 2) There's no need to make alarms match on the WEEKDAY register, since the other fields together uniquely define the alarm date/time. Ignoring the WEEKDAY value in the match isolates the driver from any incorrect value in the current time copy of the WEEKDAY register. Each change individually, or both together, solves an issue that I observed; "hwclock -r" would time out waiting for its alarm to fire if the CMOS RAM content had been lost, and hence the WEEKDAY register value mismatched what the driver expected it to be. "hwclock -w" would solve this by over-writing the HW default WEEKDAY register value with what the driver expected. Signed-off-by: Stephen Warren Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d35b93d05eb82babe49fd76a68b94d803f2ed19a Author: Sebastian Andrzej Siewior Date: Wed Nov 27 17:43:43 2013 +0100 parport: parport_pc: remove double PCI ID for NetMos commit d6a484520c5572a4170fa915109ccfc0c38f5008 upstream. In commit 85747f ("PATCH] parport: add NetMOS 9805 support") Max added the PCI ID for NetMOS 9805 based on a Debian bug report from 2k4 which was at the v2.4.26 time frame. The patch made into 2.6.14. Shortly before that patch akpm merged commit 296d3c783b ("[PATCH] Support NetMOS based PCI cards providing serial and parallel ports") which made into v2.6.9-rc1. Now we have two different entries for the same PCI id. I have here the NetMos 9805 which claims to support SPP/EPP/ECP mode. This patch takes Max's entry for titan_1284p1 (base != -1 specifies the ioport for ECP mode) and replaces akpm's entry for netmos_9805 which specified -1 (=none). Both share the same PCI-ID (my card has subsystem 0x1000 / 0x0020 so it should match PCI_ANY). While here I also drop the entry for titan_1284p2 which is the same as netmos_9815. Cc: Maximilian Attems Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cca90a970d9b18e56fb53dbcec448ba2b641170c Author: Heiko Carstens Date: Tue Jan 21 17:31:10 2014 +0100 s390/uapi: fix struct statfs64 definition commit 4e078146dff728f4865270a47710d57797e81eb6 upstream. With b8668fd0a7e1b59f "s390/uapi: change struct statfs[64] member types to unsigned values" the size of a couple of struct statfs64 member got incorrectly changed from 64 to 32 bit for 32 bit builds. Fix this by changing the type of couple of struct statfs64 members from unsigned long to unsigned long long. The definition of struct compat_statfs64 was correct however. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 8a6b1708b918d20a89d0d596d016b358c6e2d6fb Author: Heiko Carstens Date: Mon Nov 11 13:56:47 2013 +0100 KVM: s390: fix diagnose code extraction commit 743db27c526e0f31cc507959d662e97e2048a86f upstream. The diagnose code to be used is the contents of the base register (if not zero), plus the displacement. The current code ignores the base register contents. So let's fix that... Reviewed-by: Cornelia Huck Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens Signed-off-by: Cornelia Huck Signed-off-by: Greg Kroah-Hartman commit 8d353b6d2f264168b820b2124c3db5018430fd04 Author: Stephen Warren Date: Tue Jan 7 15:00:12 2014 -0700 serial: 8250: enable UART_BUG_NOMSR for Tegra commit 3685f19e07802ec4207b52465c408f185b66490e upstream. Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have their MODEM-control signals tied off to a static state. However UARTs A and B can optionally route those signals to/from package pins, depending on the exact pinmux configuration. When these signals are not routed to package pins, false interrupts may trigger either temporarily, or permanently, all while not showing up in the IIR; it will read as NO_INT. This will eventually lead to the UART IRQ being disabled due to unhandled interrupts. When this happens, the kernel may print e.g.: irq 68: nobody cared (try booting with the "irqpoll" option) In order to prevent this, enable UART_BUG_NOMSR. This prevents UART_IER_MSI from being enabled, which prevents the false interrupts from triggering. In practice, this is not needed under any of the following conditions: * On Tegra chips after Tegra30, since the HW bug has apparently been fixed. * On UARTs C..E since their MODEM control signals are tied to the correct static state which doesn't trigger the issue. * On UARTs A..B if the MODEM control signals are routed out to package pins, since they will then carry valid signals. However, we ignore these exceptions for now, since they are only relevant if a board actually hooks up more than a 4-wire UART, and no currently supported board does this. If we ever support a board that does, we can refine the algorithm that enables UART_BUG_NOMSR to take those exceptions into account, and/or read a flag from DT/... that indicates that the board has hooked up and pinmux'd more than a 4-wire UART. Reported-by: Olof Johansson # autotester Signed-off-by: Stephen Warren Signed-off-by: Greg Kroah-Hartman commit 2f8cef8c248cf56daefe3c2fb98f13cc626377f5 Author: Jonathan Woithe Date: Mon Dec 9 16:33:08 2013 +1030 serial: 8250: Fix initialisation of Quatech cards with the AMCC PCI chip commit 9c5320f8d7d9a2cf623e65d50e1113f34d9b9eb1 upstream. Fix the initialisation of older Quatech serial cards which are fitted with the AMCC PCI Matchmaker interface chip. Signed-off-by: Jonathan Woithe (jwoithe@just42.net) Signed-off-by: Greg Kroah-Hartman commit 1459439f7c43db399daf01ab5b5ead82248db361 Author: Yegor Yefremov Date: Mon Dec 9 12:11:15 2013 +0100 serial: add support for 200 v3 series Titan card commit 48c0247d7b7bf58abb85a39021099529df365c4d upstream. Signed-off-by: Yegor Yefremov Signed-off-by: Greg Kroah-Hartman commit 1d136c9b1e1008b3595ed826e210f158f3bedef2 Author: Phil Pokorny Date: Tue Jan 14 10:46:46 2014 -0800 hwmon: (k10temp) Add support for Kaveri CPUs commit d303b1b5fbb688282bbf72a534b9dfed7af9fe4f upstream. Add new PCI ID to support new model "Kaveri" family. Signed-off-by: Philip Pokorny Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 4b0bd296ad40a1a47ba5d6c37bf7dda84996db23 Author: Jean-Jacques Hiblot Date: Thu Jan 9 16:01:54 2014 +0100 ARM: at91: smc: bug fix in sam9_smc_cs_read() commit 1588c51cf6d782e63a8719681d905ef0ac22ee62 upstream. There was a copy/paste error when reading the nwe_pulse value. Signed-off-by: Jean-Jacques Hiblot Acked-by: Boris BREZILLON Signed-off-by: Nicolas Ferre Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 630cf7648cd47e83ddb674aaa4e4c245a6736f10 Author: Marek Roszko Date: Tue Jan 7 11:45:06 2014 +0100 tty/serial: at91: Handle shutdown more safely commit 0cc7c6c7916b1b6f34350ff1473b80b9f7e459c0 upstream. Interrupts were being cleaned up late in the shutdown handler, it is possible that an interrupt can occur and schedule a tasklet that runs after the port is cleaned up. There is a null dereference due to this race condition with the following stacktrace: [] (atmel_tasklet_func+0x514/0x814) from [] (tasklet_action+0x70/0xa8) [] (tasklet_action+0x70/0xa8) from [] (__do_softirq+0x90/0x144) [] (__do_softirq+0x90/0x144) from [] (irq_exit+0x40/0x4c) [] (irq_exit+0x40/0x4c) from [] (handle_IRQ+0x64/0x84) [] (handle_IRQ+0x64/0x84) from [] (__irq_svc+0x40/0x50) [] (__irq_svc+0x40/0x50) from [] (atmel_rx_dma_release+0x88/0xb8) [] (atmel_rx_dma_release+0x88/0xb8) from [] (atmel_shutdown+0x104/0x160) [] (atmel_shutdown+0x104/0x160) from [] (uart_port_shutdown+0x2c/0x38) Signed-off-by: Marek Roszko Acked-by: Leilei Zhao Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit d0db59cf6e28f8cd8958681bd9264375bbdde2c9 Author: Malcolm Priestley Date: Wed Jan 1 19:19:28 2014 +0000 staging: vt6656: CARDqGetNextTBTT correct uLowNextTBTT commit 9acec059c0cef0bf086c738f4c0b1f4447782a48 upstream. value uLowNextTBTT yields wrong value. ULL is needed with qwTSF Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit cbd508ca3c8d0d15521403f01688c57d42ba429f Author: Malcolm Priestley Date: Sun Dec 8 09:11:30 2013 +0000 staging: vt6656: [BUG] BBvUpdatePreEDThreshold Always set sensitivity on bScanning commit 8f248dae133668bfb8e9379b4b3f0571c858b24a upstream. byBBPreEDIndex value is initially 0, this means that from cold BBvUpdatePreEDThreshold is never set. This means that sensitivity may be in an ambiguous state, failing to scan any wireless points or at least distant ones. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit a8fb5c2d1833547695640260882ddbbf42dbe3c8 Author: Larry Finger Date: Tue Dec 24 11:22:54 2013 -0600 staging: r8712u: Set device type to wlan commit 3a21f00a5002b14e4aab52aef59d33ed28468a13 upstream. The latest version of NetworkManager does not recognize the device as wireless without this change. Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman commit 043a6ddb5d759bb941fed1ce3dec02461e0fd327 Author: ZHAO Gang Date: Sat Jan 18 00:17:38 2014 +0800 b43: fix the wrong assignment of status.freq in b43_rx() commit 64e5acb09ca6b50c97299cff9ef51299470b29f2 upstream. Use the right function to update frequency value. If rx skb is probe response or beacon, the wrong frequency value can cause problem that bss info can't be updated when it should be. Fixes: 8318d78a44d4 ("cfg80211 API for channels/bitrates, mac80211 and driver conversion") Signed-off-by: ZHAO Gang Acked-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit a77ea51bef5bd8b9d13118e5804d9537d54432a0 Author: Larry Finger Date: Sun Jan 12 15:11:39 2014 -0600 b43legacy: Fix unload oops if firmware is not available commit 452028665312672c6ba9e16a19248ee00ead9400 upstream. The asyncronous firmware load uses a completion struct to hold firmware processing until the user-space routines are up and running. There is. however, a problem in that the waiter is nevered canceled during teardown. As a result, unloading the driver when firmware is not available causes an oops. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 1a712907b90a5aad689e8757616537a506ba07f9 Author: Larry Finger Date: Sun Jan 12 15:11:38 2014 -0600 b43: Fix unload oops if firmware is not available commit 0673effd41dba323d6a280ef37b5ef29f3f5a653 upstream. The asyncronous firmware load uses a completion struct to hold firmware processing until the user-space routines are up and running. There is. however, a problem in that the waiter is nevered canceled during teardown. As a result, unloading the driver when firmware is not available causes an oops. To be able to access the completion structure at teardown, it had to be moved into the b43_wldev structure. This patch also fixes a typo in a comment. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit eeb405fd975fd5b684248d2d9039d685d34fac52 Author: Larry Finger Date: Sun Jan 12 15:11:37 2014 -0600 b43: Fix lockdep splat commit 09164043f63c947a49797750a09ca1cd7c31108e upstream. In https://bugzilla.kernel.org/show_bug.cgi?id=67561, a locking dependency is reported when b43 is used with hostapd, and rfkill is used to kill the radio output. The lockdep splat (in part) is as follows: ====================================================== [ INFO: possible circular locking dependency detected ] 3.12.0 #1 Not tainted ------------------------------------------------------- rfkill/10040 is trying to acquire lock: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20 but task is already holding lock: (rfkill_global_mutex){+.+.+.}, at: [] rfkill_fop_write+0x6a/0x170 [rfkill] --snip-- Chain exists of: rtnl_mutex --> misc_mtx --> rfkill_global_mutex The fix is to move the initialization of the hardware random number generator outside the code range covered by the rtnl_mutex. Reported-by: yury Tested-by: yury Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8009d02813a995de606b860fbbe1d1f64c60b853 Author: Eliad Peller Date: Sun Jan 5 12:41:12 2014 +0200 iwlwifi: mvm: fix missing cleanup in .start() error path commit 91b0d1198417cf4fd9a7bd4138b6909f0b359099 upstream. Cleanup of iwl_mvm_leds was missing in case of error, resulting in the following warning: WARNING: at lib/kobject.c:196 kobject_add_internal+0x1f4/0x210() kobject_add_internal failed for phy0-led with -EEXIST, don't try to register things with the same name in the same directory. which prevents further reloads of the driver. Signed-off-by: Eliad Peller Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 67a417790310c86996014d04db7508d4d169fc16 Author: Bing Zhao Date: Tue Jan 14 19:16:34 2014 -0800 mwifiex: fix wrong 11ac bits setting in fw_cap_info commit 1e202242ee1432d68a8bea4919b2ae0ef19d9e06 upstream. bit 14 is actually reserved and bit 12 & 13 should be used for 11ac capability in fw_cap_info. Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 4f89122d7d1af51fa7b83bfc7a9f64e5388e333e Author: Amitkumar Karwar Date: Fri Jan 10 14:30:41 2014 -0800 mwifiex: add missing endian conversion for fw_tsf commit 9795229752c31da0c5f8a7dc4c827665327b52f9 upstream. It is u64 data received from firmware. Little endian to cpu conversion is required here. Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit dc0abfd72527fbcac2dd2e53983cd9bf3df3b97a Author: Larry Finger Date: Mon Nov 25 10:45:28 2013 -0600 rtlwifi: rtl8188ee: Fix typo in code commit f699273d6a624266ebc9198774f06ee64a3847a1 upstream. The static analyser "cppcheck" shows the following typo: drivers/net/wireless/rtlwifi/rtl8188ee/dm.c:1081]: (style) Same expression on both sides of '!='. Signed-off-by: Larry Finger Reported-by: David Binderman Cc: David Binderman Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 2b87cc4a6b60fd1d779e4b5c17b29df108b41959 Author: Larry Finger Date: Mon Nov 18 11:11:35 2013 -0600 rtlwifi: Add missing code to PWDB statics routine commit d82403a9f407217b6aed5260aa92a120e8e98310 upstream. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit e13fd656649ddae1810e9c35941bbd0db46d6482 Author: Larry Finger Date: Mon Nov 18 11:11:34 2013 -0600 rtlwifi: rtl8192cu: Fix some code in RF handling commit e9b0784bb9de3152e787ee779868c626b137fb3b upstream. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit c1ba994b17866a151bd16a4045afe308a12e4c1b Author: Larry Finger Date: Mon Nov 18 11:11:33 2013 -0600 rtlwifi: rtl8192cu: Update the power index registers commit 9806eacf5de27ab01d680c5d75c92a3a89734e4f upstream. This patch uses the newly introduced power index register routines. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit dd698b636e0f8824c2f2266997adf6a5b4538279 Author: Larry Finger Date: Mon Nov 18 11:11:32 2013 -0600 rtlwifi: rtl8192c: Add routines to save/restore power index registers commit 97204e93f01868eeba6ae5c4f3270f32905bb418 upstream. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 12470254ad4149bc44b203c8f3146af9cdfde507 Author: Larry Finger Date: Mon Nov 18 11:11:30 2013 -0600 rtlwifi: Increase the RX queue length for USB drivers commit dc6405712268fe514d3dd89aa936c4397b0871b9 upstream. The current number of RX buffers queued is 32, which is too small under heavy load. That number is doubled. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 057648f92b3f83197d177761dfd290409e23db13 Author: Larry Finger Date: Mon Nov 18 11:11:29 2013 -0600 rtlwifi: rtl8192c: Add new definitions in the dm_common header commit c908c74e005de780fddbe8cb6fcd44803f5d4b74 upstream. Changes in the gain-control mechanism will require some changes in the header. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 30d93e3bc81d1e123ae190bfbcf9d5b2a94a78b9 Author: Larry Finger Date: Mon Nov 18 11:11:28 2013 -0600 rtlwifi: Set the link state commit 619ce76f8bb850b57032501a39f26aa6c6731c70 upstream. The present code fails to set the linked state when an interface is added. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 867b648d5bdc755517587217d804fbb7991a4d37 Author: Larry Finger Date: Mon Nov 18 11:11:27 2013 -0600 rtlwifi: Redo register save locations commit b9a758a8c905fc59e783ae91ad645452d877ea88 upstream. The initial USB driver did not use some register save locations in the private data storage. To save some memory, a union was used to overlay these variables with USB I/O components. In an update of the gain-control code, these register save locations are now needed for USB drivers. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit c882a20524895d14cc2fe73dcb6b3f99ac87dac6 Author: Larry Finger Date: Mon Nov 18 11:11:26 2013 -0600 rtlwifi: rtl8192cu: Add new firmware commit 62009b7f12793c932aaba0df946b04cb4a77d022 upstream. Vendor driver rtl8188C_8192C_8192D_usb_linux_v3.4.2_3727.20120404 introduced new firmware for these chips. The code try for the new file, and fall back to the original firmware if the new file is not available. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit cfce18a7871370cf75c0a289a94ff52c5eec17d2 Author: Larry Finger Date: Mon Nov 18 11:11:25 2013 -0600 rtlwifi: rtl8192c: Prevent reconnect attempts if not connected commit 8fd77aec1a9d6f4328fc0244f21932114e066df3 upstream. This driver has a watchdog timer that attempts to reconnect when beacon frames are not seen for 6 seconds. This patch disables that reconnect whenever the device has never been connected. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit a4b29f1bd1a0a56a48f00c5737079f15826b441b Author: Larry Finger Date: Mon Nov 18 11:11:31 2013 -0600 rtlwifi: Update beacon statistics for USB driver commit 65b9cc97c6852fae19dc5c7745e9abc8dd380aad upstream. The USB drivers were not updating the beacon statistics, which led to false beacon loss indications. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit b6af95155795b65fddca842bf18ea63a37d907af Author: Larry Finger Date: Thu Jan 9 10:27:27 2014 -0600 rtlwifi: rtl8192cu: Add new device ID commit f87f960b2fb802f26ee3b00c19320e57a9c583ff upstream. Reported-by: Jan Prinsloo Tested-by: Jan Prinsloo Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 0660fe75b2fcb2d3cf5d27e07104fc09c1e4e814 Author: Peter Chen Date: Fri Jan 10 13:51:26 2014 +0800 usb: ehci: add freescale imx28 special write register method commit feffe09f510c475df082546815f9e4a573f6a233 upstream. According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB register error issue", All USB register write operations must use the ARM SWP instruction. So, we implement a special ehci_write for imx28. Discussion for it at below: http://marc.info/?l=linux-usb&m=137996395529294&w=2 Without this patcheset, imx28 works unstable at high AHB bus loading. If the bus loading is not high, the imx28 usb can work well at the most of time. There is a IC errata for this problem, usually, we consider IC errata is a problem not a new feature, and this workaround is needed for that, so we need to add them to stable tree 3.11+. Cc: robert.hodaszi@digi.com Signed-off-by: Peter Chen Acked-by: Alan Stern Signed-off-by: Marc Kleine-Budde Tested-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 356c1be69288990cb10c1969c45566d5ec03fbe6 Author: Alan Stern Date: Tue Jan 7 10:43:02 2014 -0500 USB: fix race between hub_disconnect and recursively_mark_NOTATTACHED commit 543d7784b07ffd16cc82a9cb4e1e0323fd0040f1 upstream. There is a race in the hub driver between hub_disconnect() and recursively_mark_NOTATTACHED(). This race can be triggered if the driver is unbound from a device at the same time as the bus's root hub is removed. When the race occurs, it can cause an oops: BUG: unable to handle kernel NULL pointer dereference at 0000015c IP: [] recursively_mark_NOTATTACHED+0x20/0x60 Call Trace: [] recursively_mark_NOTATTACHED+0x34/0x60 [] recursively_mark_NOTATTACHED+0x34/0x60 [] recursively_mark_NOTATTACHED+0x34/0x60 [] recursively_mark_NOTATTACHED+0x34/0x60 [] usb_set_device_state+0x92/0x120 [] usb_disconnect+0x2b/0x1a0 [] usb_remove_hcd+0xb0/0x160 [] ? _raw_spin_unlock_irqrestore+0x26/0x50 [] ehci_mid_remove+0x1c/0x30 [] ehci_mid_stop_host+0x16/0x30 [] penwell_otg_work+0xd28/0x3520 [] ? __schedule+0x39b/0x7f0 [] ? sub_preempt_count+0x3d/0x50 [] process_one_work+0x11d/0x3d0 [] ? mutex_unlock+0xd/0x10 [] ? manage_workers.isra.24+0x1b5/0x270 [] worker_thread+0xf9/0x320 [] ? _raw_spin_unlock_irqrestore+0x26/0x50 [] ? rescuer_thread+0x2b0/0x2b0 [] kthread+0x94/0xa0 [] ret_from_kernel_thread+0x1b/0x28 [] ? kthread_create_on_node+0xc0/0xc0 One problem is that recursively_mark_NOTATTACHED() uses the intfdata value and hub->hdev->maxchild while hub_disconnect() is clearing them. Another problem is that it uses hub->ports[i] while the port device is being released. To fix this race, we need to hold the device_state_lock while hub_disconnect() changes the values. (Note that usb_disconnect() and hub_port_connect_change() already acquire this lock at similar critical times during a USB device's life cycle.) We also need to remove the port devices after maxchild has been set to 0, instead of before. Signed-off-by: Alan Stern Reported-by: "Du, Changbin" Tested-by: "Du, Changbin" Signed-off-by: Greg Kroah-Hartman commit 01aca4a70e1d97fac18a563f30d50f4c2e8d3864 Author: Jack Pham Date: Fri Nov 15 14:53:14 2013 -0800 usb: xhci: Check for XHCI_PLAT in xhci_cleanup_msix() commit 9005355af23856c55a5538c9024355785424821b upstream. If CONFIG_PCI is enabled, make sure xhci_cleanup_msix() doesn't try to free a bogus PCI IRQ or dereference an invalid pci_dev when the xHCI device is actually a platform_device. This patch should be backported to kernels as old as 3.9, that contain the commit 52fb61250a7a132b0cfb9f4a1060a1f3c49e5a25 "xhci-plat: Don't enable legacy PCI interrupts." Signed-off-by: Jack Pham Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 915ad6ec8715b4799b0b0d3529db348a66fe3c9e Author: Mikhail Zolotaryov Date: Sat Dec 28 01:56:35 2013 +0200 USB: Nokia 502 is an unusual device commit 0e16114f2db4838251fb64f3b550996ad3585890 upstream. The USB storage operation of Nokia Asha 502 Dual SIM smartphone running Asha Platform 1.1.1 is unreliable in respect of data consistency (i.e. transfered files are corrupted). A similar issue is described here: http://discussions.nokia.com/t5/Asha-and-other-Nokia-Series-30/Nokia-301-USB-transfers-and-corrupted-files/td-p/1974170 The workaround is (MAX_SECTORS_64): rmmod usb_storage && modprobe usb_storage quirks=0421:06aa:m The patch adds the tested device to the unusual list permanently. Signed-off-by: Mikhail Zolotaryov Signed-off-by: Greg Kroah-Hartman commit 1d09b33eb63bf5d4b172b7f13f6010ebe578557d Author: Colin Leitner Date: Mon Jan 6 21:33:54 2014 +0100 USB: ftdi_sio: added CS5 quirk for broken smartcard readers commit c1f15196ac3b541d084dc80a8fbd8a74c6a0bd44 upstream. Genuine FTDI chips support only CS7/8. A previous fix in commit 8704211f65a2 ("USB: ftdi_sio: fixed handling of unsupported CSIZE setting") enforced this limitation and reported it back to userspace. However, certain types of smartcard readers depend on specific driver behaviour that requests 0 data bits (not 5) to change into a different operating mode if CS5 has been set. This patch reenables this behaviour for all FTDI devices. Tagged to be added to stable, because it affects a lot of users of embedded systems which rely on these readers to work properly. Reported-by: Heinrich Siebmanns Tested-by: Heinrich Siebmanns Signed-off-by: Colin Leitner Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 52793ef05113658e6391230625f8762cc3905c8f Author: Johan Hovold Date: Thu Jan 2 22:49:24 2014 +0100 USB: cypress_m8: fix ring-indicator detection and reporting commit 440ebadeae9298d7de3d4d105342691841ec88d0 upstream. Fix ring-indicator (RI) status-bit definition, which was defined as CTS, effectively preventing RI-changes from being detected while reporting false RI status. This bug predates git. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit bee144583ec7f2857d54423892c46415ed8b9dcb Author: Rahul Bedarkar Date: Thu Jan 2 20:57:56 2014 +0530 USB: serial: add support for iBall 3.5G connect usb modem commit 7d5c1b9c7cb5ec8e52b1adc65c484a923a8ea6c3 upstream. Add support for iBall 3.5G connect usb modem. $lsusb Bus 002 Device 006: ID 1c9e:9605 OMEGA TECHNOLOGY $usb-devices T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1c9e ProdID=9605 Rev=00.00 S: Manufacturer=USB Modem S: Product=USB Modem S: SerialNumber=1234567890ABCDEF C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Signed-off-by: Rahul Bedarkar Suggested-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 0ed3ff76395951cb0247c4e69cf2247d14ad9fad Author: 张君 Date: Wed Dec 18 15:37:17 2013 +0800 usb: option: add new zte 3g modem pids to option driver commit 4d90b819ae4c7ea8fd5e2bb7edc68c0f334be2e4 upstream. Signed-off-by: Jun zhang Signed-off-by: Greg Kroah-Hartman commit 6c19cce59684beb17f6d0b4b4917d11f0c4a2e03 Author: Johan Hovold Date: Sun Dec 29 19:22:53 2013 +0100 USB: pl2303: fix data corruption on termios updates commit 623c8263376c0b8a4b0c220232e7313d762cd0cc upstream. Some PL2303 devices are known to lose bytes if you change serial settings even to the same values as before. Avoid this by comparing the encoded settings with the previsouly used ones before configuring the device. The common case was fixed by commit bf5e5834bffc6 ("pl2303: Fix mode switching regression"), but this problem was still possible to trigger, for instance, by using the TCSETS2-interface to repeatedly request 115201 baud, which gets mapped to 115200 and thus always triggers a settings update. Cc: Frank Schäfer Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 512f3430cf8aa7047245d94904af8df210bf4ecd Author: Marcelo Tosatti Date: Mon Jan 6 12:00:02 2014 -0200 KVM: x86: limit PIT timer frequency commit 9ed96e87c5748de4c2807ef17e81287c7304186c upstream. Limit PIT timer frequency similarly to the limit applied by LAPIC timer. Reviewed-by: Jan Kiszka Signed-off-by: Marcelo Tosatti Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5a45f3d11a80155ef9997cb1389a9213f9801f7f Author: Dave Young Date: Fri Dec 20 18:02:15 2013 +0800 x86/efi: Fix off-by-one bug in EFI Boot Services reservation commit a7f84f03f660d93574ac88835d056c0d6468aebe upstream. Current code check boot service region with kernel text region by: start+size >= __pa_symbol(_text) The end of the above region should be start + size - 1 instead. I see this problem in ovmf + Fedora 19 grub boot: text start: 1000000 md start: 800000 md size: 800000 Signed-off-by: Dave Young Acked-by: Borislav Petkov Acked-by: Toshi Kani Tested-by: Toshi Kani Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit e9d7427596cc83f8c79c1d64323a65efcdcd87c6 Author: PaX Team Date: Thu Jan 30 16:59:25 2014 -0800 x86, x32: Correct invalid use of user timespec in the kernel commit 2def2ef2ae5f3990aabdbe8a755911902707d268 upstream. The x32 case for the recvmsg() timout handling is broken: asmlinkage long compat_sys_recvmmsg(int fd, struct compat_mmsghdr __user *mmsg, unsigned int vlen, unsigned int flags, struct compat_timespec __user *timeout) { int datagrams; struct timespec ktspec; if (flags & MSG_CMSG_COMPAT) return -EINVAL; if (COMPAT_USE_64BIT_TIME) return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen, flags | MSG_CMSG_COMPAT, (struct timespec *) timeout); ... The timeout pointer parameter is provided by userland (hence the __user annotation) but for x32 syscalls it's simply cast to a kernel pointer and is passed to __sys_recvmmsg which will eventually directly dereference it for both reading and writing. Other callers to __sys_recvmmsg properly copy from userland to the kernel first. The bug was introduced by commit ee4fa23c4bfc ("compat: Use COMPAT_USE_64BIT_TIME in net/compat.c") and should affect all kernels since 3.4 (and perhaps vendor kernels if they backported x32 support along with this code). Note that CONFIG_X86_X32_ABI gets enabled at build time and only if CONFIG_X86_X32 is enabled and ld can build x32 executables. Other uses of COMPAT_USE_64BIT_TIME seem fine. This addresses CVE-2014-0038. Signed-off-by: PaX Team Signed-off-by: H. Peter Anvin Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 126f36274f181043c29188cda4f1c4296dc98a79 Author: David Rientjes Date: Thu Jan 30 15:46:08 2014 -0800 mm/mempolicy.c: fix mempolicy printing in numa_maps commit 8790c71a18e5d2d93532ae250bcf5eddbba729cd upstream. As a result of commit 5606e3877ad8 ("mm: numa: Migrate on reference policy"), /proc//numa_maps prints the mempolicy for any as "prefer:N" for the local node, N, of the process reading the file. This should only be printed when the mempolicy of is MPOL_PREFERRED for node N. If the process is actually only using the default mempolicy for local node allocation, make sure "default" is printed as expected. Signed-off-by: David Rientjes Reported-by: Robert Lippert Cc: Peter Zijlstra Acked-by: Mel Gorman Cc: Ingo Molnar Cc: [3.7+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6065e532d141ec0cc6f621021f081642d8d6c141 Author: David Ertman Date: Sat Dec 14 07:18:18 2013 +0000 e1000e: fix compiler warnings commit 9e6c3b63399dd424d33a34e08b77f2cab0b84cdc upstream. This patch is to fix a compiler warning of __bad_udelay due to a value of >999 being passed as a parameter to udelay() in the function e1000e_phy_has_link_generic(). This affects the gcc compiler when it is given a flag of -O3 and the icc compiler. This patch is also making the change from mdelay() to msleep() in the same function, since it was determined though code inspection that this function is never called in atomic context. Signed-off-by: David Ertman Acked-by: Bruce Allan Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 03117884dc39b1ce164da1671e010970779b0c64 Author: Aristeu Rozanski Date: Thu Dec 5 10:37:56 2013 -0500 e752x_edac: Fix pci_dev usage count commit 90ed4988b8c030d65b41b7d13140e9376dc6ec5a upstream. In case the device 0, function 1 is not found using pci_get_device(), pci_scan_single_device() will be used but, differently than pci_get_device(), it allocates a pci_dev but doesn't does bump the usage count on the pci_dev and after few module removals and loads the pci_dev will be freed. Signed-off-by: Aristeu Rozanski Reviewed-by: mark gross Link: http://lkml.kernel.org/r/20131205153755.GL4545@redhat.com Signed-off-by: Borislav Petkov Cc: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 17b6ada0567b5a9b837d37ad007c6da36dd759c0 Author: Andrea Arcangeli Date: Thu Nov 21 14:32:02 2013 -0800 mm: hugetlbfs: fix hugetlbfs optimization commit 27c73ae759774e63313c1fbfeb17ba076cea64c5 upstream. Commit 7cb2ef56e6a8 ("mm: fix aio performance regression for database caused by THP") can cause dereference of a dangling pointer if split_huge_page runs during PageHuge() if there are updates to the tail_page->private field. Also it is repeating compound_head twice for hugetlbfs and it is running compound_head+compound_trans_head for THP when a single one is needed in both cases. The new code within the PageSlab() check doesn't need to verify that the THP page size is never bigger than the smallest hugetlbfs page size, to avoid memory corruption. A longstanding theoretical race condition was found while fixing the above (see the change right after the skip_unlock label, that is relevant for the compound_lock path too). By re-establishing the _mapcount tail refcounting for all compound pages, this also fixes the below problem: echo 0 >/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages BUG: Bad page state in process bash pfn:59a01 page:ffffea000139b038 count:0 mapcount:10 mapping: (null) index:0x0 page flags: 0x1c00000000008000(tail) Modules linked in: CPU: 6 PID: 2018 Comm: bash Not tainted 3.12.0+ #25 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x55/0x76 bad_page+0xd5/0x130 free_pages_prepare+0x213/0x280 __free_pages+0x36/0x80 update_and_free_page+0xc1/0xd0 free_pool_huge_page+0xc2/0xe0 set_max_huge_pages.part.58+0x14c/0x220 nr_hugepages_store_common.isra.60+0xd0/0xf0 nr_hugepages_store+0x13/0x20 kobj_attr_store+0xf/0x20 sysfs_write_file+0x189/0x1e0 vfs_write+0xc5/0x1f0 SyS_write+0x55/0xb0 system_call_fastpath+0x16/0x1b Signed-off-by: Khalid Aziz Signed-off-by: Andrea Arcangeli Tested-by: Khalid Aziz Cc: Pravin Shelar Cc: Greg Kroah-Hartman Cc: Ben Hutchings Cc: Christoph Lameter Cc: Johannes Weiner Cc: Mel Gorman Cc: Rik van Riel Cc: Andi Kleen Cc: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Guillaume Morin Signed-off-by: Greg Kroah-Hartman commit c18e49ad50903819b947aea33c1cdcef724f7c35 Author: Alexandre Courbot Date: Wed Sep 11 14:23:53 2013 -0700 lib/decompressors: fix "no limit" output buffer length commit 1431574a1c4c669a0c198e4763627837416e4443 upstream. When decompressing into memory, the output buffer length is set to some arbitrarily high value (0x7fffffff) to indicate the output is, virtually, unlimited in size. The problem with this is that some platforms have their physical memory at high physical addresses (0x80000000 or more), and that the output buffer address and its "unlimited" length cannot be added without overflowing. An example of this can be found in inflate_fast(): /* next_out is the output buffer address */ out = strm->next_out - OFF; /* avail_out is the output buffer size. end will overflow if the output * address is >= 0x80000104 */ end = out + (strm->avail_out - 257); This has huge consequences on the performance of kernel decompression, since the following exit condition of inflate_fast() will be always true: } while (in < last && out < end); Indeed, "end" has overflowed and is now always lower than "out". As a result, inflate_fast() will return after processing one single byte of input data, and will thus need to be called an unreasonably high number of times. This probably went unnoticed because kernel decompression is fast enough even with this issue. Nonetheless, adjusting the output buffer length in such a way that the above pointer arithmetic never overflows results in a kernel decompression that is about 3 times faster on affected machines. Signed-off-by: Alexandre Courbot Tested-by: Jon Medhurst Cc: Stephen Warren Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 366d6b206f19ebe663503dbb58c2d05ab5f1b3f4 Author: Ilia Mirkin Date: Tue Jan 7 12:33:59 2014 -0500 drm/nouveau/bios: fix offset calculation for BMPv1 bioses commit 5d2f4767c4eacab351b8450b0de4d3261fe1a957 upstream. The only BIOS on record that needs the 14 offset has a bios major version 2 but BMP version 1.01. Another bunch of BIOSes that need the 18 offset have BMP version 2.01 or 5.01 or higher. So instead of looking at the bios major version, look at the BMP version. BIOSes with BMP version 0 do not contain a detectable script, so always return 0 for them. See https://bugs.freedesktop.org/show_bug.cgi?id=68835 Reported-by: Mauro Molinari Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 6ba854e9bf9aa4a481038cf20ccbb878cacb8418 Author: NeilBrown Date: Thu Jan 16 09:35:38 2014 +1100 md/raid5: fix long-standing problem with bitmap handling on write failure. commit 9f97e4b128d2ea90a5f5063ea0ee3b0911f4c669 upstream. Before a write starts we set a bit in the write-intent bitmap. When the write completes we clear that bit if the write was successful to all devices. However if the write wasn't fully successful we should not clear the bit. If the faulty drive is subsequently re-added, the fact that the bit is still set ensure that we will re-write the data that is missing. This logic is mediated by the STRIPE_DEGRADED flag - we only clear the bitmap bit when this flag is not set. Currently we correctly set the flag if a write starts when some devices are failed or missing. But we do *not* set the flag if some device failed during the write attempt. This is wrong and can result in clearing the bit inappropriately. So: set the flag when a write fails. This bug has been present since bitmaps were introduces, so the fix is suitable for any -stable kernel. Reported-by: Ethan Wilson Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit d934d91ae3399d562849d5da096cf93d08ddc9c4 Author: Andrew Jones Date: Wed Jan 15 13:39:59 2014 +0100 kvm: x86: fix apic_base enable check commit 0dce7cd67fd9055c4a2ff278f8af1431e646d346 upstream. Commit e66d2ae7c67bd moved the assignment vcpu->arch.apic_base = value above a condition with (vcpu->arch.apic_base ^ value), causing that check to always fail. Use old_value, vcpu->arch.apic_base's old value, in the condition instead. Signed-off-by: Andrew Jones Signed-off-by: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Greg Kroah-Hartman