commit b67be2a5c9ed3f101e1562a9efe160b368000f89 Author: Greg Kroah-Hartman Date: Sat May 12 10:08:37 2012 -0700 Linux 3.3.6 commit 59da83377222910347425ec225cf3a665e0c8e1b 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: Greg Kroah-Hartman commit 804596fcfa2946ea83737346290f806651cd69ea 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: Greg Kroah-Hartman commit f3d426d5b791e91a0c515ac8f9dbf9e16dc439e6 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: Greg Kroah-Hartman commit c2fa9282ae75212b61077b274bf69d89890362e5 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 Signed-off-by: Greg Kroah-Hartman commit 502fd05d816f4a74a1a7bb45896ba35a33f8da10 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 and 3.3: use &resfh, not resfh] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit b9d36778c87e927d3272b2bb8beadc2c07ee8fa6 Author: Greg Kroah-Hartman Date: Thu Apr 12 08:47:05 2012 +0200 block: mtip32xx: remove HOTPLUG_PCI_PCIE dependancy commit 63634806519b49bb43f37e53a1e8366eb3e846a4 upstream. This removes the HOTPLUG_PCI_PCIE dependency on the driver and makes it depend on PCI. Cc: Sam Bradshaw Signed-off-by: Greg Kroah-Hartman Acked-by: Asai Thambi S P Signed-off-by: Jens Axboe commit 24041232df8a8e96113ddd1f83a58f552f1f5968 Author: Ryosuke Saito Date: Thu Apr 5 08:09:34 2012 -0600 mtip32xx: fix error handling in mtip_init() commit 6d27f09a6398ee086b11804aa3a16609876f0c7c upstream. Ensure that block device is properly unregistered, if pci_register_driver() fails. Signed-off-by: Ryosuke Saito Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 633935add06d8deb9fb2879fd06bbfd9df7e1a89 Author: Asai Thambi S P Date: Fri Mar 23 12:33:03 2012 +0100 mtip32xx: fix incorrect value set for drv_cleanup_done, and re-initialize and start port in mtip_restart_port() commit 22be2e6e13ac09b20000582ac34d47fb0029a6da upstream. This patch includes two changes: * fix incorrect value set for drv_cleanup_done * re-initialize and start port in mtip_restart_port() Signed-off-by: Asai Thambi S P Signed-off-by: Sam Bradshaw Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c6e143d5d46c8c84247c5ca9202c4d677a6162a7 Author: David Gibson Date: Wed Mar 21 16:34:12 2012 -0700 hugepages: fix use after free bug in "quota" handling commit 90481622d75715bfcb68501280a917dbfe516029 upstream. hugetlbfs_{get,put}_quota() are badly named. They don't interact with the general quota handling code, and they don't much resemble its behaviour. Rather than being about maintaining limits on on-disk block usage by particular users, they are instead about maintaining limits on in-memory page usage (including anonymous MAP_PRIVATE copied-on-write pages) associated with a particular hugetlbfs filesystem instance. Worse, they work by having callbacks to the hugetlbfs filesystem code from the low-level page handling code, in particular from free_huge_page(). This is a layering violation of itself, but more importantly, if the kernel does a get_user_pages() on hugepages (which can happen from KVM amongst others), then the free_huge_page() can be delayed until after the associated inode has already been freed. If an unmount occurs at the wrong time, even the hugetlbfs superblock where the "quota" limits are stored may have been freed. Andrew Barry proposed a patch to fix this by having hugepages, instead of storing a pointer to their address_space and reaching the superblock from there, had the hugepages store pointers directly to the superblock, bumping the reference count as appropriate to avoid it being freed. Andrew Morton rejected that version, however, on the grounds that it made the existing layering violation worse. This is a reworked version of Andrew's patch, which removes the extra, and some of the existing, layering violation. It works by introducing the concept of a hugepage "subpool" at the lower hugepage mm layer - that is a finite logical pool of hugepages to allocate from. hugetlbfs now creates a subpool for each filesystem instance with a page limit set, and a pointer to the subpool gets added to each allocated hugepage, instead of the address_space pointer used now. The subpool has its own lifetime and is only freed once all pages in it _and_ all other references to it (i.e. superblocks) are gone. subpools are optional - a NULL subpool pointer is taken by the code to mean that no subpool limits are in effect. Previous discussion of this bug found in: "Fix refcounting in hugetlbfs quota handling.". See: https://lkml.org/lkml/2011/8/11/28 or http://marc.info/?l=linux-mm&m=126928970510627&w=1 v2: Fixed a bug spotted by Hillf Danton, and removed the extra parameter to alloc_huge_page() - since it already takes the vma, it is not necessary. Signed-off-by: Andrew Barry Signed-off-by: David Gibson Cc: Hugh Dickins Cc: Mel Gorman Cc: Minchan Kim Cc: Hillf Danton Cc: Paul Mackerras Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0b518e8f62e2e1436c6506fd44f13894dc87b281 Author: Josh Boyer Date: Wed Nov 2 14:32:00 2011 -0400 sony-laptop: Enable keyboard backlight by default commit 6fe6ae56a7cebaebc2e6daa11c423e4692f9b592 upstream. When the keyboard backlight support was originally added, the commit said to default it to on with a 10 second timeout. That actually wasn't the case, as the default value is commented out for the kbd_backlight parameter. Because it is a static variable, it gets set to 0 by default without some other form of initialization. However, it seems the function to set the value wasn't actually called immediately, so whatever state the keyboard was in initially would remain. Then commit df410d522410e67660 was introduced during the 2.6.39 timeframe to immediately set whatever value was present (as well as attempt to restore/reset the state on module removal or resume). That seems to have now forced the light off immediately when the module is loaded unless the option kbd_backlight=1 is specified. Let's enable it by default again (for the first time). This should solve https://bugzilla.redhat.com/show_bug.cgi?id=728478 Signed-off-by: Josh Boyer Acked-by: Mattia Dongili Signed-off-by: Matthew Garrett Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit fecc7cbae16b25401cd6d53dda8fb8fcc1b1ec4f Author: Alex Williamson Date: Wed May 9 16:10:47 2012 +0300 KVM: lock slots_lock around device assignment (cherry picked from commit 21a1416a1c945c5aeaeaf791b63c64926018eb77) As pointed out by Jason Baron, when assigning a device to a guest we first set the iommu domain pointer, which enables mapping and unmapping of memory slots to the iommu. This leaves a window where this path is enabled, but we haven't synchronized the iommu mappings to the existing memory slots. Thus a slot being removed at that point could send us down unexpected code paths removing non-existent pinnings and iommu mappings. Take the slots_lock around creating the iommu domain and initial mappings as well as around iommu teardown to avoid this race. Signed-off-by: Alex Williamson Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit a4dfde33d7f8448d65d066392ecccbbf50d55fd8 Author: Avi Kivity Date: Wed May 9 16:10:46 2012 +0300 KVM: VMX: Fix kvm_set_shared_msr() called in preemptible context (cherry picked from commit 2225fd56049643c1a7d645c0ce9d499d43c7974e) kvm_set_shared_msr() may not be called in preemptible context, but vmx_set_msr() does so: BUG: using smp_processor_id() in preemptible [00000000] code: qemu-kvm/22713 caller is kvm_set_shared_msr+0x32/0xa0 [kvm] Pid: 22713, comm: qemu-kvm Not tainted 3.4.0-rc3+ #39 Call Trace: [] debug_smp_processor_id+0xe2/0x100 [] kvm_set_shared_msr+0x32/0xa0 [kvm] [] vmx_set_msr+0x28b/0x2d0 [kvm_intel] ... Making kvm_set_shared_msr() work in preemptible is cleaner, but it's used in the fast path. Making two variants is overkill, so this patch just disables preemption around the call. Reported-by: Dave Jones Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 8a4a30bf172a05f53714f0f54af2e044a6ede7a8 Author: Marcelo Tosatti Date: Wed May 9 16:10:45 2012 +0300 KVM: VMX: vmx_set_cr0 expects kvm->srcu locked (cherry picked from commit 7a4f5ad051e02139a9f1c0f7f4b1acb88915852b) vmx_set_cr0 is called from vcpu run context, therefore it expects kvm->srcu to be held (for setting up the real-mode TSS). Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 8dd2cb2a8d183d59f6d41dd71db550a306cc55eb Author: Nadav Har'El Date: Wed May 9 16:10:44 2012 +0300 KVM: nVMX: Fix erroneous exception bitmap check (cherry picked from commit 9587190107d0c0cbaccbf7bf6b0245d29095a9ae) The code which checks whether to inject a pagefault to L1 or L2 (in nested VMX) was wrong, incorrect in how it checked the PF_VECTOR bit. Thanks to Dan Carpenter for spotting this. Signed-off-by: Nadav Har'El Reported-by: Dan Carpenter Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 044873c9fc637a88225f0e01bedb9daee04524ed Author: Avi Kivity Date: Wed May 9 16:10:43 2012 +0300 KVM: VMX: Fix delayed load of shared MSRs (cherry picked from commit 9ee73970c03edb68146ceb1ba2a7033c99a5e017) Shared MSRs (MSR_*STAR and related) are stored in both vmx->guest_msrs and in the CPU registers, but vmx_set_msr() only updated memory. Prior to 46199f33c2953, this didn't matter, since we called vmx_load_host_state(), which scheduled a vmx_save_host_state(), which re-synchronized the CPU state, but now we don't, so the CPU state will not be synchronized until the next exit to host userspace. This mostly affects nested vmx workloads, which play with these MSRs a lot. Fix by loading the MSR eagerly. Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 9c895160d25a76c21b65bad141b08e8d4f99afef Author: Avi Kivity Date: Wed May 9 16:10:42 2012 +0300 KVM: Ensure all vcpus are consistent with in-kernel irqchip settings (cherry picked from commit 3e515705a1f46beb1c942bb8043c16f8ac7b1e9e) If some vcpus are created before KVM_CREATE_IRQCHIP, then irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading to potential NULL pointer dereferences. Fix by: - ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called - ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP This is somewhat long winded because vcpu->arch.apic is created without kvm->lock held. Based on earlier patch by Michael Ellerman. Signed-off-by: Michael Ellerman Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit c1cca0b1b79ba339d040793ad70fad254e1af220 Author: Gleb Natapov Date: Wed May 9 16:10:41 2012 +0300 KVM: x86 emulator: correctly mask pmc index bits in RDPMC instruction emulation (cherry picked from commit 270c6c79f4e15e599f47174ecedad932463af7a2) Signed-off-by: Gleb Natapov Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 6429d8675607e080deb716830f97ee0e78c991df Author: Takuya Yoshikawa Date: Wed May 9 16:10:40 2012 +0300 KVM: mmu_notifier: Flush TLBs before releasing mmu_lock (cherry picked from commit 565f3be2174611f364405bbea2d86e153c2e7e78) Other threads may process the same page in that small window and skip TLB flush and then return before these functions do flush. Signed-off-by: Takuya Yoshikawa Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 87a6c3e2b97b6556a7184a198d7b862b101c24cd Author: Takuya Yoshikawa Date: Wed May 9 16:10:39 2012 +0300 KVM: Fix write protection race during dirty logging (cherry picked from commit 6dbf79e7164e9a86c1e466062c48498142ae6128) This patch fixes a race introduced by: commit 95d4c16ce78cb6b7549a09159c409d52ddd18dae KVM: Optimize dirty logging by rmap_write_protect() During protecting pages for dirty logging, other threads may also try to protect a page in mmu_sync_children() or kvm_mmu_get_page(). In such a case, because get_dirty_log releases mmu_lock before flushing TLB's, the following race condition can happen: A (get_dirty_log) B (another thread) lock(mmu_lock) clear pte.w unlock(mmu_lock) lock(mmu_lock) pte.w is already cleared unlock(mmu_lock) skip TLB flush return ... TLB flush Though thread B assumes the page has already been protected when it returns, the remaining TLB entry will break that assumption. This patch fixes this problem by making get_dirty_log hold the mmu_lock until it flushes the TLB's. Signed-off-by: Takuya Yoshikawa Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit f6a0ce750df3fd54adbdbfbaf9f0736763f4f7ac Author: Christian Borntraeger Date: Wed May 9 16:10:38 2012 +0300 KVM: s390: Sanitize fpc registers for KVM_SET_FPU (cherry picked from commit 851755871c1f3184f4124c466e85881f17fa3226) commit 7eef87dc99e419b1cc051e4417c37e4744d7b661 (KVM: s390: fix register setting) added a load of the floating point control register to the KVM_SET_FPU path. Lets make sure that the fpc is valid. Signed-off-by: Christian Borntraeger Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit bb5f011a9b907e646904289c79f250b3aa17d57a Author: Jens Freimann Date: Wed May 9 16:10:37 2012 +0300 KVM: s390: do store status after handling STOP_ON_STOP bit (cherry picked from commit 9e0d5473e2f0ba2d2fe9dab9408edef3060b710e) In handle_stop() handle the stop bit before doing the store status as described for "Stop and Store Status" in the Principles of Operation. We have to give up the local_int.lock before calling kvm store status since it calls gmap_fault() which might sleep. Since local_int.lock only protects local_int.* and not guest memory we can give up the lock. Signed-off-by: Jens Freimann Signed-off-by: Christian Borntraeger Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 3b50cf3c908f2d025617f3e593c132fdfbc0eb4b Author: Alexander Duyck Date: Tue Feb 7 02:29:01 2012 +0000 net: Fix issue with netdev_tx_reset_queue not resetting queue from XOFF state [ Upstream commit 5c4903549c05bbb373479e0ce2992573c120654a ] We are seeing dev_watchdog hangs on several drivers. I suspect this is due to the __QUEUE_STATE_STACK_XOFF bit being set prior to a reset for link change, and then not being cleared by netdev_tx_reset_queue. This change corrects that. In addition we were seeing dev_watchdog hangs on igb after running the ethtool tests. We found this to be due to the fact that the ethtool test runs the same logic as ndo_start_xmit, but we were never clearing the XOFF flag since the loopback test in ethtool does not do byte queue accounting. Signed-off-by: Alexander Duyck Tested-by: Stephen Ko Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 4680d7ad59b1aeab6bd04d326523cf8e6b305f02 Author: Alexander Duyck Date: Tue Feb 7 02:29:06 2012 +0000 net: Add memory barriers to prevent possible race in byte queue limits [ Upstream commit b37c0fbe3f6dfba1f8ad2aed47fb40578a254635 ] This change adds a memory barrier to the byte queue limit code to address a possible race as has been seen in the past with the netif_stop_queue/netif_wake_queue logic. Signed-off-by: Alexander Duyck Tested-by: Stephen Ko Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 4f3f1e28d64084bae113cf9d3ca516bdc43046ad Author: Eric Dumazet Date: Wed May 2 02:28:41 2012 +0000 tcp: change tcp_adv_win_scale and tcp_rmem[2] [ Upstream commit b49960a05e32121d29316cfdf653894b88ac9190 ] tcp_adv_win_scale default value is 2, meaning we expect a good citizen skb to have skb->len / skb->truesize ratio of 75% (3/4) In 2.6 kernels we (mis)accounted for typical MSS=1460 frame : 1536 + 64 + 256 = 1856 'estimated truesize', and 1856 * 3/4 = 1392. So these skbs were considered as not bloated. With recent truesize fixes, a typical MSS=1460 frame truesize is now the more precise : 2048 + 256 = 2304. But 2304 * 3/4 = 1728. So these skb are not good citizen anymore, because 1460 < 1728 (GRO can escape this problem because it build skbs with a too low truesize.) This also means tcp advertises a too optimistic window for a given allocated rcvspace : When receiving frames, sk_rmem_alloc can hit sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often, especially when application is slow to drain its receive queue or in case of losses (netperf is fast, scp is slow). This is a major latency source. We should adjust the len/truesize ratio to 50% instead of 75% This patch : 1) changes tcp_adv_win_scale default to 1 instead of 2 2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account better truesize tracking and to allow autotuning tcp receive window to reach same value than before. Note that same amount of kernel memory is consumed compared to 2.6 kernels. Signed-off-by: Eric Dumazet Cc: Neal Cardwell Cc: Tom Herbert Cc: Yuchung Cheng Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 28a3d46497af5da64dd88110bf03d99cf181d5f9 Author: Yuchung Cheng Date: Mon Apr 30 06:00:18 2012 +0000 tcp: fix infinite cwnd in tcp_complete_cwr() [ Upstream commit 1cebce36d660c83bd1353e41f3e66abd4686f215 ] When the cwnd reduction is done, ssthresh may be infinite if TCP enters CWR via ECN or F-RTO. If cwnd is not undone, i.e., undo_marker is set, tcp_complete_cwr() falsely set cwnd to the infinite ssthresh value. The correct operation is to keep cwnd intact because it has been updated in ECN or F-RTO. Signed-off-by: Yuchung Cheng Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ac931e2df86c0f7e69df21001832ad63ffe3d1c9 Author: Matt Carlson Date: Tue Apr 24 13:37:01 2012 +0000 tg3: Avoid panic from reserved statblk field access [ Upstream commit f891ea1634ce41f5f47ae40d8594809f4cd2ca66 ] When RSS is enabled, interrupt vector 0 does not receive any rx traffic. The rx producer index fields for vector 0's status block should be considered reserved in this case. This patch changes the code to respect these reserved fields, which avoids a kernel panic when these fields take on non-zero values. Signed-off-by: Matt Carlson Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2b4a884ae39037f4f340e1249ae944d25b00c025 Author: Gerard Lledo Date: Sat Apr 28 08:52:37 2012 +0000 sungem: Fix WakeOnLan [ Upstream commit 5a8887d39e1ba5ee2d4ccb94b14d6f2dce5ddfca ] WakeOnLan was broken in this driver because gp->asleep_wol is a 1-bit bitfield and it was being assigned WAKE_MAGIC, which is (1 << 5). gp->asleep_wol remains 0 and the machine never wakes up. Fixed by casting gp->wake_on_lan to bool. Tested on an iBook G4. Signed-off-by: Gerard Lledo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bff12743574b49347d43393c29cb7c5e8dc8af5a Author: stephen hemminger Date: Mon Apr 30 06:47:37 2012 +0000 sky2: fix receive length error in mixed non-VLAN/VLAN traffic [ Upstream commit e072b3fad5f3915102c94628b4971f52ff99dd05 ] Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older supported chips. Sometimes the VLAN bit is not set for valid VLAN packets and also sometimes the VLAN bit is set for non-VLAN packets that came after a VLAN packet. This results in a receive length error when VLAN hardware tagging is enabled. Fix: Variation on original fix proposed by Mirko. The VLAN information is decoded in the status loop, and can be applied to the received SKB there. This eliminates the need for the separate tag field in the interface data structure. The tag has to be copied and cleared if packet is copied. This version checked out with vlan and normal traffic. Note: vlan_tx_tag_present should be renamed vlan_tag_present, but that is outside scope of this. Reported-by: Mirko Lindner Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bd920c58f390f5e76e5456d395adeccd3fb1e53d Author: stephen hemminger Date: Mon Apr 30 05:49:45 2012 +0000 sky2: propogate rx hash when packet is copied [ Upstream commit 3f42941b5d1d13542b1a755a9e4f633aa72e4d3e ] When a small packet is received, the driver copies it to a new skb to allow reusing the full size Rx buffer. The copy was propogating the checksum offload but not the receive hash information. The bug is impact was mostly harmless and therefore not observed until reviewing this area of code. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e6a23eedf2cd344f36a6f634212d4b0913f485fe Author: Sasha Levin Date: Wed May 2 03:58:43 2012 +0000 net: l2tp: unlock socket lock before returning from l2tp_ip_sendmsg [ Upstream commit 84768edbb2721637620b2d84501bb0d5aed603f1 ] l2tp_ip_sendmsg could return without releasing socket lock, making it all the way to userspace, and generating the following warning: [ 130.891594] ================================================ [ 130.894569] [ BUG: lock held when returning to user space! ] [ 130.897257] 3.4.0-rc5-next-20120501-sasha #104 Tainted: G W [ 130.900336] ------------------------------------------------ [ 130.902996] trinity/8384 is leaving the kernel with locks still held! [ 130.906106] 1 lock held by trinity/8384: [ 130.907924] #0: (sk_lock-AF_INET){+.+.+.}, at: [] l2tp_ip_sendmsg+0x2f/0x550 Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c"). Signed-off-by: Sasha Levin Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a3aea3c511888bf0b1261a5414051e43b69a5ebd Author: Eric W. Biederman Date: Fri Apr 6 15:33:35 2012 +0000 net: In unregister_netdevice_notifier unregister the netdevices. [ Upstream commit 7d3d43dab4e978d8d9ad1acf8af15c9b1c4b0f0f ] We already synthesize events in register_netdevice_notifier and synthesizing events in unregister_netdevice_notifier allows to us remove the need for special case cleanup code. This change should be safe as it adds no new cases for existing callers of unregiser_netdevice_notifier to handle. Signed-off-by: Eric W. Biederman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 51cfc3b6927a21512fddeb3ab07065295657fde8 Author: Eric Dumazet Date: Sun Apr 29 09:08:22 2012 +0000 netem: fix possible skb leak [ Upstream commit 116a0fc31c6c9b8fc821be5a96e5bf0b43260131 ] skb_checksum_help(skb) can return an error, we must free skb in this case. qdisc_drop(skb, sch) can also be feeded with a NULL skb (if skb_unshare() failed), so lets use this generic helper. Signed-off-by: Eric Dumazet Cc: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7a519993790a09fd6410bdeb0a049e96d11a2324 Author: Ingo van Lil Date: Mon Apr 23 22:05:38 2012 +0000 asix: Fix tx transfer padding for full-speed USB [ Upstream commit 2a5809499e35b53a6044fd34e72b242688b7a862 ] The asix.c USB Ethernet driver avoids ending a tx transfer with a zero- length packet by appending a four-byte padding to transfers whose length is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket length is valid for high-speed USB only; full-speed USB uses 64 byte packets. Signed-off-by: Ingo van Lil Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f4fad1b66f36116d8ac4f58c357ea077179c8e84 Author: Archit Taneja Date: Thu Apr 19 17:39:16 2012 +0530 ARM: OMAP: Revert "ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields" commit 08ca7444f589bedf9ad5d82883e5d0754852d73b upstream. This reverts commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237. The commit above swapped the DSI1_PPID and DSI2_PPID register fields in CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V). With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs. After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was pulling up voltage on DSI2 lanes. This proves that the current version of OMAP4 TRM is incorrect, swap the position of register fields according to the older TRM versions as they were correct. Acked-by: Tomi Valkeinen Signed-off-by: Archit Taneja Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit ddfe373c202b9d3a079365040855a0d297421bce Author: Ben Hutchings Date: Sun Apr 8 05:18:53 2012 +0100 ARM: orion5x: Fix GPIO enable bits for MPP9 commit 48d99f47a81a66bdd61a348c7fe8df5a7afdf5f3 upstream. Commit 554cdaefd1cf7bb54b209c4e68c7cec87ce442a9 ('ARM: orion5x: Refactor mpp code to use common orion platform mpp.') seems to have accidentally inverted the GPIO valid bits for MPP9 (only). For the mv2120 platform which uses MPP9 as a GPIO LED device, this results in the error: [ 12.711476] leds-gpio: probe of leds-gpio failed with error -22 Reported-by: Henry von Tresckow References: http://bugs.debian.org/667446 Signed-off-by: Ben Hutchings Tested-by: Hans Henry von Tresckow Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 89ec66f87f76f389887b04a415f6dd53305bb9d0 Author: Axel Lin Date: Wed Apr 11 20:53:58 2012 +0800 regulator: Fix the logic to ensure new voltage setting in valid range commit f55205f4d4a8823a11bb8b37ef2ecbd78fb09463 upstream. I think this is a typo. To ensure new voltage setting won't greater than desc->max, the equation should be desc->min + desc->step * new_val <= desc->max. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c35fda8ad637d6f86fad00139f7faaf3d1133302 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: Greg Kroah-Hartman commit 246301f454256967c5845a3e076c05ce488ff910 Author: Will Deacon Date: Fri May 4 17:53:52 2012 +0100 ARM: 7412/1: audit: use only AUDIT_ARCH_ARM regardless of endianness commit 2f978366984a418f38fcf44137be1fbc5a89cfd9 upstream. The machine endianness has no direct correspondence to the syscall ABI, so use only AUDIT_ARCH_ARM when identifying the ABI to the audit tools in userspace. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 50f764acf24996dc3fd845f837f88a80b80b7d53 Author: Will Deacon Date: Fri May 4 17:52:02 2012 +0100 ARM: 7411/1: audit: fix treatment of saved ip register during syscall tracing commit 6a68b6f574c8ad2c1d90f0db8fd95b8abe8a0a73 upstream. The ARM audit code incorrectly uses the saved application ip register value to infer syscall entry or exit. Additionally, the saved value will be clobbered if the current task is not being traced, which can lead to libc corruption if ip is live (apparently glibc uses it for the TLS pointer). This patch fixes the syscall tracing code so that the why parameter is used to infer the syscall direction and the saved ip is only updated if we know that we will be signalling a ptrace trap. Reported-and-Tested-by: Jon Masters Cc: Eric Paris Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit acfee6ae4cf54e4afb10252c86dc72ca3472eec7 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: Greg Kroah-Hartman commit 15e8eae4f13da852c0ed0a8b85af5ba62c46a56b 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: Greg Kroah-Hartman commit 5a3f30217f703a1e2124766bc2c5e4e4c8b57813 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: Greg Kroah-Hartman commit 4f9b82ae13a482026a83eafa307ca037131a54b3 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: Greg Kroah-Hartman commit 318c686eb39d8587b67be613a652ea55dc701a58 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: Greg Kroah-Hartman commit 800aaea4c2da2c2022c48a10c2e80ab68c6eb790 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 Signed-off-by: Greg Kroah-Hartman commit 9e52d84a9ac037d47e8c3f2db9e0a453237966f8 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: Greg Kroah-Hartman commit 35cdf78c44dc54a6262ebbfc745f46bd3b813f94 Author: Richard Zhao Date: Tue Apr 24 15:24:43 2012 +0800 ASoC: core: check of_property_count_strings failure commit c34ce320d9fe328e3272def20b152f39ccfa045e upstream. Signed-off-by: Richard Zhao Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e7bcb4bafa9bb05db987601067c2f9da45d2678c 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: Greg Kroah-Hartman commit fc737b6c5fb5e3d9f5562c1db8c8a73af2304cd4 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: Greg Kroah-Hartman commit 381c2fc9d4012983065c39f0fc50cac9ec32b0be 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 Signed-off-by: Greg Kroah-Hartman commit 3d018683171461ac7effa05fdecf296f4ab442a5 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: Greg Kroah-Hartman commit c820fc19273c7be987fd0e0963311fbf53b484bf Author: Jiri Pirko Date: Tue Mar 20 18:10:01 2012 +0000 e1000: fix vlan processing regression commit 52f5509fe8ccb607ff9b84ad618f244262336475 upstream. This patch fixes a regression introduced by commit "e1000: do vlan cleanup (799d531)". Apparently some e1000 chips (not mine) are sensitive about the order of setting vlan filter and vlan stripping/inserting functionality. So this patch changes the order so it's the same as before vlan cleanup. Reported-by: Ben Greear Signed-off-by: Jiri Pirko Tested-by: Ben Greear Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Cc: David Ward Signed-off-by: Greg Kroah-Hartman commit 3cb41a56a8dbe5df16c1a6e451dfaef6c387ead5 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: Greg Kroah-Hartman commit ab83a1346bc7877973e501c323df83e880a82ffb 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: Greg Kroah-Hartman