commit b67be2a5c9ed3f101e1562a9efe160b368000f89
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sat May 12 10:08:37 2012 -0700
Linux 3.3.6
commit 59da83377222910347425ec225cf3a665e0c8e1b
Author: Alan Stern <stern@rowland.harvard.edu>
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 <stern@rowland.harvard.edu>
Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 804596fcfa2946ea83737346290f806651cd69ea
Author: Felipe Balbi <balbi@ti.com>
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 <ben@decadent.org.uk>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f3d426d5b791e91a0c515ac8f9dbf9e16dc439e6
Author: Will Deacon <will.deacon@arm.com>
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 <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c2fa9282ae75212b61077b274bf69d89890362e5
Author: Will Deacon <will.deacon@arm.com>
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 <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 502fd05d816f4a74a1a7bb45896ba35a33f8da10
Author: J. Bruce Fields <bfields@redhat.com>
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 <orion@cora.nwra.com>
Tested-by: Orion Poplawski <orion@cora.nwra.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
[bwh: Backported to 3.2 and 3.3: use &resfh, not resfh]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b9d36778c87e927d3272b2bb8beadc2c07ee8fa6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <sbradshaw@micron.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
commit 24041232df8a8e96113ddd1f83a58f552f1f5968
Author: Ryosuke Saito <raitosyo@gmail.com>
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 <raitosyo@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 633935add06d8deb9fb2879fd06bbfd9df7e1a89
Author: Asai Thambi S P <asamymuthupa@micron.com>
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 <asamymuthupa@micron.com>
Signed-off-by: Sam Bradshaw <sbradshaw@micron.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c6e143d5d46c8c84247c5ca9202c4d677a6162a7
Author: David Gibson <david@gibson.dropbear.id.au>
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 <abarry@cray.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Cc: Hugh Dickins <hughd@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0b518e8f62e2e1436c6506fd44f13894dc87b281
Author: Josh Boyer <jwboyer@redhat.com>
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 <jwboyer@redhat.com>
Acked-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fecc7cbae16b25401cd6d53dda8fb8fcc1b1ec4f
Author: Alex Williamson <alex.williamson@redhat.com>
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 <alex.williamson@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a4dfde33d7f8448d65d066392ecccbbf50d55fd8
Author: Avi Kivity <avi@redhat.com>
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:
[<ffffffff8131fa82>] debug_smp_processor_id+0xe2/0x100
[<ffffffffa0328ae2>] kvm_set_shared_msr+0x32/0xa0 [kvm]
[<ffffffffa03a103b>] 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 <davej@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8a4a30bf172a05f53714f0f54af2e044a6ede7a8
Author: Marcelo Tosatti <mtosatti@redhat.com>
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 <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8dd2cb2a8d183d59f6d41dd71db550a306cc55eb
Author: Nadav Har'El <nyh@math.technion.ac.il>
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 <nyh@il.ibm.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 044873c9fc637a88225f0e01bedb9daee04524ed
Author: Avi Kivity <avi@redhat.com>
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 <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9c895160d25a76c21b65bad141b08e8d4f99afef
Author: Avi Kivity <avi@redhat.com>
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 <michael@ellerman.id.au>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c1cca0b1b79ba339d040793ad70fad254e1af220
Author: Gleb Natapov <gleb@redhat.com>
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 <gleb@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6429d8675607e080deb716830f97ee0e78c991df
Author: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
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 <yoshikawa.takuya@oss.ntt.co.jp>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 87a6c3e2b97b6556a7184a198d7b862b101c24cd
Author: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
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 <yoshikawa.takuya@oss.ntt.co.jp>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f6a0ce750df3fd54adbdbfbaf9f0736763f4f7ac
Author: Christian Borntraeger <borntraeger@de.ibm.com>
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 <borntraeger@de.ibm.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bb5f011a9b907e646904289c79f250b3aa17d57a
Author: Jens Freimann <jfrei@linux.vnet.ibm.com>
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 <jfrei@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3b50cf3c908f2d025617f3e593c132fdfbc0eb4b
Author: Alexander Duyck <alexander.h.duyck@intel.com>
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 <alexander.h.duyck@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4680d7ad59b1aeab6bd04d326523cf8e6b305f02
Author: Alexander Duyck <alexander.h.duyck@intel.com>
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 <alexander.h.duyck@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4f3f1e28d64084bae113cf9d3ca516bdc43046ad
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 28a3d46497af5da64dd88110bf03d99cf181d5f9
Author: Yuchung Cheng <ycheng@google.com>
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 <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ac931e2df86c0f7e69df21001832ad63ffe3d1c9
Author: Matt Carlson <mcarlson@broadcom.com>
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 <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2b4a884ae39037f4f340e1249ae944d25b00c025
Author: Gerard Lledo <gerard.lledo@gmail.com>
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 <gerard.lledo@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bff12743574b49347d43393c29cb7c5e8dc8af5a
Author: stephen hemminger <shemminger@vyatta.com>
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 <mlindner@marvell.com>
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bd920c58f390f5e76e5456d395adeccd3fb1e53d
Author: stephen hemminger <shemminger@vyatta.com>
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 <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e6a23eedf2cd344f36a6f634212d4b0913f485fe
Author: Sasha Levin <levinsasha928@gmail.com>
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: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550
Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c").
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a3aea3c511888bf0b1261a5414051e43b69a5ebd
Author: Eric W. Biederman <ebiederm@xmission.com>
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 <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 51cfc3b6927a21512fddeb3ab07065295657fde8
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
Cc: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7a519993790a09fd6410bdeb0a049e96d11a2324
Author: Ingo van Lil <inguin@gmx.de>
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 <inguin@gmx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f4fad1b66f36116d8ac4f58c357ea077179c8e84
Author: Archit Taneja <archit@ti.com>
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 <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ddfe373c202b9d3a079365040855a0d297421bce
Author: Ben Hutchings <ben@decadent.org.uk>
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 <hvontres@gmail.com>
References: http://bugs.debian.org/667446
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Hans Henry von Tresckow <hvontres@gmail.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 89ec66f87f76f389887b04a415f6dd53305bb9d0
Author: Axel Lin <axel.lin@gmail.com>
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 <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c35fda8ad637d6f86fad00139f7faaf3d1133302
Author: Colin Cross <ccross@android.com>
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 <ccross@android.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 246301f454256967c5845a3e076c05ce488ff910
Author: Will Deacon <will.deacon@arm.com>
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 <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 50f764acf24996dc3fd845f837f88a80b80b7d53
Author: Will Deacon <will.deacon@arm.com>
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 <jcm@jonmasters.org>
Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit acfee6ae4cf54e4afb10252c86dc72ca3472eec7
Author: Tim Bird <tim.bird@am.sony.com>
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 <tim.bird@am.sony.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 15e8eae4f13da852c0ed0a8b85af5ba62c46a56b
Author: Linus Torvalds <torvalds@linux-foundation.org>
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 <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5a3f30217f703a1e2124766bc2c5e4e4c8b57813
Author: H. Peter Anvin <hpa@linux.intel.com>
Date: Thu Apr 26 11:45:16 2012 -0700
asm-generic: Use __BITS_PER_LONG in statfs.h
commit f5c2347ee20a8d6964d6a6b1ad04f200f8d4dfa7 upstream.
<asm-generic/statfs.h> 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 <hjl.tools@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/1335465916-16965-1-git-send-email-hpa@linux.intel.com
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4f9b82ae13a482026a83eafa307ca037131a54b3
Author: Tejun Heo <tj@kernel.org>
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 <tj@kernel.org>
Reported-by: Yanmin Zhang <yanmin.zhang@intel.com>
Reported-by: ShuoX Liu <shuox.liu@intel.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
LKML-Reference: <4F97BA98.6010001@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 318c686eb39d8587b67be613a652ea55dc701a58
Author: Kusanagi Kouichi <slash@ac.auone-net.jp>
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 <slash@ac.auone-net.jp>
Link: http://lkml.kernel.org/r/20120401082932.D5E066FC03D@msa105.auone-net.jp
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 800aaea4c2da2c2022c48a10c2e80ab68c6eb790
Author: Stefan Metzmacher <metze@samba.org>
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 <metze@samba.org>
Tested-by: Björn Jacke <bj@sernet.de>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9e52d84a9ac037d47e8c3f2db9e0a453237966f8
Author: Eric Bénard <eric@eukrea.com>
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 <eric@eukrea.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 35cdf78c44dc54a6262ebbfc745f46bd3b813f94
Author: Richard Zhao <richard.zhao@freescale.com>
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 <richard.zhao@freescale.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e7bcb4bafa9bb05db987601067c2f9da45d2678c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <airlied@redhat.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fc737b6c5fb5e3d9f5562c1db8c8a73af2304cd4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <simon.farnsworth@onelan.co.uk>
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 <dominik@devwork.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 381c2fc9d4012983065c39f0fc50cac9ec32b0be
Author: David Vrabel <david.vrabel@citrix.com>
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 <jbeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
[v1: Fixed compile error when CONFIG_PCI is not set]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d018683171461ac7effa05fdecf296f4ab442a5
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
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: [<ffffffff8106aa51>] 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 <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c820fc19273c7be987fd0e0963311fbf53b484bf
Author: Jiri Pirko <jpirko@redhat.com>
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 <greearb@candelatech.com>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: David Ward <david.ward@ll.mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3cb41a56a8dbe5df16c1a6e451dfaef6c387ead5
Author: Paolo Pisati <paolo.pisati@canonical.com>
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 <paolo.pisati@canonical.com>
Acked-by: Steve Glendinning <steve.glendinning@shawell.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ab83a1346bc7877973e501c323df83e880a82ffb
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
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 <jbarnes@virtuousgeek.org>
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 <guang.a.yang@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: Pimped commit message by using the usual commit citation
layout.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>