30 Jan, 2015
40 commits
-
commit 45f87de57f8fad59302fd263dd81ffa4843b5b24 upstream.
Commit 2457aec63745 ("mm: non-atomically mark page accessed during page
cache allocation where possible") has added a separate parameter for
specifying gfp mask for radix tree allocations.Not only this is less than optimal from the API point of view because it
is error prone, it is also buggy currently because
grab_cache_page_write_begin is using GFP_KERNEL for radix tree and if
fgp_flags doesn't contain FGP_NOFS (mostly controlled by fs by
AOP_FLAG_NOFS flag) but the mapping_gfp_mask has __GFP_FS cleared then
the radix tree allocation wouldn't obey the restriction and might
recurse into filesystem and cause deadlocks. This is the case for most
filesystems unfortunately because only ext4 and gfs2 are using
AOP_FLAG_NOFS.Let's simply remove radix_gfp_mask parameter because the allocation
context is same for both page cache and for the radix tree. Just make
sure that the radix tree gets only the sane subset of the mask (e.g. do
not pass __GFP_WRITE).Long term it is more preferable to convert remaining users of
AOP_FLAG_NOFS to use mapping_gfp_mask instead and simplify this
interface even further.Reported-by: Dave Chinner
Signed-off-by: Michal Hocko
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit a3a8784454692dd72e5d5d34dcdab17b4420e74c upstream.
When a key is being garbage collected, it's key->user would get put before
the ->destroy() callback is called, where the key is removed from it's
respective tracking structures.This leaves a key hanging in a semi-invalid state which leaves a window open
for a different task to try an access key->user. An example is
find_keyring_by_name() which would dereference key->user for a key that is
in the process of being garbage collected (where key->user was freed but
->destroy() wasn't called yet - so it's still present in the linked list).This would cause either a panic, or corrupt memory.
Fixes CVE-2014-9529.
Signed-off-by: Sasha Levin
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman -
commit 5c0b8e0de76a86edb99e46612fd9d341b4c4fa0a upstream.
This patch fixes the big endian mode issue with function
xgene_ahci_read_id.Signed-off-by: Suman Tripathi
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 4aaa71873ddb9faf4b0c4826579e2f6d18ff9ab4 upstream.
DMA mapped IO should be unmapped on the error path in probe() and
unconditionally on remove().Fixes: 62936009f35a ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex)
Signed-off-by: Andy Shevchenko
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 38a1dfda8e77d7ba74c94d06d8bc41ba98a4bc8c upstream.
Commit 0dbc6078c06bc0 ('x86, build, pci: Fix PCI_MSI build on !SMP')
introduced the dependency that X86_UP_APIC is only available when
PCI_MSI is false. This effectively prevents PCI_MSI support on 32bit
UP systems because it disables both APIC and IO-APIC. But APIC support
is architecturally required for PCI_MSI.The intention of the patch was to enforce APIC support when PCI_MSI is
enabled, but failed to do so.Remove the !PCI_MSI dependency from X86_UP_APIC and enforce
X86_UP_APIC when PCI_MSI support is enabled on 32bit UP systems.[ tglx: Massaged changelog ]
Fixes 0dbc6078c06bc0 'x86, build, pci: Fix PCI_MSI build on !SMP'
Signed-off-by: Bryan O'Donoghue
Suggested-by: Thomas Gleixner
Reviewed-by: Andy Shevchenko
Cc: Thomas Petazzoni
Link: http://lkml.kernel.org/r/1421967529-9037-1-git-send-email-pure.logic@nexus-software.ie
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 3669ef9fa7d35f573ec9c0e0341b29251c2734a7 upstream.
The Witcher 2 did something like this to allocate a TLS segment index:
struct user_desc u_info;
bzero(&u_info, sizeof(u_info));
u_info.entry_number = (uint32_t)-1;syscall(SYS_set_thread_area, &u_info);
Strictly speaking, this code was never correct. It should have set
read_exec_only and seg_not_present to 1 to indicate that it wanted
to find a free slot without putting anything there, or it should
have put something sensible in the TLS slot if it wanted to allocate
a TLS entry for real. The actual effect of this code was to
allocate a bogus segment that could be used to exploit espfix.The set_thread_area hardening patches changed the behavior, causing
set_thread_area to return -EINVAL and crashing the game.This changes set_thread_area to interpret this as a request to find
a free slot and to leave it empty, which isn't *quite* what the game
expects but should be close enough to keep it working. In
particular, using the code above to allocate two segments will
allocate the same segment both times.According to FrostbittenKing on Github, this fixes The Witcher 2.
If this somehow still causes problems, we could instead allocate
a limit==0 32-bit data segment, but that seems rather ugly to me.Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
Signed-off-by: Andy Lutomirski
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/0cb251abe1ff0958b8e468a9a9a905b80ae3a746.1421954363.git.luto@amacapital.net
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit e30ab185c490e9a9381385529e0fd32f0a399495 upstream.
32-bit programs don't have an lm bit in their ABI, so they can't
reliably cause LDT_empty to return true without resorting to memset.
They shouldn't need to do this.This should fix a longstanding, if minor, issue in all 64-bit kernels
as well as a potential regression in the TLS hardening code.Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
Signed-off-by: Andy Lutomirski
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/72a059de55e86ad5e2935c80aa91880ddf19d07c.1421954363.git.luto@amacapital.net
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 63ea0a49ae0b145b91ff2b070c01b66fc75854b9 upstream.
STR and SLDT with rip-relative operand can cause a host kernel oops.
Mark them as DstMem as well.Signed-off-by: Nadav Amit
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit f3747379accba8e95d70cec0eae0582c8c182050 upstream.
SYSENTER emulation is broken in several ways:
1. It misses the case of 16-bit code segments completely (CVE-2015-0239).
2. MSR_IA32_SYSENTER_CS is checked in 64-bit mode incorrectly (bits 0 and 1 can
still be set without causing #GP).
3. MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP are not masked in
legacy-mode.
4. There is some unneeded code.Fix it.
Signed-off-by: Nadav Amit
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit f285f4a21c3253887caceed493089ece17579d59 upstream.
On 64-bit, relocation is not required unless the load address gets
changed. Without this, relocations do unexpected things when the kernel
is above 4G.Reported-by: Baoquan He
Signed-off-by: Kees Cook
Tested-by: Thomas D.
Cc: Vivek Goyal
Cc: Jan Beulich
Cc: Junjie Mao
Cc: Andi Kleen
Link: http://lkml.kernel.org/r/20150116005146.GA4212@www.outflux.net
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 520452172e6b318f3a8bd9d4fe1e25066393de25 upstream.
Many users see this message when booting without knowning that it is
of no importance and that TSC calibration may have succeeded by
another way.As explained by Paul Bolle in
http://lkml.kernel.org/r/1348488259.1436.22.camel@x61.thuisdomein"Fast TSC calibration failed" should not be considered as an error
since other calibration methods are being tried afterward. At most,
those send a warning if they fail (not an error). So let's change
the message from error to warning.[ tglx: Make if pr_info. It's really not important at all ]
Fixes: c767a54ba065 x86/debug: Add KERN_ to bare printks, convert printks to pr_
Signed-off-by: Alexandre Demers
Link: http://lkml.kernel.org/r/1418106470-6906-1-git-send-email-alexandre.f.demers@gmail.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 32c6590d126836a062b3140ed52d898507987017 upstream.
The Hyper-V clocksource is continuous; mark it accordingly.
Signed-off-by: K. Y. Srinivasan
Acked-by: jasowang@redhat.com
Cc: gregkh@linuxfoundation.org
Cc: devel@linuxdriverproject.org
Cc: olaf@aepfle.de
Cc: apw@canonical.com
Link: http://lkml.kernel.org/r/1421108762-3331-1-git-send-email-kys@microsoft.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 8c38d28ba8da98f7102c31d35359b4dbe9d1f329 upstream.
EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask
produces a number outside the range 0x00 to 0xff, which always results
in execution of the default switch statement.Obviously this is wrong and git history shows that the bitmask inversion
was incorrectly set during a refactoring of the MCT code.Fix this by putting the inversion at the correct position again.
Acked-by: Kukjin Kim
Reported-by: GP Orcullo
Reviewed-by: Doug Anderson
Signed-off-by: Tobias Jakobi
Signed-off-by: Daniel Lezcano
Signed-off-by: Greg Kroah-Hartman -
commit 4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f upstream.
The mis-naming likely was a copy-and-paste effect.
Signed-off-by: Jan Beulich
Link: http://lkml.kernel.org/r/54B9408B0200007800055E8B@mail.emea.novell.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 91d1179212161f220938198b742c328ad38fd0a3 upstream.
This patch makes the bitmask for AIC_SRCTYPE consistent
with that of its valid values, and prevents the priority
field at bits 2:0 from being clobbered by an incorrect
AND with the AIC_SRCTYPE mask.Signed-off-by: Gavin Li
Acked-by: Boris Brezillon
Acked-by: Nicolas Ferre
Link: https://lkml.kernel.org/r/1420598843-8409-1-git-send-email-gavinli@thegavinli.com
Signed-off-by: Jason Cooper
Signed-off-by: Greg Kroah-Hartman -
commit 378ff1a53b5724f3ac97b0aba3c9ecac072f6fcd upstream.
It really needs to check that src is non-directory *and* use
{un,}lock_two_nodirectories(). As it is, it's trivial to cause
double-lock (ioctl(fd, CIFS_IOC_COPYCHUNK_FILE, fd)) and if the
last argument is an fd of directory, we are asking for trouble
by violating the locking order - all directories go before all
non-directories. If the last argument is an fd of parent
directory, it has 50% odds of locking child before parent,
which will cause AB-BA deadlock if we race with unlink().Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman -
commit 38bdf45f4aa5cb6186d50a29e6cbbd9d486a1519 upstream.
On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.As a minimal fix for stable, don't use window 13. A full fix will
follow later.Fixes: fddddb52a6c ("bus: introduce an Marvell EBU MBus driver")
Reviewed-by: Thomas Petazzoni
Signed-off-by: Andrew Lunn
Signed-off-by: Greg Kroah-Hartman -
commit 8f1e8ee28660018a935c7576b9af8ffe1feab54c upstream.
The current hardware I/O coherency is known to cause problems with DMA
coherent buffers, as it still requires explicit I/O synchronization
barriers, which is not compatible with the semantics expected by the
Linux DMA coherent buffers API.So, in order to have enough time to validate a new solution based on
automatic I/O synchronization barriers, this commit disables hardware
I/O coherency entirely. Future patches will re-enable it.Signed-off-by: Thomas Petazzoni
Signed-off-by: Andrew Lunn
Signed-off-by: Greg Kroah-Hartman -
commit 7ecd0bde5bfea524a843ad8fa8cb66ccbce68779 upstream.
Currently PWM functionality is broken on mx25 due to the wrong assignment of the
PWM "per" clock.According to Documentation/devicetree/bindings/clock/imx25-clock.txt:
pwm_ipg_per 52,so update the pwm "per" to use 'pwm_ipg_per' instead of 'per10' clock.
With this change PWM can work fine on mx25.
Reported-by: Carlos Soto
Signed-off-by: Fabio Estevam
Signed-off-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman -
commit 5e5aeb4367b450a28f447f6d5ab57d8f2ab16a5f upstream.
Verify that the frequency value from userspace is valid and makes sense.
Unverified values can cause overflows later on.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Sasha Levin
[jstultz: Fix up bug for negative values and drop redunent cap check]
Signed-off-by: John Stultz
Signed-off-by: Greg Kroah-Hartman -
commit 6ada1fc0e1c4775de0e043e1bd3ae9d065491aa5 upstream.
An unvalidated user input is multiplied by a constant, which can result in
an undefined behaviour for large values. While this is validated later,
we should avoid triggering undefined behaviour.Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Sasha Levin
[jstultz: include trivial milisecond->microsecond correction noticed
by Andy]
Signed-off-by: John Stultz
Signed-off-by: Greg Kroah-Hartman -
commit 4b149e417463bbb6d1d9b805f729627ca2b54495 upstream.
commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Tested-by: Aaro Koskinen
Tested-by: Tony Lindgren
Signed-off-by: Felipe Balbi
Link: https://lkml.kernel.org/r/1420576688-10604-1-git-send-email-balbi@ti.com
Signed-off-by: Jason Cooper
Signed-off-by: Greg Kroah-Hartman -
commit a59db67656021fa212e9b95a583f13c34eb67cd9 upstream.
Introduce a new variable to count the number of allocated migration
structures. The existing variable cache->nr_migrations became
overloaded. It was used to:i) track of the number of migrations in flight for the purposes of
quiescing during suspend.ii) to estimate the amount of background IO occuring.
Recent discard changes meant that REQ_DISCARD bios are processed with
a migration. Discards are not background IO so nr_migrations was not
incremented. However this could cause quiescing to complete early.(i) is now handled with a new variable cache->nr_allocated_migrations.
cache->nr_migrations has been renamed cache->nr_io_migrations.
cleanup_migration() is now called free_io_migration(), since it
decrements that variable.Also, remove the unused cache->next_migration variable that got replaced
with with prealloc_structs a while ago.Signed-off-by: Joe Thornber
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 9b1cc9f251affdd27f29fe46d0989ba76c33faf6 upstream.
If a DM table is reloaded with an inactive table when the device is not
suspended (normal procedure for LVM2), then there will be two dm-bufio
objects that can diverge. This can lead to a situation where the
inactive table uses bufio to read metadata at the same time the active
table writes metadata -- resulting in the inactive table having stale
metadata buffers once it is promoted to the active table slot.Fix this by using reference counting and a global list of cache metadata
objects to ensure there is only one metadata object per metadata device.Signed-off-by: Joe Thornber
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 6cf11ee6300f38b7cfc43af9b7be2afaa5e05869 upstream.
The locking scheme inside the vb2 thread is unsafe when stopping the
thread. In particular kthread_stop was called *after* internal data
structures were cleaned up instead of doing that before. In addition,
internal vb2 functions were called after threadio->stop was set to
true and vb2_internal_streamoff was called. This is also not allowed.All this led to a variety of race conditions and kernel warnings and/or
oopses.Fixed by moving the kthread_stop call up before the cleanup takes
place, and by checking threadio->stop before calling internal vb2
queuing operations.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 721f3223f26bbe81c7e55f84188e74d99df50a16 upstream.
Unconditionally attaching Si2161/Si2165 demod driver
breaks Hauppauge WinTV Starburst.
So create own card entry for this.Add card name comments to the subsystem ids.
This fixes a regression introduced in 3.17 by
36efec48e2e6016e05364906720a0ec350a5d768 ([media] cx23885: Add si2165 support for HVR-5500)Signed-off-by: Matthias Schwarzott
Tested-by: Antti Palosaari
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 6cdb08172bc89f0a39e1643c5e7eab362692fd1b upstream.
Fixes a race condition in abort handling that was injected
when multiple interrupt support was added. When only a single
interrupt is present, the adapter guarantees it will send
responses for aborted commands prior to the response for the
abort command itself. With multiple interrupts, these responses
generally come back on different interrupts, so we need to
ensure the abort thread waits until the aborted command is
complete so we don't perform a double completion. This race
condition was being hit frequently in environments which
were triggering command timeouts, which was resulting in
a double completion causing a kernel oops.Signed-off-by: Brian King
Reviewed-by: Wendy Xiong
Tested-by: Wendy Xiong
Signed-off-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman -
commit c3e59ee4e76686b0c84ca8faa1011d10cd4ca1b8 upstream.
Reports against the TL-WDN4800 card indicate that PCI bus reset of this
Atheros device cause system lock-ups and resets. I've also been able to
confirm this behavior on multiple systems. The device never returns from
reset and attempts to access config space of the device after reset result
in hangs. Blacklist bus reset for the device to avoid this issue.[bhelgaas: This regression appeared in v3.14. Andreas bisected it to
425c1b223dac ("PCI: Add Virtual Channel to save/restore support"), but we
don't understand the mechanism by which that commit affects the reset
path.][bhelgaas: changelog, references]
Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Reported-by: Andreas Hartmann
Tested-by: Andreas Hartmann
Signed-off-by: Alex Williamson
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit f331a859e0ee5a898c1f47596eddad4c4f02d657 upstream.
Enable a mechanism for devices to quirk that they do not behave when
doing a PCI bus reset. We require a modest level of spec compliant
behavior in order to do a reset, for instance the device should come
out of reset without throwing errors and PCI config space should be
accessible after reset. This is too much to ask for some devices.Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Signed-off-by: Alex Williamson
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit 851b09369255a91e77f56d83e3643439ac5b209a upstream.
Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge. If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Tested-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x86@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 0f7e7aee2f37119a32e6e8b63250922442528961 upstream.
Add pci_bus_clip_resource(). If a PCI-PCI bridge window overlaps an
upstream bridge window but is not completely contained by it, this clips
the downstream window so it fits inside the upstream one.No functional change (this adds the function but no callers).
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit 8505e729a2f6eb0803ff943a15f133dd10afff3a upstream.
Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.This is for scenarios like this:
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch. That is a problem because Linux doesn't
always assign things optimally. For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration. Of
course, it's possible that devices below 00:01.0 will no longer fit. If
that's the case, we'll have to reassign things. But that's a separate
problem.[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit 3f2f4dc456e9f80849b99d79600a7257690ca4b1 upstream.
pci_setup_bridge_io(), pci_setup_bridge_mmio(), and
pci_setup_bridge_mmio_pref() program the windows of PCI-PCI bridges.
Previously they accepted a pointer to the pci_bus of the secondary bus,
then looked up the bridge leading to that bus. Pass the bridge directly,
which will make it more convenient for future callers.No functional change.
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit d8a74e186949e1a2c2f1309212478b0659bf9225 upstream.
This was accidently lost in 76a0df859def.
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 5615f890bc6babdc2998dec62f3552326d06eb7b upstream.
This adds a quirks list to fix stability problems with
certain SI boards.bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 4369a69ec6ab86821352bd753c68af5880f87956 upstream.
Disable dpm on certain problematic boards rather than
disabling dpm for the entire chip family since most
boards work fine.https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386534
https://bugzilla.kernel.org/show_bug.cgi?id=83731Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 226e5ae9e5f9108beb0bde4ac69f68fe6210fed9 upstream.
If CONFIG_DEBUG_MUTEXES is set, the mutex->owner field is only cleared
if the mutex debugging is enabled which introduces a race in our
mutex_is_locked_by() - i.e. we may inspect the old owner value before it
is acquired by the new task.This is the root cause of this error:
# diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
# index 5cf6731..3ef3736 100644
# --- a/kernel/locking/mutex-debug.c
# +++ b/kernel/locking/mutex-debug.c
# @@ -80,13 +80,13 @@ void debug_mutex_unlock(struct mutex *lock)
# DEBUG_LOCKS_WARN_ON(lock->owner != current);
#
# DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next);
# - mutex_clear_owner(lock);
# }
#
# /*
# * __mutex_slowpath_needs_to_unlock() is explicitly 0 for debug
# * mutexes so that we can do it here after we've verified state.
# */
# + mutex_clear_owner(lock);
# atomic_set(&lock->count, 1);
# }Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87955
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 48bf5b2d00bfeb681f6500c626189c7cd2c964d2 upstream.
Like Ivybridge, we have reports that we get random hangs when flipping
with multiple pipes. Extendcommit 2a92d5bca1999b69c78f3c3e97b5484985b094b9
Author: Chris Wilson
Date: Tue Jul 8 10:40:29 2014 +0100drm/i915: Disable RCS flips on Ivybridge
to also apply to Haswell.
Reported-and-tested-by: Scott Tsai
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87759
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 1caf6aaaa47471831d77c75f094d4e00ad1ec808 upstream.
Compiling SH with gcc-4.8 fails due to the -m32 option not being
supported.From http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=sh4&ver=3.16.7-ckt4-1&stamp=1421425783
CC init/main.o
gcc-4.8: error: unrecognized command line option '-m32'
ld: cannot find init/.tmp_mc_main.o: No such file or directory
objcopy: 'init/.tmp_mx_main.o': No such file
rm: cannot remove 'init/.tmp_mx_main.o': No such file or directory
rm: cannot remove 'init/.tmp_mc_main.o': No such file or directoryLink: http://lkml.kernel.org/r/1421537778-29001-1-git-send-email-kernel@mkarcher.dialup.fu-berlin.de
Link: http://lkml.kernel.org/r/54BCBDD4.10102@physik.fu-berlin.deCc: Matt Fleming
Reported-by: John Paul Adrian Glaubitz
Signed-off-by: Michael Karcher
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman -
commit 29187a9eeaf362d8422e62e17a22a6e115277a49 upstream.
A worker_pool's forward progress is guaranteed by the fact that the
last idle worker assumes the manager role to create more workers and
summon the rescuers if creating workers doesn't succeed in timely
manner before proceeding to execute work items.This manager role is implemented in manage_workers(), which indicates
whether the worker may proceed to work item execution with its return
value. This is necessary because multiple workers may contend for the
manager role, and, if there already is a manager, others should
proceed to work item execution.Unfortunately, the function also indicates that the worker may proceed
to work item execution if need_to_create_worker() is false at the head
of the function. need_to_create_worker() tests the following
conditions.pending work items && !nr_running && !nr_idle
The first and third conditions are protected by pool->lock and thus
won't change while holding pool->lock; however, nr_running can change
asynchronously as other workers block and resume and while it's likely
to be zero, as someone woke this worker up in the first place, some
other workers could have become runnable inbetween making it non-zero.If this happens, manage_worker() could return false even with zero
nr_idle making the worker, the last idle one, proceed to execute work
items. If then all workers of the pool end up blocking on a resource
which can only be released by a work item which is pending on that
pool, the whole pool can deadlock as there's no one to create more
workers or summon the rescuers.This patch fixes the problem by removing the early exit condition from
maybe_create_worker() and making manage_workers() return false iff
there's already another manager, which ensures that the last worker
doesn't start executing work items.We can leave the early exit condition alone and just ignore the return
value but the only reason it was put there is because the
manage_workers() used to perform both creations and destructions of
workers and thus the function may be invoked while the pool is trying
to reduce the number of workers. Now that manage_workers() is called
only when more workers are needed, the only case this early exit
condition is triggered is rare race conditions rendering it pointless.Tested with simulated workload and modified workqueue code which
trigger the pool deadlock reliably without this patch.Signed-off-by: Tejun Heo
Reported-by: Eric Sandeen
Link: http://lkml.kernel.org/g/54B019F4.8030009@sandeen.net
Cc: Dave Chinner
Cc: Lai Jiangshan
Signed-off-by: Greg Kroah-Hartman
