- 05 Mar, 2014 40 commits
-
-
Jan Kara authored
commit 1362f4ea upstream. Currently last dqput() can race with dquot_scan_active() causing it to call callback for an already deactivated dquot. The race is as follows: CPU1 CPU2 dqput() spin_lock(&dq_list_lock); if (atomic_read(&dquot->dq_count) > 1) { - not taken if (test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) { spin_unlock(&dq_list_lock); ->release_dquot(dquot); if (atomic_read(&dquot->dq_count) > 1) - not taken dquot_scan_active() spin_lock(&dq_list_lock); if (!test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) - not taken atomic_inc(&dquot->dq_count); spin_unlock(&dq_list_lock); - proceeds to release dquot ret = fn(dquot, priv); - called for inactive dquot Fix the problem by making sure possible ->release_dquot() is finished by the time we call the callback and new calls to it will notice reference dquot_scan_active() has taken and bail out. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Dan Williams authored
commit da87ca4d upstream. Since commit 77873803 "net_dma: mark broken" we no longer pin dma engines active for the network-receive-offload use case. As a result the ->free_chan_resources() that occurs after the driver self test no longer has a NET_DMA induced ->alloc_chan_resources() to back it up. A late firing irq can lead to ksoftirqd spinning indefinitely due to the tasklet_disable() performed by ->free_chan_resources(). Only ->alloc_chan_resources() can clear this condition in affected kernels. This problem has been present since commit 3e037454 "I/OAT: Add support for MSI and MSI-X" in 2.6.24, but is now exposed. Given the NET_DMA use case is deprecated we can revisit moving the driver to use threaded irqs. For now, just tear down the irq and tasklet properly by: 1/ Disable the irq from triggering the tasklet 2/ Disable the irq from re-arming 3/ Flush inflight interrupts 4/ Flush the timer 5/ Flush inflight tasklets References: https://lkml.org/lkml/2014/1/27/282 https://lkml.org/lkml/2014/2/19/672 Cc: Ingo Molnar <mingo@elte.hu> Cc: Steven Rostedt <rostedt@goodmis.org> Reported-by:
Mike Galbraith <bitbucket@online.de> Reported-by:
Stanislav Fomichev <stfomichev@yandex-team.ru> Tested-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Eric Paris authored
commit 9085a642 upstream. When writing policy via /sys/fs/selinux/policy I wrote the type and class of filename trans rules in CPU endian instead of little endian. On x86_64 this works just fine, but it means that on big endian arch's like ppc64 and s390 userspace reads the policy and converts it from le32_to_cpu. So the values are all screwed up. Write the values in le format like it should have been to start. Signed-off-by:
Eric Paris <eparis@redhat.com> Acked-by:
Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
-
Max Filippov authored
commit e2fd1374 upstream. Most in-kernel users want registers spilled on the kernel stack and don't require PS.EXCM to be set. That means that they don't need fixup routine and could reuse regular window overflow mechanism for that, which makes spill routine very simple. Suggested-by:
Chris Zankel <chris@zankel.net> Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Max Filippov authored
commit 3251f1e2 upstream. We need it saved because it contains a3 where we track which register windows we still need to spill, and fixup handler may call C exception handlers. Also fix comments. Signed-off-by:
-
Andrew Lunn authored
commit d86e9af6 upstream. Enabling SPARSE_IRQ shows up a bug in the irq-orion bridge interrupt handler. The bridge interrupt is implemented using a single generic chip. Thus the parameter passed to irq_get_domain_generic_chip() should always be zero. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Acked-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Fixes: 9dbd90f1 ("irqchip: Add support for Marvell Orion SoCs") Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Sebastian Hesselbarth authored
commit e0318ec3 upstream. Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear them before unmask. This installs an .irq_startup callback to ensure stale irqs are cleared before initial unmask. Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by:
-
Sebastian Hesselbarth authored
commit 5f40067f upstream. Bridge irqs are edge-triggered, i.e. they get asserted on low-to-high transitions and not on the level of the downstream interrupt line. This replaces handle_level_irq by the more appropriate handle_edge_irq. Signed-off-by:
-
Sebastian Hesselbarth authored
commit 7b119fd1 upstream. It is good practice to mask and clear pending irqs on init. We already mask all irqs, so also clear the bridge irq cause register. Signed-off-by:
-
Takashi Iwai authored
commit 37c367ec upstream. HP Folio 13 may have a broken BIOS that doesn't set up the mute LED GPIO properly, and the driver guesses it wrongly, too. Add a new fixup entry for setting the GPIO pin statically for this laptop. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70991Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Peter Zijlstra authored
commit e3703f8c upstream. Drew Richardson reported that he could make the kernel go *boom* when hotplugging while having perf events active. It turned out that when you have a group event, the code in __perf_event_exit_context() fails to remove the group siblings from the context. We then proceed with destroying and freeing the event, and when you re-plug the CPU and try and add another event to that CPU, things go *boom* because you've still got dead entries there. Reported-by:
Drew Richardson <drew.richardson@arm.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Link: http://lkml.kernel.org/n/tip-k6v5wundvusvcseqj1si0oz0@git.kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Will Deacon authored
commit 57ca90f6 upstream. Whilst trying to bring-up an SMMUv2 implementation with the table walker plumbed into a coherent interconnect, I noticed that the memory transactions targetting the CPU caches from the SMMU were marked as outer-shareable instead of inner-shareable. After a bunch of digging, it seems that we actually need to program CBARn.BPSHCFG for s1-s2-bypass contexts to act as non-shareable in order for the shareability configured in the corresponding TTBCR not to be overridden with an outer-shareable attribute. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Will Deacon authored
commit c9d09e27 upstream. Commit a44a9791 ("iommu/arm-smmu: use mutex instead of spinlock for locking page tables") replaced the page table spinlock with a mutex, to allow blocking allocations to satisfy lazy mapping requests. Unfortunately, it turns out that IOMMU mappings are created from atomic context (e.g. spinlock held during a dma_map), so this change doesn't really help us in practice. This patch is a partial revert of the offending commit, bringing back the original spinlock but replacing our page table allocations for any levels below the pgd (which is allocated during domain init) with GFP_ATOMIC instead of GFP_KERNEL. Reported-by:
Andreas Herrmann <andreas.herrmann@calxeda.com> Signed-off-by:
-
Yifan Zhang authored
commit 97a64420 upstream. The ARM SMMU driver's population of puds and pmds is broken, since we iterate over the next level of table repeatedly setting the current level descriptor to point at the pmd being initialised. This is clearly wrong when dealing with multiple pmds/puds. This patch fixes the problem by moving the pud/pmd population out of the loop and instead performing it when we allocate the next level (like we correctly do for ptes already). The starting address for the next level is then calculated prior to entering the loop. Signed-off-by:
Yifan Zhang <zhangyf@marvell.com> Signed-off-by:
-
Denis CIOCCA authored
commit a0657716 upstream. The driver was not able to manage the sensor: during probe function and wai check, the driver stops and writes: "device name and WhoAmI mismatch." The correct value of L3GD20H wai is 0xd7 instead of 0xd4. Dropped support for the sensor. Signed-off-by:
Denis Ciocca <denis.ciocca@st.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Manu Gupta authored
commit 260ea9c2 upstream. The D-Link DWA-123 REV D1 with USB ID 2001:3310 uses this driver. Signed-off-by:
Manu Gupta <manugupt1@gmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Arve Hjønnevåg authored
commit e194fd8a upstream. The change (008fa749) that moved the node release code to a separate function broke death notifications in some cases. When it encountered a reference without a death notification request, it would skip looking at the remaining references, and therefore fail to send death notifications for them. Cc: Colin Cross <ccross@android.com> Cc: Android Kernel Team <kernel-team@android.com> Signed-off-by:
Arve Hjønnevåg <arve@android.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Jeremy Compostella <jeremy.compostella@intel.com> Signed-off-by:
-
Steve Twiss authored
commit ebf6dad0 upstream. Bug fix to allow the setting of maximum voltage for certain LDOs. What the bug is: There is a problem caused by an invalid calculation of n_voltages in the driver. This n_voltages value has the potential to be different for each regulator. The value for linear_min_sel is set as DA9063_V##regl_name# which can be different depending upon the regulator. This is chosen according to the following definitions in the DA9063 registers.h file: DA9063_VLDO1_BIAS 0 DA9063_VLDO2_BIAS 0 DA9063_VLDO3_BIAS 0 DA9063_VLDO4_BIAS 0 DA9063_VLDO5_BIAS 2 DA9063_VLDO6_BIAS 2 DA9063_VLDO7_BIAS 2 DA9063_VLDO8_BIAS 2 DA9063_VLDO9_BIAS 3 DA9063_VLDO10_BIAS 2 DA9063_VLDO11_BIAS 2 The calculation for n_voltages is valid for LDOs whose BIAS value is zero but this is not correct for those LDOs which have a non-zero value. What the fix is: In order to take into account the non-zero linear_min_sel value which is set for the regulators LDO5, LDO6, LDO7, LDO8, LDO9, LDO10 and LDO11, the calculation for n_voltages should take into account the missing term defined by DA9063_V##regl_name#. This will in turn allow the core constraints calculation to set the maximum voltage limits correctly and therefore allow users to apply the maximum expected voltage to all of the LDOs. Signed-off-by:
Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Lai Jiangshan authored
commit 5bdfff96 upstream. When a kworker should die, the kworkre is notified through WORKER_DIE flag instead of kthread_should_stop(). This, IIRC, is primarily to keep the test synchronized inside worker_pool lock. WORKER_DIE is first set while holding pool->lock, the lock is dropped and kthread_stop() is called. Unfortunately, this means that there's a slight chance that the target kworker may see WORKER_DIE before kthread_stop() finishes and exits and frees the target task before or during kthread_stop(). Fix it by pinning the target task before setting WORKER_DIE and putting it after kthread_stop() is done. tj: Improved patch description and comment. Moved pinning above WORKER_DIE for better signify what it's protecting. Signed-off-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Guenter Roeck authored
commit 500a9157 upstream. When trying to set the minimum temperature, the driver was erroneously writing the maximum temperature into the chip. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
-
Chao Bi authored
commit accb884b upstream. In mei_cl_read_start(), if it fails to send flow control request, it will release "cl->read_cb" but forget to set pointer to NULL, leaving "cl->read_cb" still pointing to random memory, next time this client is operated like mei_release(), it has chance to refer to this wrong pointer. Fixes: PANIC at kfree in mei_release() [228781.826904] Call Trace: [228781.829737] [<c16249b8>] ? mei_cl_unlink+0x48/0xa0 [228781.835283] [<c1624487>] mei_io_cb_free+0x17/0x30 [228781.840733] [<c16265d8>] mei_release+0xa8/0x180 [228781.845989] [<c135c610>] ? __fsnotify_parent+0xa0/0xf0 [228781.851925] [<c1325a69>] __fput+0xd9/0x200 [228781.856696] [<c1325b9d>] ____fput+0xd/0x10 [228781.861467] [<c125cae1>] task_work_run+0x81/0xb0 [228781.866821] [<c1242e53>] do_exit+0x283/0xa00 [228781.871786] [<c1a82b36>] ? kprobe_flush_task+0x66/0xc0 [228781.877722] [<c124eeb8>] ? __dequeue_signal+0x18/0x1a0 [228781.883657] [<c124f072>] ? dequeue_signal+0x32/0x190 [228781.889397] [<c1243744>] do_group_exit+0x34/0xa0 [228781.894750] [<c12517b6>] get_signal_to_deliver+0x206/0x610 [228781.901075] [<c12018d8>] do_signal+0x38/0x100 [228781.906136] [<c1626d1c>] ? mei_read+0x42c/0x4e0 [228781.911393] [<c12600a0>] ? wake_up_bit+0x30/0x30 [228781.916745] [<c16268f0>] ? mei_poll+0x120/0x120 [228781.922001] [<c1324be9>] ? vfs_read+0x89/0x160 [228781.927158] [<c16268f0>] ? mei_poll+0x120/0x120 [228781.932414] [<c133ca34>] ? fget_light+0x44/0xe0 [228781.937670] [<c1324e58>] ? SyS_read+0x68/0x80 [228781.942730] [<c12019f5>] do_notify_resume+0x55/0x70 [228781.948376] [<c1a7de5d>] work_notifysig+0x29/0x30 [228781.953827] [<c1a70000>] ? bad_area+0x5/0x3e Signed-off-by:
Chao Bi <chao.bi@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Joerg Dorchain authored
commit 6dbd46c8 upstream. Hello, the following patch adds an entry for the PID of a Cressi Leonardo diving computer interface to kernel 3.13.0. It is detected as FT232RL. Works with subsurface. Signed-off-by:
Joerg Dorchain <joerg@dorchain.net> Signed-off-by:
-
Stanislaw Gruszka authored
commit a1227f3c upstream. ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when threadirqs option is used. To prevent the deadlock use spin_lock_irqsave() in ehci_irq(). This change can be reverted when hrtimer callbacks become threaded. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
commit 3e8d6d85 upstream. High-speed USB connections revert back to full-speed signalling when the device goes into suspend. This takes several milliseconds, and during that time it's not possible to tell reliably whether the device has been disconnected. On some platforms, the Wake-On-Disconnect circuitry gets confused during this intermediate state. It generates a false wakeup signal, which can prevent the controller from going to sleep. To avoid this problem, this patch adds a 5-ms delay to the ehci_bus_suspend() routine if any ports have to switch over to full-speed signalling. (Actually, the delay was already present for devices using a particular kind of PHY power management; the patch merely causes the delay to be used more widely.) Signed-off-by:
Peter Chen <Peter.Chen@freescale.com> Signed-off-by:
-
Aleksander Morgado authored
commit 12df84d4 upstream. This interface is to be handled by the qmi_wwan driver. CC: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com> CC: Christian Schmiedl <christian.schmiedl@gemalto.com> CC: Nicolaus Colberg <nicolaus.colberg@gemalto.com> CC: David McCullough <david.mccullough@accelecon.com> Signed-off-by:
Aleksander Morgado <aleksander@aleksander.es> Signed-off-by:
-
Florian Fainelli authored
commit 2d1f7af3 upstream. Commit 3dc6475c ("bcm63xx_enet: add support Broadcom BCM6345 Ethernet") changed the ENETDMA[CS] macros such that they are no longer macros, but actual register offset definitions. The bcm63xx_udc driver was not updated, and as a result, causes the following build error to pop up: CC drivers/usb/gadget/u_ether.o drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_write': drivers/usb/gadget/bcm63xx_udc.c:642:24: error: called object '0' is not a function drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_reset_channel': drivers/usb/gadget/bcm63xx_udc.c:698:46: error: called object '0' is not a function drivers/usb/gadget/bcm63xx_udc.c:700:49: error: called object '0' is not a function Fix this by updating usb_dmac_{read,write}l and usb_dmas_{read,write}l to take an extra channel argument, and use the channel width (ENETDMA_CHAN_WIDTH) to offset the register we want to access, hence doing again what the macro implicitely did for us. Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Jonas Gorski <jogo@openwrt.org> Signed-off-by:
Florian Fainelli <florian@openwrt.org> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Matthieu CASTET authored
commit 5bf5dbed upstream. ENDPTFLUSH and ENDPTPRIME registers are set by software and clear by hardware. There is a bit for each endpoint. When we are setting a bit for an endpoint we should make sure we do not touch other endpoint bit. There is a race condition if the hardware clear the bit between the read and the write in hw_write. Signed-off-by:
Matthieu CASTET <matthieu.castet@parrot.com> Tested-by:
Michael Grzeschik <mgrzeschik@pengutronix.de> Signed-off-by:
-
Olivier Sobrie authored
commit 862474f8 upstream. It is needed to check the number of channels returned by the HW because it cannot be greater than MAX_NET_DEVICES otherwise it will crash. Signed-off-by:
Olivier Sobrie <olivier@sobrie.be> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Lan Tianyu authored
commit f3ca4164 upstream. acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make sure that the (struct acpi_processor)->acpi_processor_set_throttling() callback will run on the right CPU. However, the function may be called from a worker thread already bound to a different CPU in which case that won't work. Make acpi_processor_set_throttling() use work_on_cpu() as appropriate instead of abusing set_cpus_allowed_ptr(). Reported-and-tested-by:
Jiri Olsa <jolsa@redhat.com> Signed-off-by:
Lan Tianyu <tianyu.lan@intel.com> [rjw: Changelog] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Hans de Goede authored
commit bd8ba205 upstream. Some devices have duplicate entries in there brightness levels table, ie on my Dell Latitude E6430 the table looks like this: [ 3.686060] acpi backlight index 0, val 80 [ 3.686095] acpi backlight index 1, val 50 [ 3.686122] acpi backlight index 2, val 5 [ 3.686147] acpi backlight index 3, val 5 [ 3.686172] acpi backlight index 4, val 5 [ 3.686197] acpi backlight index 5, val 5 [ 3.686223] acpi backlight index 6, val 5 [ 3.686248] acpi backlight index 7, val 5 [ 3.686273] acpi backlight index 8, val 6 [ 3.686332] acpi backlight index 9, val 7 [ 3.686356] acpi backlight index 10, val 8 [ 3.686380] acpi backlight index 11, val 9 etc. Notice that brightness values 0-5 are all mapped to 5. This means that if userspace writes any value between 0 and 5 to the brightness sysfs attribute and then reads it, it will always return 0, which is somewhat unexpected. This is a problem for ie gnome-settings-daemon, which uses read-modify-write logic when the users presses the brightness up or down keys. This is done this way to take brightness changes from other sources into account. On this specific laptop what happens once the brightness has been set to 0, is that gsd reads 0, adds 5, writes 5, and on the next brightness up key press again reads 0, so things get stuck at the lowest brightness setting. Filtering out the duplicate table entries, makes any write to brightness read back as the written value as one would expect, fixing this. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
-
Jean Delvare authored
commit c0f5eeed upstream. The reference count changes done by pci_get_device can be a little misleading when the usage diverges from the most common scheme. The reference count of the device passed as the last parameter is always decreased, even if the function returns no new device. So if we are going to try alternative device IDs, we must manually increment the device reference count before each retry. If we don't, we end up decreasing the reference count, and after a few modprobe/rmmod cycles the PCI devices will vanish. In other words and as Alan put it: without this fix the EDAC code corrupts the PCI device list. This fixes kernel bug #50491: https://bugzilla.kernel.org/show_bug.cgi?id=50491Signed-off-by:
Alan Cox <alan@linux.intel.com> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: Doug Thompson <dougthompson@xmission.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Tomasz Nowicki authored
commit b685f3b1 upstream. acpi_pci_link_allocate_irq() can return negative gsi even if entry != NULL. For that case we have a memory leak, so free entry before returning from acpi_pci_irq_enable() for gsi < 0. Signed-off-by:
Tomasz Nowicki <tomasz.nowicki@linaro.org> [rjw: Subject and changelog] Signed-off-by:
-
Bjorn Helgaas authored
commit 1f42db78 upstream. Some firmware leaves the Interrupt Disable bit set even if the device uses INTx interrupts. Clear Interrupt Disable so we get those interrupts. Based on the report mentioned below, if the user selects the "EHCI only" option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS with the PCI_COMMAND_INTX_DISABLE bit set. Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601Reported-by:
Chris Cheng <chris.cheng@atrustcorp.com> Reported-and-tested-by:
Jamie Chen <jamie.chen@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Andrew Lunn authored
commit 322a8e91 upstream. Marvell SoCs place the SoC number into the PCIe endpoint device ID. The SoC stepping is placed into the PCIe revision. The old plat-orion PCIe driver allowed this information to be seen in user space with a simple lspci command. The new driver places a virtual PCI-PCI bridge on top of these endpoints. It has its own hard coded PCI device ID. Thus it is no longer possible to see what the SoC is using lspci. When initializing the PCI-PCI bridge, set its device ID and revision from the underlying endpoint, thus restoring this functionality. Debian would like to use this in order to aid installing the correct DTB file. Fixes: 45361a4f ("pci: PCIe driver for Marvell Armada 370/XP systems") Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by:
-
Srivatsa S. Bhat authored
commit c3274763 upstream. The powernow-k8 driver maintains a per-cpu data-structure called powernow_data that is used to perform the frequency transitions. It initializes this data structure only for the policy->cpu. So, accesses to this data structure by other CPUs results in various problems because they would have been uninitialized. Specifically, if a cpu (!= policy->cpu) invokes the drivers' ->get() function, it returns 0 as the KHz value, since its per-cpu memory doesn't point to anything valid. This causes problems during suspend/resume since cpufreq_update_policy() tries to enforce this (0 KHz) as the current frequency of the CPU, and this madness gets propagated to adjust_jiffies() as well. Eventually, lots of things start breaking down, including the r8169 ethernet card, in one particularly interesting case reported by Pierre Ossman. Fix this by initializing the per-cpu data-structures of all the CPUs in the policy appropriately. References: https://bugzilla.kernel.org/show_bug.cgi?id=70311Reported-by:
Pierre Ossman <pierre@ossman.eu> Signed-off-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Tejun Heo authored
commit 9f9c47f0 upstream. It's a bit odd to see a newer device showing mod15write; however, the reported behavior is highly consistent and other factors which could contribute seem to have been verified well enough. Also, both sata_sil itself and the drive are fairly outdated at this point making the risk of this change fairly low. It is possible, probably likely, that other drive models in the same family have the same problem; however, for now, let's just add the specific model which was tested. Signed-off-by:
matson <lists-matsonpa@luxsci.me> References: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.comSigned-off-by:
-
Denis V. Lunev authored
commit efb9e0f4 upstream. Without the patch the kernel generates the following error. ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123' ata11.15: PMP revalidation failed (errno=-19) ata11.15: failed to recover PMP after 5 tries, giving up This patch helps to bypass this error and the device becomes functional. Signed-off-by:
Denis V. Lunev <den@openvz.org> Signed-off-by:
-
Peter Zijlstra authored
commit 26e61e89 upstream. Vince "Super Tester" Weaver reported a new round of syscall fuzzing (Trinity) failures, with perf WARN_ON()s triggering. He also provided traces of the failures. This is I think the relevant bit: > pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_disable: x86_pmu_disable > pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_state: Events: { > pec_1076_warn-2804 [000] d... 147.926156: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null)) > pec_1076_warn-2804 [000] d... 147.926158: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926159: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926160: x86_pmu_state: n_events: 1, n_added: 0, n_txn: 1 > pec_1076_warn-2804 [000] d... 147.926161: x86_pmu_state: Assignment: { > pec_1076_warn-2804 [000] d... 147.926162: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926163: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926166: collect_events: Adding event: 1 (ffff880119ec8800) So we add the insn:p event (fd[23]). At this point we should have: n_events = 2, n_added = 1, n_txn = 1 > pec_1076_warn-2804 [000] d... 147.926170: collect_events: Adding event: 0 (ffff8800c9e01800) > pec_1076_warn-2804 [000] d... 147.926172: collect_events: Adding event: 4 (ffff8800cbab2c00) We try and add the {BP,cycles,br_insn} group (fd[3], fd[4], fd[15]). These events are 0:cycles and 4:br_insn, the BP event isn't x86_pmu so that's not visible. group_sched_in() pmu->start_txn() /* nop - BP pmu */ event_sched_in() event->pmu->add() So here we should end up with: 0: n_events = 3, n_added = 2, n_txn = 2 4: n_events = 4, n_added = 3, n_txn = 3 But seeing the below state on x86_pmu_enable(), the must have failed, because the 0 and 4 events aren't there anymore. Looking at group_sched_in(), since the BP is the leader, its event_sched_in() must have succeeded, for otherwise we would not have seen the sibling adds. But since neither 0 or 4 are in the below state; their event_sched_in() must have failed; but I don't see why, the complete state: 0,0,1:p,4 fits perfectly fine on a core2. However, since we try and schedule 4 it means the 0 event must have succeeded! Therefore the 4 event must have failed, its failure will have put group_sched_in() into the fail path, which will call: event_sched_out() event->pmu->del() on 0 and the BP event. Now x86_pmu_del() will reduce n_events; but it will not reduce n_added; giving what we see below: n_event = 2, n_added = 2, n_txn = 2 > pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_enable: x86_pmu_enable > pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_state: Events: { > pec_1076_warn-2804 [000] d... 147.926179: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null)) > pec_1076_warn-2804 [000] d... 147.926181: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926182: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: n_events: 2, n_added: 2, n_txn: 2 > pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: Assignment: { > pec_1076_warn-2804 [000] d... 147.926186: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: 1->0 tag: 1 config: 1 (ffff880119ec8800) > pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926190: x86_pmu_enable: S0: hwc->idx: 33, hwc->last_cpu: 0, hwc->last_tag: 1 hwc->state: 0 So the problem is that x86_pmu_del(), when called from a group_sched_in() that fails (for whatever reason), and without x86_pmu TXN support (because the leader is !x86_pmu), will corrupt the n_added state. Reported-and-Tested-by:
Vince Weaver <vincent.weaver@maine.edu> Signed-off-by:
-
Marek Szyprowski authored
commit c091c71a upstream. GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other flags, where meaningful is the LACK of __GFP_WAIT flag. To check if caller wants to perform an atomic allocation, the code must test for a lack of the __GFP_WAIT flag. This patch fixes the issue introduced in v3.5-rc1. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Levente Kurusa authored
commit 67809f85 upstream. Samsung's pci-e SSDs with device ID 0x1600 which are found on some macbooks time out on NCQ commands. Blacklist NCQ on the device so that the affected machines can at least boot. Original-patch-by:
Levente Kurusa <levex@linux.com> Signed-off-by:
-
