- 30 Jan, 2015 40 commits
-
-
Michal Hocko authored
commit 45f87de5 upstream. Commit 2457aec6 ("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 <david@fromorbit.com> Signed-off-by:
Michal Hocko <mhocko@suse.cz> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sasha Levin authored
commit a3a87844 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 <sasha.levin@oracle.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Suman Tripathi authored
commit 5c0b8e0d upstream. This patch fixes the big endian mode issue with function xgene_ahci_read_id. Signed-off-by:
Suman Tripathi <stripathi@apm.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Andy Shevchenko authored
commit 4aaa7187 upstream. DMA mapped IO should be unmapped on the error path in probe() and unconditionally on remove(). Fixes: 62936009 ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex) Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Bryan O'Donoghue authored
commit 38a1dfda upstream. Commit 0dbc6078 ('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 0dbc6078 'x86, build, pci: Fix PCI_MSI build on !SMP' Signed-off-by:
Bryan O'Donoghue <pure.logic@nexus-software.ie> Suggested-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: http://lkml.kernel.org/r/1421967529-9037-1-git-send-email-pure.logic@nexus-software.ieSigned-off-by:
-
Andy Lutomirski authored
commit 3669ef9f 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: 41bdc785 x86/tls: Validate TLS entries to protect espfix Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Cc: torvalds@linux-foundation.org Link: http://lkml.kernel.org/r/0cb251abe1ff0958b8e468a9a9a905b80ae3a746.1421954363.git.luto@amacapital.netSigned-off-by:
-
Andy Lutomirski authored
commit e30ab185 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: 41bdc785 x86/tls: Validate TLS entries to protect espfix Signed-off-by:
-
Nadav Amit authored
commit 63ea0a49 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 <namit@cs.technion.ac.il> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Nadav Amit authored
commit f3747379 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:
-
Kees Cook authored
commit f285f4a2 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 <bhe@redhat.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Tested-by:
Thomas D. <whissi@whissi.de> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: Junjie Mao <eternal.n08@gmail.com> Cc: Andi Kleen <ak@linux.intel.com> Link: http://lkml.kernel.org/r/20150116005146.GA4212@www.outflux.netSigned-off-by:
-
Alexandre Demers authored
commit 52045217 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: c767a54b x86/debug: Add KERN_<LEVEL> to bare printks, convert printks to pr_<level> Signed-off-by:
Alexandre Demers <alexandre.f.demers@gmail.com> Link: http://lkml.kernel.org/r/1418106470-6906-1-git-send-email-alexandre.f.demers@gmail.comSigned-off-by:
-
K. Y. Srinivasan authored
commit 32c6590d upstream. The Hyper-V clocksource is continuous; mark it accordingly. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> 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.comSigned-off-by:
-
Tobias Jakobi authored
commit 8c38d28b 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 <kgene.kim@samsung.com> Reported-by:
GP Orcullo <kinsamanka@gmail.com> Reviewed-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Jan Beulich authored
commit 4a0d3107 upstream. The mis-naming likely was a copy-and-paste effect. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Link: http://lkml.kernel.org/r/54B9408B0200007800055E8B@mail.emea.novell.comSigned-off-by:
-
Gavin Li authored
commit 91d11792 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 <gavinli@thegavinli.com> Acked-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Link: https://lkml.kernel.org/r/1420598843-8409-1-git-send-email-gavinli@thegavinli.comSigned-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Al Viro authored
commit 378ff1a5 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 <viro@zeniv.linux.org.uk> Signed-off-by:
-
Andrew Lunn authored
commit 38bdf45f 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: fddddb52 ("bus: introduce an Marvell EBU MBus driver") Reviewed-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Thomas Petazzoni authored
commit 8f1e8ee2 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:
-
Fabio Estevam authored
commit 7ecd0bde 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 <csotoalonso@gmail.com> Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Sasha Levin authored
commit 5e5aeb43 upstream. Verify that the frequency value from userspace is valid and makes sense. Unverified values can cause overflows later on. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Sasha Levin authored
commit 6ada1fc0 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 <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Felipe Balbi authored
commit 4b149e41 upstream. commit 55601c9f (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: 55601c9f (arm: omap: intc: switch over to linear irq domain) Tested-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Link: https://lkml.kernel.org/r/1420576688-10604-1-git-send-email-balbi@ti.comSigned-off-by:
-
Joe Thornber authored
commit a59db676 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 <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Joe Thornber authored
commit 9b1cc9f2 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:
-
Hans Verkuil authored
commit 6cf11ee6 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 <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Matthias Schwarzott authored
commit 721f3223 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 36efec48 ([media] cx23885: Add si2165 support for HVR-5500) Signed-off-by:
Matthias Schwarzott <zzam@gentoo.org> Tested-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Brian King authored
commit 6cdb0817 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 <brking@linux.vnet.ibm.com> Reviewed-by:
Wendy Xiong <wenxiong@linux.vnet.ibm.com> Tested-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Alex Williamson authored
commit c3e59ee4 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 425c1b22 ("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.orgReported-by:
Andreas Hartmann <andihartmann@freenet.de> Tested-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Alex Williamson authored
commit f331a859 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.orgSigned-off-by:
-
Yinghai Lu authored
commit 851b0936 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=85491Reported-by:
Marek Kordik <kordikmarek@gmail.com> Tested-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
-
Yinghai Lu authored
commit 0f7e7aee 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=85491Reported-by:
-
Yinghai Lu authored
commit 8505e729 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 5b285415, 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=85491Reported-by:
-
Yinghai Lu authored
commit 3f2f4dc4 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=85491Reported-by:
-
Alex Deucher authored
commit d8a74e18 upstream. This was accidently lost in 76a0df85. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 5615f890 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 authored
commit 4369a69e 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:
-
Chris Wilson authored
commit 226e5ae9 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=87955Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Chris Wilson authored
commit 48bf5b2d upstream. Like Ivybridge, we have reports that we get random hangs when flipping with multiple pipes. Extend commit 2a92d5bc Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jul 8 10:40:29 2014 +0100 drm/i915: Disable RCS flips on Ivybridge to also apply to Haswell. Reported-and-tested-by:
Scott Tsai <scottt.tw@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87759Signed-off-by:
-
Michael Karcher authored
commit 1caf6aaa 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 directory Link: 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.de Cc: Matt Fleming <matt@console-pimps.org> Reported-by:
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by:
Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Tejun Heo authored
commit 29187a9e 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:
Eric Sandeen <sandeen@sandeen.net> Link: http://lkml.kernel.org/g/54B019F4.8030009@sandeen.net Cc: Dave Chinner <david@fromorbit.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by:
-
