commit a0fb6543b40f216f72ef57ff3f61df918047c0fc
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Wed Aug 16 13:47:18 2017 -0700
Linux 4.12.8
commit 1d4efdd222c4fdf1fd91937fad5c57c78dff4fc1
Author: Michael Neuling <mikey@neuling.org>
Date: Thu Jun 15 11:53:16 2017 +1000
powerpc: Fix /proc/cpuinfo revision for POWER9 DD2
commit 64ebb9a208c6e66316329a6d9101815d1ee06fa9 upstream.
The P9 PVR bits 12-15 don't indicate a revision but instead different
chip configurations. From BookIV we have:
Bits Configuration
0 : Scale out 12 cores
1 : Scale out 24 cores
2 : Scale up 12 cores
3 : Scale up 24 cores
DD1 doesn't use this but DD2 does. Linux will mostly use the "Scale
out 24 core" configuration (ie. SMT4 not SMT8) which results in a PVR
of 0x004e1200. The reported revision in /proc/cpuinfo is hence
reported incorrectly as "18.0".
This patch fixes this to mask off only the relevant bits for the major
revision (ie. bits 8-11) for POWER9.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d40a5450000866c4c5c475bc275042c241953fed
Author: Steven J. Hill <Steven.Hill@cavium.com>
Date: Wed Aug 2 12:39:28 2017 -0500
MIPS: Octeon: Fix broken EDAC driver.
commit 81a67e52763d1db6b3200c648d1efa16daddc536 upstream.
Commit "MIPS: Octeon: Remove unused L2C types and macros." broke the
the EDAC driver. Bring back 'cvmx-l2d-defs.h' file and the missing
types for L2C. Fixes: 15f6847923a8 ("MIPS: Octeon: Remove unused L2C
types and macros.")
Fixes: 15f6847923a8 ("MIPS: Octeon: Remove unused L2C types and macros.")
Signed-off-by: Steven J. Hill <steven.hill@cavium.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16906/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bc60edb6aa3f559bd2b10e9639ad054e2877c7b6
Author: Paul Burton <paul.burton@imgtec.com>
Date: Tue Aug 1 13:32:57 2017 -0700
Revert "MIPS: Don't unnecessarily include kmalloc.h into <asm/cache.h>."
commit ae5b0675942ab30cde96099c68a2290bd1aafcca upstream.
Commit 296e46db0073 ("MIPS: Don't unnecessarily include kmalloc.h into
<asm/cache.h>.") claimed that the inclusion of the machine's kmalloc.h
from asm/cache.h is unnecessary, but this is not true.
Without including kmalloc.h we don't get a definition for
ARCH_DMA_MINALIGN, which means we no longer suitably align DMA. Further
to this the definition of ARCH_KMALLOC_MINALIGN provided by linux/slab.h
ends up being set to the alignment of an unsigned long long value rather
than to ARCH_DMA_MINALIGN, which means that buffers allocated using
kmalloc may no longer be safely aligned for use with DMA.
Fix this by re-adding the include of kmalloc.h in asm/cache.h. This
reverts commit 296e46db0073 ("MIPS: Don't unnecessarily include
kmalloc.h into <asm/cache.h>.")
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 296e46db0073 ("MIPS: Don't unnecessarily include kmalloc.h into <asm/cache.h>.")
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16895/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0a5a16f6cefdd3eea80d96fe7e9df5e7aae0769a
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date: Sun Jul 30 21:28:15 2017 +0100
MIPS: DEC: Fix an int-handler.S CPU_DADDI_WORKAROUNDS regression
commit 68fe55680d0f3342969f49412fceabb90bdfadba upstream.
Fix a commit 3021773c7c3e ("MIPS: DEC: Avoid la pseudo-instruction in
delay slots") regression and remove assembly errors:
arch/mips/dec/int-handler.S: Assembler messages:
arch/mips/dec/int-handler.S:162: Error: Macro used $at after ".set noat"
arch/mips/dec/int-handler.S:163: Error: Macro used $at after ".set noat"
arch/mips/dec/int-handler.S:229: Error: Macro used $at after ".set noat"
arch/mips/dec/int-handler.S:230: Error: Macro used $at after ".set noat"
triggering with with the CPU_DADDI_WORKAROUNDS option set and the DADDIU
instruction. This is because with that option in place the instruction
becomes a macro, which expands to an LI/DADDU (or actually ADDIU/DADDU)
sequence that uses $at as a temporary register.
With CPU_DADDI_WORKAROUNDS we only support `-msym32' compilation though,
and this is already enforced in arch/mips/Makefile, so choose the 32-bit
expansion variant for the supported configurations and then replace the
64-bit variant with #error just in case.
Fixes: 3021773c7c3e ("MIPS: DEC: Avoid la pseudo-instruction in delay slots")
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16893/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 888986477133a05348b7f19b628a8941c6032f9c
Author: Neil Armstrong <narmstrong@baylibre.com>
Date: Tue May 23 16:09:18 2017 +0200
pinctrl: meson-gxl: Add missing GPIODV_18 pin entry
commit aa9556956653f85baaadeb4846dc571414f13e36 upstream.
GPIODV_18 entry was missing in the original driver push.
Fixes: 0f15f500ff2c ("pinctrl: meson: Add GXL pinctrl definitions")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d7b28b4cae66ffdd752bc5b88cf483efe18f5ea6
Author: Neil Armstrong <narmstrong@baylibre.com>
Date: Tue May 23 16:09:19 2017 +0200
pinctrl: meson-gxbb: Add missing GPIODV_18 pin entry
commit 34e61801a3b9df74b69f0e359d64a197a77dd6ac upstream.
GPIODV_18 entry was missing in the original driver push.
Fixes: 468c234f9ed7 ("pinctrl: amlogic: Add support for Amlogic Meson GXBB SoC")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 155407bbf9f21414881e9157d8e43aee3243f91e
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Jun 29 23:33:35 2017 +0200
pinctrl: samsung: Remove bogus irq_[un]mask from resource management
commit 3fa53ec2ed885b0aec3f0472e3b4a8a6f1cd748c upstream.
The irq chip callbacks irq_request/release_resources() have absolutely no
business with masking and unmasking the irq.
The core code unmasks the interrupt after complete setup and masks it
before invoking irq_release_resources().
The unmask is actually harmful as it happens before the interrupt is
completely initialized in __setup_irq().
Remove it.
Fixes: f6a8249f9e55 ("pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 21d22dffc34478d8112b65eaba5664fc80c8d35d
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Wed Jun 14 13:49:30 2017 +0900
pinctrl: uniphier: fix WARN_ON() of pingroups dump on LD20
commit 1bd303dc04c3f744474e77c153575087b657f7e1 upstream.
The pingroups dump of debugfs hits WARN_ON() in pinctrl_groups_show().
Filling non-existing ports with '-1' turned out a bad idea.
Fixes: 336306ee1f2d ("pinctrl: uniphier: add UniPhier PH1-LD20 pinctrl driver")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 338ac5dd59b9c682a63bdb8ad58a171ba06344be
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Wed Jun 14 13:49:29 2017 +0900
pinctrl: uniphier: fix WARN_ON() of pingroups dump on LD11
commit 9592bc256d50481dfcdba93890e576a728fb373c upstream.
The pingroups dump of debugfs hits WARN_ON() in pinctrl_groups_show().
Filling non-existing ports with '-1' turned out a bad idea.
Fixes: 70f2f9c4cf25 ("pinctrl: uniphier: add UniPhier PH1-LD11 pinctrl driver")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit be9f65893e3ba91716ad3a85bc4d438c87fb5af1
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri Aug 4 19:26:34 2017 +0300
pinctrl: intel: merrifield: Correct UART pin lists
commit 5d996132d921c391af5f267123eca1a6a3148ecd upstream.
UART pin lists consist GPIO numbers which is simply wrong.
Replace it by pin numbers.
Fixes: 4e80c8f50574 ("pinctrl: intel: Add Intel Merrifield pin controller support")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fa72b4b746aec106eb3cdfa4760a248e6f0d041
Author: Icenowy Zheng <icenowy@aosc.io>
Date: Sat Jul 22 10:50:53 2017 +0800
pinctrl: sunxi: add a missing function of A10/A20 pinctrl driver
commit d81ece747d8727bb8b1cfc9a20dbe62f09a4e35a upstream.
The PH16 pin has a function with mux id 0x5, which is the DET pin of the
"sim" (smart card reader) IP block.
This function is missing in old versions of A10/A20 SoCs' datasheets and
user manuals, so it's also missing in the old drivers. The newest A10
Datasheet V1.70 and A20 Datasheet V1.41 contain this pin function, and
it's discovered during implementing R40 pinctrl driver.
Add it to the driver. As we now merged A20 pinctrl driver to the A10
one, we need to only fix the A10 driver now.
Fixes: f2821b1ca3a2 ("pinctrl: sunxi: Move Allwinner A10 pinctrl
driver to a driver of its own")
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c75a48eed01f80ac0c17216fd5e404bb07f3a402
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue Jul 4 15:58:39 2017 +0300
pinctrl: cherryview: Add Setzer models to the Chromebook DMI quirk
commit 2d80bd3f7eb69204cd5dec4fa7fe7e12cbfaed13 upstream.
Add one more model to the Chromebook DMI quirk to make it working again.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=194945
Fixes: 2a8209fa6823 ("pinctrl: cherryview: Extend the Chromebook DMI quirk to Intel_Strago systems")
Reported-by: mail@abhishek.geek.nz
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cc7f330bed7139e8df059996160d8396708b8a18
Author: Christoph Hellwig <hch@lst.de>
Date: Sat Aug 5 10:59:14 2017 +0200
pnfs/blocklayout: require 64-bit sector_t
commit 8a9d6e964d318533ba3d2901ce153ba317c99a89 upstream.
The blocklayout code does not compile cleanly for a 32-bit sector_t,
and also has no reliable checks for devices sizes, which makes it
unsafe to use with a kernel that doesn't support large block devices.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing")
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e8a1edad18fae0a967a1225e242908412497ee61
Author: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
Date: Thu Jul 6 10:06:41 2017 +0100
iio: adc: vf610_adc: Fix VALT selection value for REFSEL bits
commit d466d3c1217406b14b834335b5b4b33c0d45bd09 upstream.
In order to select the alternate voltage reference pair (VALTH/VALTL), the
right value for the REFSEL field in the ADCx_CFG register is "01", leading
to 0x800 as register mask. See section 8.2.6.4 in the reference manual[1].
[1] http://www.nxp.com/docs/en/reference-manual/VFXXXRM.pdf
Fixes: a775427632fd ("iio:adc:imx: add Freescale Vybrid vf610 adc driver")
Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0e1f0eaed6c20db41ff61e024b361ee3ec9d686c
Author: Marc Zyngier <marc.zyngier@arm.com>
Date: Tue Aug 1 20:11:08 2017 -0500
xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue
commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 upstream.
The Renesas uPD72020x XHCI controller seems to suffer from a really
annoying bug, where it may retain some of its DMA programming across a XHCI
reset, and despite the driver correctly programming new DMA addresses.
This is visible if the device has been using 64-bit DMA addresses, and is
then switched to using 32-bit DMA addresses. The top 32 bits of the
address (now zero) are ignored are replaced by the 32 bits from the
*previous* programming. Sticking with 64-bit DMA always works, but doesn't
seem very appropriate.
A PCI reset of the device restores the normal functionality, which is done
at probe time. Unfortunately, this has to be done before any quirk has
been discovered, hence the intrusive nature of the fix.
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ea9647cf87f59a71845fc3b137772830812ff2cf
Author: Marc Zyngier <marc.zyngier@arm.com>
Date: Tue Aug 1 20:11:02 2017 -0500
PCI: Add pci_reset_function_locked()
commit a477b9cd37aa81a490dfa3265b7ff4f2c5a92463 upstream.
The implementation of PCI workarounds may require that the device is reset
from its probe function. This implies that the PCI device lock is already
held, and makes calling pci_reset_function() impossible (since it will
itself try to take that lock).
Add pci_reset_function_locked(), which is the equivalent of
pci_reset_function(), except that it requires the PCI device lock to be
already held by the caller.
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
[bhelgaas: folded in fix for conflict with 52354b9d1f46 ("PCI: Remove
__pci_dev_reset() and pci_dev_reset()")]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c71305e6854d9b16191be12944029f4f09948022
Author: Christoph Hellwig <hch@lst.de>
Date: Thu Jun 1 13:10:39 2017 +0200
PCI: Remove __pci_dev_reset() and pci_dev_reset()
commit 52354b9d1f46aae7386db7bb8ec8484b5488087f upstream.
Implement the reset probing / reset chain directly in
__pci_probe_reset_function() and __pci_reset_function_locked()
respectively.
Link: http://lkml.kernel.org/r/20170601111039.8913-4-hch@lst.de
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 31e71939a4dd66426da46f76d81e1eb33a817ad1
Author: Christoph Hellwig <hch@lst.de>
Date: Thu Jun 1 13:10:37 2017 +0200
PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()
commit b014e96d1abbd67404bbe2018937b46466299e9e upstream.
Every method in struct device_driver or structures derived from it like
struct pci_driver MUST provide exclusion vs the driver's ->remove() method,
usually by using device_lock().
Protect use of pci_error_handlers->reset_notify() by holding the device
lock while calling it.
Note:
- pci_dev_lock() calls device_lock() in addition to blocking user-space
config accesses.
- pci_err_handlers->reset_notify() is used inside
pci_dev_save_and_disable() and pci_dev_restore(). We could hold the
device lock directly in pci_reset_notify(), but we expand the region
since we have several calls following each other.
Without this, ->reset_notify() may race with ->remove() calls, which can be
easily triggered in NVMe.
[bhelgaas: changelog, add pci_reset_notify() comment]
[bhelgaas: fold in fix from Dan Carpenter <dan.carpenter@oracle.com>:
http://lkml.kernel.org/r/20170701135323.x5vaj4e2wcs2mcro@mwanda]
Link: http://lkml.kernel.org/r/20170601111039.8913-2-hch@lst.de
Reported-by: Rakesh Pandit <rakesh@tuxera.com>
Tested-by: Rakesh Pandit <rakesh@tuxera.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b23ef7b8dd7e88c2fbddb4c8b0e13366d6c23766
Author: Sandeep Singh <sandeep.singh@amd.com>
Date: Fri Aug 4 16:35:56 2017 +0530
usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume
commit e788787ef4f9c24aafefc480a8da5f92b914e5e6 upstream.
Certain HP keyboards would keep inputting a character automatically which
is the wake-up key after S3 resume
On some AMD platforms USB host fails to respond (by holding resume-K) to
USB device (an HP keyboard) resume request within 1ms (TURSM) and ensures
that resume is signaled for at least 20 ms (TDRSMDN), which is defined in
USB 2.0 spec. The result is that the keyboard is out of function.
In SNPS USB design, the host responds to the resume request only after
system gets back to S0 and the host gets to functional after the internal
HW restore operation that is more than 1 second after the initial resume
request from the USB device.
As a workaround for specific keyboard ID(HP Keyboards), applying port reset
after resume when the keyboard is plugged in.
Signed-off-by: Sandeep Singh <Sandeep.Singh@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
Reviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 73e7a2dca9ccfc43bd456f97e453176d0c3152c2
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date: Tue Aug 8 17:51:27 2017 +0800
usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter
commit 7496cfe5431f21da5d27a8388c326397e3f0a5db upstream.
Moshi USB to Ethernet Adapter internally uses a Genesys Logic hub to
connect to Realtek r8153.
The Realtek r8153 ethernet does not work on the internal hub, no-lpm quirk
can make it work.
Since another r8153 dongle at my hand does not have the issue, so add
the quirk to the Genesys Logic hub instead.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 488f4d8048e202f9a0053c1fa16d0b17ebe575cb
Author: Bin Liu <b-liu@ti.com>
Date: Tue Jul 25 09:31:33 2017 -0500
usb: core: unlink urbs from the tail of the endpoint's urb_list
commit 2eac13624364db5b5e1666ae0bb3a4d36bc56b6e upstream.
While unlink an urb, if the urb has been programmed in the controller,
the controller driver might do some hw related actions to tear down the
urb.
Currently usb_hcd_flush_endpoint() passes each urb from the head of the
endpoint's urb_list to the controller driver, which could make the
controller driver think each urb has been programmed and take the
unnecessary actions for each urb.
This patch changes the behavior in usb_hcd_flush_endpoint() to pass the
urbs from the tail of the list, to avoid any unnecessary actions in an
controller driver.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7ff799af2c2171605e3bcf859e8bf65b21f2fbf8
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Tue Aug 1 10:41:56 2017 -0400
USB: Check for dropped connection before switching to full speed
commit 94c43b9897abf4ea366ed4dba027494e080c7050 upstream.
Some buggy USB disk adapters disconnect and reconnect multiple times
during the enumeration procedure. This may lead to a device
connecting at full speed instead of high speed, because when the USB
stack sees that a device isn't able to enumerate at high speed, it
tries to hand the connection over to a full-speed companion
controller.
The logic for doing this is careful to check that the device is still
connected. But this check is inadequate if the device disconnects and
reconnects before the check is done. The symptom is that a device
works, but much more slowly than it is capable of operating.
The situation was made worse recently by commit 22547c4cc4fe ("usb:
hub: Wait for connection to be reestablished after port reset"), which
increases the delay following a reset before a disconnect is
recognized, thus giving the device more time to reconnect.
This patch makes the check more robust. If the device was
disconnected at any time during enumeration, we will now skip the
full-speed handover.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Zdenek Kabelac <zkabelac@redhat.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c45923eb94130287582e50d4ac12fd4f5f99c3bb
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Wed Aug 2 13:21:45 2017 +0900
usb: renesas_usbhs: Fix UGCTRL2 value for R-Car Gen3
commit 2acecd58969897795cf015c9057ebd349a3fda8a upstream.
The latest HW manual (Rev.0.55) shows us this UGCTRL2.VBUSSEL bit.
If the bit sets to 1, the VBUS drive is controlled by phy related
registers (called "UCOM Registers" on the manual). Since R-Car Gen3
environment will control VBUS by phy-rcar-gen3-usb2 driver,
the UGCTRL2.VBUSSEL bit should be set to 1. So, this patch fixes
the register's value. Otherwise, even if the ID pin indicates to
peripheral, the R-Car will output USBn_PWEN to 1 when a host driver
is running.
Fixes: de18757e272d ("usb: renesas_usbhs: add R-Car Gen3 power control"
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f5324020bcef034f832291bacd0d214d02f27919
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Wed Aug 2 21:06:35 2017 +0900
usb: gadget: udc: renesas_usb3: Fix usb_gadget_giveback_request() calling
commit aca5b9ebd096039657417c321a9252c696b359c2 upstream.
According to the gadget.h, a "complete" function will always be called
with interrupts disabled. However, sometimes usb3_request_done() function
is called with interrupts enabled. So, this function should be held
by spin_lock_irqsave() to disable interruption. Also, this driver has
to call spin_unlock() to avoid spinlock recursion by this driver before
calling usb_gadget_giveback_request().
Reported-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Tested-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7926348676f575024cb7d7e302b6584331208f01
Author: Bart Van Assche <bart.vanassche@wdc.com>
Date: Wed Aug 9 11:28:06 2017 -0700
block: Make blk_mq_delay_kick_requeue_list() rerun the queue at a quiet time
commit d4acf3650c7c968f46ad932b9a25d1cc24cf4998 upstream.
The blk_mq_delay_kick_requeue_list() function is used by the device
mapper and only by the device mapper to rerun the queue and requeue
list after a delay. This function is called once per request that
gets requeued. Modify this function such that the queue is run once
per path change event instead of once per request that is requeued.
Fixes: commit 2849450ad39d ("blk-mq: introduce blk_mq_delay_kick_requeue_list()")
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: Laurence Oberman <loberman@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 67e1a98e3a74a5e728f311f59282a242ab34406d
Author: Luis R. Rodriguez <mcgrof@kernel.org>
Date: Thu Jul 20 13:13:11 2017 -0700
firmware: avoid invalid fallback aborts by using killable wait
commit 260d9f2fc5655a2552701cdd0b909c4466732f19 upstream.
Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion
is interrupted") added via 4.0 added support to abort the fallback mechanism
when a signal was detected and wait_for_completion_interruptible() returned
-ERESTARTSYS -- for instance when a user hits CTRL-C. The abort was overly
*too* effective.
When a child process terminates (successful or not) the signal SIGCHLD can
be sent to the parent process which ran the child in the background and
later triggered a sync request for firmware through a sysfs interface which
relies on the fallback mechanism. This signal in turn can be recieved by the
interruptible wait we constructed on firmware_class and detects it as an
abort *before* userspace could get a chance to write the firmware. Upon
failure -EAGAIN is returned, so userspace is also kept in the dark about
exactly what happened.
We can reproduce the issue with the fw_fallback.sh selftest:
Before this patch:
$ sudo tools/testing/selftests/firmware/fw_fallback.sh
...
tools/testing/selftests/firmware/fw_fallback.sh: error - sync firmware request cancelled due to SIGCHLD
After this patch:
$ sudo tools/testing/selftests/firmware/fw_fallback.sh
...
tools/testing/selftests/firmware/fw_fallback.sh: SIGCHLD on sync ignored as expected
Fix this by making the wait killable -- only killable by SIGKILL (kill -9).
We loose the ability to allow userspace to cancel a write with CTRL-C
(SIGINT), however its been decided the compromise to require SIGKILL is
worth the gains.
Chances of this issue occuring are low due to the number of drivers upstream
exclusively relying on the fallback mechanism for firmware (2 drivers),
however this is observed in the field with custom drivers with sysfs
triggers to load firmware. Only distributions relying on the fallback
mechanism are impacted as well. An example reported issue was on Android,
as follows:
1) Android init (pid=1) fork()s (say pid=42) [this child process is totally
unrelated to firmware loading, it could be sleep 2; for all we care ]
2) Android init (pid=1) does a write() on a (driver custom) sysfs file which
ends up calling request_firmware() kernel side
3) The firmware loading fallback mechanism is used, the request is sent to
userspace and pid 1 waits in the kernel on wait_*
4) before firmware loading completes pid 42 dies (for any reason, even
normal termination)
5) Kernel delivers SIGCHLD to pid=1 to tell it a child has died, which
causes -ERESTARTSYS to be returned from wait_*
6) The kernel's wait aborts and return -EAGAIN for the
request_firmware() caller.
Fixes: 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion is interrupted")
Suggested-by: "Eric W. Biederman" <ebiederm@xmission.com>
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Martin Fuzzey <mfuzzey@parkeon.com>
Reported-by: Martin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b1b5c0b23a909c0e6f7f8bddc111a68caf128242
Author: Luis R. Rodriguez <mcgrof@kernel.org>
Date: Thu Jul 20 13:13:10 2017 -0700
firmware: fix batched requests - send wake up on failure on direct lookups
commit 90d41e74a9c36a84e2efbd2a5b8d79299feee6fa upstream.
Fix batched requests from waiting forever on failure.
The firmware API batched requests feature has been broken since the API call
request_firmware_direct() was introduced on commit bba3a87e982ad ("firmware:
Introduce request_firmware_direct()"), added on v3.14 *iff* the firmware
being requested was not present in *certain kernel builds* [0].
When no firmware is found the worker which goes on to finish never informs
waiters queued up of this, so any batched request will stall in what seems
to be forever (MAX_SCHEDULE_TIMEOUT). Sadly, a reboot will also stall, as
the reboot notifier was only designed to kill custom fallback workers. The
issue seems to the user as a type of soft lockup, what *actually* happens
underneath the hood is a wait call which never completes as we failed to
issue a completion on error.
For device drivers with optional firmware schemes (ie, Intel iwlwifi, or
Netronome -- even though it uses request_firmware() and not
request_firmware_direct()), this could mean that when you boot a system with
multiple cards the firmware will seem to never load on the system, or that
the card is just not responsive even the driver initialization. Due to
differences in scheduling possible this should not always trigger --
one would need to to ensure that multiple requests are in place at the
right time for this to work, also release_firmware() must not be called
prior to any other incoming request. The complexity may not be worth
supporting batched requests in the future given the wait mechanism is
only used also for the fallback mechanism. We'll keep it for now and
just fix it.
Its reported that at least with the Intel WiFi cards on one system this
issue was creeping up 50% of the boots [0].
Before this commit batched requests testing revealed:
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
CONFIG_FW_LOADER_USER_HELPER=y
Most common Linux distribution setup.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() FAIL OK
request_firmware_direct() FAIL OK
request_firmware_nowait(uevent=true) FAIL OK
request_firmware_nowait(uevent=false) FAIL OK
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
CONFIG_FW_LOADER_USER_HELPER=n
Only possible if CONFIG_DELL_RBU=n and CONFIG_LEDS_LP55XX_COMMON=n, rare.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() FAIL OK
request_firmware_direct() FAIL OK
request_firmware_nowait(uevent=true) FAIL OK
request_firmware_nowait(uevent=false) FAIL OK
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_FW_LOADER_USER_HELPER=y
Google Android setup.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() OK OK
request_firmware_direct() FAIL OK
request_firmware_nowait(uevent=true) OK OK
request_firmware_nowait(uevent=false) OK OK
============================================================================
Ater this commit batched testing results:
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
CONFIG_FW_LOADER_USER_HELPER=y
Most common Linux distribution setup.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() OK OK
request_firmware_direct() OK OK
request_firmware_nowait(uevent=true) OK OK
request_firmware_nowait(uevent=false) OK OK
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
CONFIG_FW_LOADER_USER_HELPER=n
Only possible if CONFIG_DELL_RBU=n and CONFIG_LEDS_LP55XX_COMMON=n, rare.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() OK OK
request_firmware_direct() OK OK
request_firmware_nowait(uevent=true) OK OK
request_firmware_nowait(uevent=false) OK OK
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_FW_LOADER_USER_HELPER=y
Google Android setup.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() OK OK
request_firmware_direct() OK OK
request_firmware_nowait(uevent=true) OK OK
request_firmware_nowait(uevent=false) OK OK
============================================================================
[0] https://bugzilla.kernel.org/show_bug.cgi?id=195477
Fixes: bba3a87e982ad ("firmware: Introduce request_firmware_direct()"
Reported-by: Nicolas <nbroeking@me.com>
Reported-by: John Ewalt <jewalt@lgsinnovations.com>
Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c2c32ed5e6bf3aa81d4c5e04be9f9ec2598ef2db
Author: Luis R. Rodriguez <mcgrof@kernel.org>
Date: Thu Jul 20 13:13:09 2017 -0700
firmware: fix batched requests - wake all waiters
commit e44565f62a72064e686f7a852137595ec94d78f2 upstream.
The firmware cache mechanism serves two purposes, the secondary purpose is
not well documented nor understood. This fixes a regression with the
secondary purpose of the firmware cache mechanism: batched requests on
successful lookups. Without this fix *any* time a batched request is
triggered, secondary requests for which the batched request mechanism
was designed for will seem to last forver and seem to never return.
This issue is present for all kernel builds possible, and a hard reset
is required.
The firmware cache is used for:
1) Addressing races with file lookups during the suspend/resume cycle
by keeping firmware in memory during the suspend/resume cycle
2) Batched requests for the same file rely only on work from the first file
lookup, which keeps the firmware in memory until the last
release_firmware() is called
Batched requests *only* take effect if secondary requests come in prior to
the first user calling release_firmware(). The devres name used for the
internal firmware cache is used as a hint other pending requests are
ongoing, the firmware buffer data is kept in memory until the last user of
the buffer calls release_firmware(), therefore serializing requests and
delaying the release until all requests are done.
Batched requests wait for a wakup or signal so we can rely on the first file
fetch to write to the pending secondary requests. Commit 5b029624948d
("firmware: do not use fw_lock for fw_state protection") ported the firmware
API to use swait, and in doing so failed to convert complete_all() to
swake_up_all() -- it used swake_up(), loosing the ability for *some* batched
requests to take effect.
We *could* fix this by just using swake_up_all() *but* swait is now known
to be very special use case, so its best to just move away from it. So we
just go back to using completions as before commit 5b029624948d ("firmware:
do not use fw_lock for fw_state protection") given this was using
complete_all().
Without this fix it has been reported plugging in two Intel 6260 Wifi cards
on a system will end up enumerating the two devices only 50% of the time
[0]. The ported swake_up() should have actually handled the case with two
devices, however, *if more than two cards are used* the swake_up() would
not have sufficed. This change is only part of the required fixes for
batched requests. Another fix is provided in the next patch.
This particular change should fix the cases where more than three requests
with the same firmware name is used, otherwise batched requests will wait
for MAX_SCHEDULE_TIMEOUT and just timeout eventually.
Below is a summary of tests triggering batched requests on different
kernel builds.
Before this patch:
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
CONFIG_FW_LOADER_USER_HELPER=y
Most common Linux distribution setup.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() FAIL FAIL
request_firmware_direct() FAIL FAIL
request_firmware_nowait(uevent=true) FAIL FAIL
request_firmware_nowait(uevent=false) FAIL FAIL
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
CONFIG_FW_LOADER_USER_HELPER=n
Only possible if CONFIG_DELL_RBU=n and CONFIG_LEDS_LP55XX_COMMON=n, rare.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() FAIL FAIL
request_firmware_direct() FAIL FAIL
request_firmware_nowait(uevent=true) FAIL FAIL
request_firmware_nowait(uevent=false) FAIL FAIL
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_FW_LOADER_USER_HELPER=y
Google Android setup.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() FAIL FAIL
request_firmware_direct() FAIL FAIL
request_firmware_nowait(uevent=true) FAIL FAIL
request_firmware_nowait(uevent=false) FAIL FAIL
============================================================================
After this patch:
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
CONFIG_FW_LOADER_USER_HELPER=y
Most common Linux distribution setup.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() FAIL OK
request_firmware_direct() FAIL OK
request_firmware_nowait(uevent=true) FAIL OK
request_firmware_nowait(uevent=false) FAIL OK
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
CONFIG_FW_LOADER_USER_HELPER=n
Only possible if CONFIG_DELL_RBU=n and CONFIG_LEDS_LP55XX_COMMON=n, rare.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() FAIL OK
request_firmware_direct() FAIL OK
request_firmware_nowait(uevent=true) FAIL OK
request_firmware_nowait(uevent=false) FAIL OK
============================================================================
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_FW_LOADER_USER_HELPER=y
Google Android setup.
API-type no-firmware-found firmware-found
----------------------------------------------------------------------
request_firmware() OK OK
request_firmware_direct() FAIL OK
request_firmware_nowait(uevent=true) OK OK
request_firmware_nowait(uevent=false) OK OK
============================================================================
[0] https://bugzilla.kernel.org/show_bug.cgi?id=195477
Cc: Ming Lei <ming.lei@redhat.com>
Fixes: 5b029624948d ("firmware: do not use fw_lock for fw_state protection")
Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f0834df3d97e5cb7370848f668a27a75172dd70d
Author: Alan Swanson <reiver@improbability.net>
Date: Wed Jul 26 12:03:33 2017 +0100
uas: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069
commit 89f23d51defcb94a5026d4b5da13faf4e1150a6f upstream.
Similar to commit d595259fbb7a ("usb-storage: Add ignore-residue quirk for
Initio INIC-3619") for INIC-3169 in unusual_devs.h but INIC-3069 already
present in unusual_uas.h. Both in same controller IC family.
Issue is that MakeMKV fails during key exchange with installed bluray drive
with following error:
002004:0000 Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED'
occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:0'
Signed-off-by: Alan Swanson <reiver@improbability.net>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c208cb9a5596661a3fce7c5352bc9f1f4980f31d
Author: Ian Abbott <abbotti@mev.co.uk>
Date: Fri Jul 28 16:22:31 2017 +0100
staging: comedi: comedi_fops: do not call blocking ops when !TASK_RUNNING
commit cef988642cdac44e910a27cb6e8166c96f86a0df upstream.
Comedi's read and write file operation handlers (`comedi_read()` and
`comedi_write()`) currently call `copy_to_user()` or `copy_from_user()`
whilst in the `TASK_INTERRUPTIBLE` state, which falls foul of the
`might_fault()` checks when enabled. Fix it by setting the current task
state back to `TASK_RUNNING` a bit earlier before calling these
functions.
Reported-by: Piotr Gregor <piotrgregor@rsyncme.org>
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 20035abc9e083387a3c163207f185468f5c137bb
Author: Hans de Goede <hdegoede@redhat.com>
Date: Fri Jun 30 19:42:54 2017 +0200
iio: adc: Revert "axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications"
commit 631b010abc5b57009c6a8328f51492665f6ef310 upstream.
Inheriting the ADC BIAS current settings from the BIOS instead of
hardcoding then causes the AXP288 to disable charging (I think it
mis-detects an overheated battery) on at least one model tablet.
So lets go back to hard coding the values, this reverts
commit fa2849e9649b ("iio: adc: axp288: Drop bogus
AXP288_ADC_TS_PIN_CTRL register modifications"), fixing charging not
working on the model tablet in question.
The exact cause is not fully understood, hence the revert to a known working
state.
Reported-by: Umberto Ixxo <sfumato1977@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c1164cc258bc657e31b860ef643d2a83bd064298
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date: Wed Jun 21 01:46:37 2017 +0900
iio: light: tsl2563: use correct event code
commit a3507e48d3f99a93a3056a34a5365f310434570f upstream.
The TSL2563 driver provides three iio channels, two of which are raw ADC
channels (channel 0 and channel 1) in the device and the remaining one
is calculated by the two. The ADC channel 0 only supports programmable
interrupt with threshold settings and this driver supports the event but
the generated event code does not contain the corresponding iio channel
type.
This is going to change userspace ABI. Hopefully fixing this to be
what it should always have been won't break any userspace code.
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 39e07a5c112cbac6999c57a87e171c0b3450db87
Author: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Date: Thu Jun 22 19:46:43 2017 +0200
iio: pressure: st_pressure_core: disable multiread by default for LPS22HB
commit add6e6ab3ee0e237822e0951476d3df039b49ec8 upstream.
Set multiread variable to false for LPS22HB pressure sensor since
it is already enabled in CTRL_REG2. Previous configuration does not
cause any issue in I2C communication since SUB Msb has no meaning
whereas it breaks register address in SPI communication
Fixes: e039e2f5b4da (iio:st_pressure:initial lps22hb sensor support)
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8886738d06fac8cee8626a0e042569e9879f02ab
Author: Hans de Goede <hdegoede@redhat.com>
Date: Thu Jul 13 15:13:41 2017 +0200
iio: accel: bmc150: Always restore device to normal mode after suspend-resume
commit e59e18989c68a8d7941005f81ad6abc4ca682de0 upstream.
After probe we would put the device in normal mode, after a runtime
suspend-resume we would put it back in normal mode. But for a regular
suspend-resume we would only put it back in normal mode if triggers
or events have been requested. This is not consistent and breaks
reading raw values after a suspend-resume.
This commit changes the regular resume path to also unconditionally put
the device back in normal mode, fixing reading of raw values not working
after a regular suspend-resume cycle.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3fdd0854800e3f026fda1668b0df29a7eb99bd42
Author: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Date: Wed Jul 5 20:30:01 2017 +0200
iio: accel: st_accel: add SPI-3wire support
commit a7b8829d242b1a58107e9c02b09e93aec446d55c upstream.
Add SPI Serial Interface Mode (SIM) register information
in st_sensor_settings look up table to support devices
(like LSM303AGR accel sensor) that allow just SPI-3wire
communication mode. SIM mode has to be configured before any
other operation since it is not enabled by default and the driver
is not able to read without that configuration
Whilst a fairly substantial patch, the actual logic is simple and it
is better to have the generic fix than a band aid.
Fixes: ddc05fa28606 (iio: st-accel: add support for lsm303agr accel)
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5f26ebe1afdcf348a9daafd419f97bca02e1a49c
Author: Mykola Kostenok <c_mykolak@mellanox.com>
Date: Mon Jul 17 12:00:35 2017 +0300
iio: aspeed-adc: wait for initial sequence.
commit 737cc2a593782df6846b3cab7e0f64384f58364a upstream.
This patch enables adc engine at initialization time and waits
for the initial sequence completion before enabling adc channels.
Without this code adc channels are not functional and shows
zeros for all connected channels.
Tested on mellanox msn platform.
v1 -> v2:
Pointed by Rick Altherr:
- Wait init sequence code enabled by bool
from OF match table.
Signed-off-by: Mykola Kostenok <c_mykolak@mellanox.com>
Reviewed-by: Rick Altherr <raltherr@google.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f0ab97d1aa1468d769ce6663e52a850601f68f37
Author: Arnd Bergmann <arnd@arndb.de>
Date: Fri Jul 14 11:31:03 2017 +0200
staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read
commit 105967ad68d2eb1a041bc041f9cf96af2a653b65 upstream.
gcc-7 points out an older regression:
drivers/staging/iio/resolver/ad2s1210.c: In function 'ad2s1210_read_raw':
drivers/staging/iio/resolver/ad2s1210.c:515:42: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context]
The original code had 'unsigned short' here, but incorrectly got
converted to 'bool'. This reverts the regression and uses a normal
type instead.
Fixes: 29148543c521 ("staging:iio:resolver:ad2s1210 minimal chan spec conversion.")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9ccd63a6fdbd9ca6b7eb90898da4809c9dfcac6d
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Tue Jul 25 23:58:50 2017 +0200
USB: hcd: Mark secondary HCD as dead if the primary one died
commit cd5a6a4fdaba150089af2afc220eae0fef74878a upstream.
Make usb_hc_died() clear the HCD_FLAG_RH_RUNNING flag for the shared
HCD and set HCD_FLAG_DEAD for it, in analogy with what is done for
the primary one.
Among other thigs, this prevents check_root_hub_suspended() from
returning -EBUSY for dead HCDs which helps to work around system
suspend issues in some situations.
This actually fixes occasional suspend failures on one of my test
machines.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 792c00cb2377c373c0d46a249169362244bd9ced
Author: Bin Liu <b-liu@ti.com>
Date: Tue Jul 25 09:31:34 2017 -0500
usb: musb: fix tx fifo flush handling again
commit 45d73860530a14c608f410b91c6c341777bfa85d upstream.
commit 68fe05e2a451 ("usb: musb: fix tx fifo flush handling") drops the
1ms delay trying to solve the long disconnect time issue when
application queued many tx urbs. However, the 1ms delay is needed for
some use cases, for example, without the delay, reconnecting AR9271 WIFI
dongle no longer works if the connection is dropped from the AP.
So let's add back the 1ms delay in musb_h_tx_flush_fifo(), and solve the
long disconnect time problem with a separate patch for
usb_hcd_flush_endpoint().
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ab51515ece30bd49314579f3323cd055200f7484
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Thu Aug 10 11:54:12 2017 -0700
USB: serial: pl2303: add new ATEN device id
commit 3b6bcd3d093c698d32e93d4da57679b8fbc5e01e upstream.
This adds a new ATEN device id for a new pl2303-based device.
Reported-by: Peter Kuo <PeterKuo@aten.com.tw>
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 492eb6125c83ede23f017c78d948a297adee085e
Author: Stefan Triller <github@stefantriller.de>
Date: Fri Jun 30 14:44:03 2017 +0200
USB: serial: cp210x: add support for Qivicon USB ZigBee dongle
commit 9585e340db9f6cc1c0928d82c3a23cc4460f0a3f upstream.
The German Telekom offers a ZigBee USB Stick under the brand name Qivicon
for their SmartHome Home Base in its 1. Generation. The productId is not
known by the according kernel module, this patch adds support for it.
Signed-off-by: Stefan Triller <github@stefantriller.de>
Reviewed-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b576de1e12c980ba6bd38a142f0d58b9048b884d
Author: Hector Martin <marcan@marcan.st>
Date: Wed Aug 2 00:45:06 2017 +0900
USB: serial: option: add D-Link DWM-222 device ID
commit fd1b8668af59a11bb754a6c9b0051c6c5ce73b74 upstream.
Add device id for D-Link DWM-222.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 59f1322cc1e5fc9a4aa186c1862a027df97132fc
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Mon Jul 24 11:14:31 2017 +0200
drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut
commit 5279fc7724ae3a82c9cfe5b09c1fb07ff0e41056 upstream.
bdw_load_gamma_lut is writing beyond the array to the maximum value.
The intend of the function is to clamp values > 1 to 1, so write
the intended color to the max register.
This fixes the following KASAN warning:
[ 197.020857] [IGT] kms_pipe_color: executing
[ 197.063434] [IGT] kms_pipe_color: starting subtest ctm-0-25-pipe0
[ 197.078989] ==================================================================
[ 197.079127] BUG: KASAN: slab-out-of-bounds in bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[ 197.079188] Read of size 2 at addr ffff8800d38db150 by task kms_pipe_color/1839
[ 197.079208] CPU: 2 PID: 1839 Comm: kms_pipe_color Tainted: G U 4.13.0-rc1-patser+ #5211
[ 197.079215] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
[ 197.079220] Call Trace:
[ 197.079230] dump_stack+0x68/0x9e
[ 197.079239] print_address_description+0x6f/0x250
[ 197.079251] kasan_report+0x216/0x370
[ 197.079374] ? bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[ 197.079451] ? gen8_write16+0x4e0/0x4e0 [i915]
[ 197.079460] __asan_report_load2_noabort+0x14/0x20
[ 197.079535] bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[ 197.079612] broadwell_load_luts+0x1df/0x550 [i915]
[ 197.079690] intel_color_load_luts+0x7b/0x80 [i915]
[ 197.079764] intel_begin_crtc_commit+0x138/0x760 [i915]
[ 197.079783] drm_atomic_helper_commit_planes_on_crtc+0x1a3/0x820 [drm_kms_helper]
[ 197.079859] ? intel_pre_plane_update+0x571/0x580 [i915]
[ 197.079937] intel_update_crtc+0x238/0x330 [i915]
[ 197.080016] intel_update_crtcs+0x10f/0x210 [i915]
[ 197.080092] intel_atomic_commit_tail+0x1552/0x3340 [i915]
[ 197.080101] ? _raw_spin_unlock+0x3c/0x40
[ 197.080110] ? __queue_work+0xb40/0xbf0
[ 197.080188] ? skl_update_crtcs+0xc00/0xc00 [i915]
[ 197.080195] ? trace_hardirqs_on+0xd/0x10
[ 197.080269] ? intel_atomic_commit_ready+0x128/0x13c [i915]
[ 197.080329] ? __i915_sw_fence_complete+0x5b8/0x6d0 [i915]
[ 197.080336] ? debug_object_activate+0x39e/0x580
[ 197.080397] ? i915_sw_fence_await+0x30/0x30 [i915]
[ 197.080409] ? __might_sleep+0x15b/0x180
[ 197.080483] intel_atomic_commit+0x944/0xa70 [i915]
[ 197.080490] ? refcount_dec_and_test+0x11/0x20
[ 197.080567] ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
[ 197.080597] ? drm_atomic_crtc_set_property+0x303/0x580 [drm]
[ 197.080674] ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
[ 197.080704] drm_atomic_commit+0xd7/0xe0 [drm]
[ 197.080722] drm_atomic_helper_crtc_set_property+0xec/0x130 [drm_kms_helper]
[ 197.080749] drm_mode_crtc_set_obj_prop+0x7d/0xb0 [drm]
[ 197.080775] drm_mode_obj_set_property_ioctl+0x50b/0x5d0 [drm]
[ 197.080783] ? __might_fault+0x104/0x180
[ 197.080809] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[ 197.080838] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[ 197.080861] drm_ioctl_kernel+0x154/0x1a0 [drm]
[ 197.080885] drm_ioctl+0x624/0x8f0 [drm]
[ 197.080910] ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[ 197.080934] ? drm_getunique+0x210/0x210 [drm]
[ 197.080943] ? __handle_mm_fault+0x1bd0/0x1ce0
[ 197.080949] ? lock_downgrade+0x610/0x610
[ 197.080957] ? __lru_cache_add+0x15a/0x180
[ 197.080967] do_vfs_ioctl+0xd92/0xe40
[ 197.080975] ? ioctl_preallocate+0x1b0/0x1b0
[ 197.080982] ? selinux_capable+0x20/0x20
[ 197.080991] ? __do_page_fault+0x7b7/0x9a0
[ 197.080997] ? lock_downgrade+0x5bb/0x610
[ 197.081007] ? security_file_ioctl+0x57/0x90
[ 197.081016] SyS_ioctl+0x4e/0x80
[ 197.081024] entry_SYSCALL_64_fastpath+0x18/0xad
[ 197.081030] RIP: 0033:0x7f61f287a987
[ 197.081035] RSP: 002b:00007fff7d44d188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 197.081043] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f61f287a987
[ 197.081048] RDX: 00007fff7d44d1c0 RSI: 00000000c01864ba RDI: 0000000000000003
[ 197.081053] RBP: 00007f61f2b3eb00 R08: 0000000000000059 R09: 0000000000000000
[ 197.081058] R10: 0000002ea5c4a290 R11: 0000000000000246 R12: 00007f61f2b3eb58
[ 197.081063] R13: 0000000000001010 R14: 00007f61f2b3eb58 R15: 0000000000002702
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101659
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: Martin Peres <martin.peres@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Fixes: 82cf435b3134 ("drm/i915: Implement color management on bdw/skl/bxt/kbl")
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Kiran S Kumar <kiran.s.kumar@intel.com>
Cc: Kausal Malladi <kausalmalladi@gmail.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20170724091431.24251-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
(cherry picked from commit 09a92bc8773b4314e02b478e003fe5936ce85adb)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4eedc8a7f03b15a9daad69b4d54e43f79fa0e16e
Author: Wladimir J. van der Laan <laanwj@gmail.com>
Date: Tue Jul 25 14:33:36 2017 +0200
drm/etnaviv: Fix off-by-one error in reloc checking
commit d6f756e09f01ea7a0efbbcef269a1e384a35d824 upstream.
A relocation pointing to the last four bytes of a buffer can
legitimately happen in the case of small vertex buffers.
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8f0f15cc167d550cb50adbdf14472968b619d244
Author: Lucas Stach <l.stach@pengutronix.de>
Date: Mon Jul 10 14:41:25 2017 +0200
drm/bridge: tc358767: fix probe without attached output node
commit d630213f2a47933e1037909273a20023ba3e598d upstream.
The output node of the TC358767 is only used if another bridge is chained
behind it. Panels attached to the TC358767 can be detected using the usual
DP AUX probing. This restores the old behavior of ignoring the output if
no endpoint is found.
Fixes: ebc944613567 (drm: convert drivers to use drm_of_find_panel_or_bridge)
Acked-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20170710124125.9019-1-l.stach@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1cc5cd5b97b51a19cbc0a918787b5a9b63aa7140
Author: Weston Andros Adamson <dros@monkey.org>
Date: Tue Aug 1 16:25:01 2017 -0400
nfs/flexfiles: fix leak of nfs4_ff_ds_version arrays
commit 1feb26162bee7b2f110facfec71b5c7bdbc7d14d upstream.
The client was freeing the nfs4_ff_layout_ds, but not the contained
nfs4_ff_ds_version array.
Signed-off-by: Weston Andros Adamson <dros@primarydata.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8d189f60407f878aff3bc782e109edd713da9655
Author: Haibo Chen <haibo.chen@nxp.com>
Date: Tue Aug 8 18:54:01 2017 +0800
mmc: mmc: correct the logic for setting HS400ES signal voltage
commit 92ddd95919466de5d34f3cb43635da9a7f9ab814 upstream.
Change the default err value to -EINVAL, make sure the card only
has type EXT_CSD_CARD_TYPE_HS400_1_8V also do the signal voltage
setting when select hs400es mode.
Fixes: commit 1720d3545b77 ("mmc: core: switch to 1V8 or 1V2 for hs400es mode")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3329fe0e05f8eb1a82b04d921b07c2ece0e3c802
Author: Miquel Raynal <miquel.raynal@free-electrons.com>
Date: Wed Jul 5 08:51:09 2017 +0200
nand: fix wrong default oob layout for small pages using soft ecc
commit f7f8c1756e9a5f1258a7cc6b663f8451b724900f upstream.
When using soft ecc, if no ooblayout is given, the core automatically
uses one of the nand_ooblayout_{sp,lp}*() functions to determine the
layout inside the out of band data.
Until kernel version 4.6, struct nand_ecclayout was used for that
purpose. During the migration from 4.6 to 4.7, an error shown up in the
small page layout, in the case oob section is only 8 bytes long.
The layout was using three bytes (0, 1, 2) for ecc, two bytes (3, 4)
as free bytes, one byte (5) for bad block marker and finally
two bytes (6, 7) as free bytes, as shown there:
[linux-4.6] drivers/mtd/nand/nand_base.c:52
static struct nand_ecclayout nand_oob_8 = {
.eccbytes = 3,
.eccpos = {0, 1, 2},
.oobfree = {
{.offset = 3,
.length = 2},
{.offset = 6,
.length = 2} }
};
This fixes the current implementation which is incoherent. It
references bit 3 at the same time as an ecc byte and a free byte.
Furthermore, it is clear with the previous implementation that there
is only one ecc section with 8 bytes oob sections. We shall return
-ERANGE in the nand_ooblayout_ecc_sp() function when asked for the
second section.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Fixes: 41b207a70d3a ("mtd: nand: implement the default mtd_ooblayout_ops")
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1f2f0f1a75bda5776c5d5aba015fc9b3d1fd82cb
Author: Hans de Goede <hdegoede@redhat.com>
Date: Thu Jul 13 15:45:02 2017 +0200
i2c: designware: Some broken DSTDs use 1MiHz instead of 1MHz
commit 682c6c2188f39d13548ccdc89c9888fbcb547889 upstream.
At least the Acer Iconia Tab8 / aka W1-810 uses 1MiHz instead of
1MHz for one of its busses, fix this up to 1MHz instead of failing
the probe of that bus.
This fixes the accelerometer on the Acer Iconia Tab8 not working.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cfea0422a154cd45de0ff1a8146d2e303647a5cf
Author: Mateusz Jurczyk <mjurczyk@google.com>
Date: Wed Jun 7 12:26:49 2017 +0200
fuse: initialize the flock flag in fuse_file on allocation
commit 68227c03cba84a24faf8a7277d2b1a03c8959c2c upstream.
Before the patch, the flock flag could remain uninitialized for the
lifespan of the fuse_file allocation. Unless set to true in
fuse_file_flock(), it would remain in an indeterminate state until read in
an if statement in fuse_release_common(). This could consequently lead to
taking an unexpected branch in the code.
The bug was discovered by a runtime instrumentation designed to detect use
of uninitialized memory in the kernel.
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Fixes: 37fb3a30b462 ("fuse: fix flock")
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 59c74236092d7bf6581dfc9c3b29315d26f6a5eb
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Sun Aug 6 16:10:03 2017 -0700
target: Fix node_acl demo-mode + uncached dynamic shutdown regression
commit 6f48655facfd7f7ccfe6d252ac0fe319ab02e4dd upstream.
This patch fixes a generate_node_acls = 1 + cache_dynamic_acls = 0
regression, that was introduced by
commit 01d4d673558985d9a118e1e05026633c3e2ade9b
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Wed Dec 7 12:55:54 2016 -0800
which originally had the proper list_del_init() usage, but was
dropped during list review as it was thought unnecessary by HCH.
However, list_del_init() usage is required during the special
generate_node_acls = 1 + cache_dynamic_acls = 0 case when
transport_free_session() does a list_del(&se_nacl->acl_list),
followed by target_complete_nacl() doing the same thing.
This was manifesting as a general protection fault as reported
by Justin:
kernel: general protection fault: 0000 [#1] SMP
kernel: Modules linked in:
kernel: CPU: 0 PID: 11047 Comm: iscsi_ttx Not tainted 4.13.0-rc2.x86_64.1+ #20
kernel: Hardware name: Intel Corporation S5500BC/S5500BC, BIOS S5500.86B.01.00.0064.050520141428 05/05/2014
kernel: task: ffff88026939e800 task.stack: ffffc90007884000
kernel: RIP: 0010:target_put_nacl+0x49/0xb0
kernel: RSP: 0018:ffffc90007887d70 EFLAGS: 00010246
kernel: RAX: dead000000000200 RBX: ffff8802556ca000 RCX: 0000000000000000
kernel: RDX: dead000000000100 RSI: 0000000000000246 RDI: ffff8802556ce028
kernel: RBP: ffffc90007887d88 R08: 0000000000000001 R09: 0000000000000000
kernel: R10: ffffc90007887df8 R11: ffffea0009986900 R12: ffff8802556ce020
kernel: R13: ffff8802556ce028 R14: ffff8802556ce028 R15: ffffffff88d85540
kernel: FS: 0000000000000000(0000) GS:ffff88027fc00000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 00007fffe36f5f94 CR3: 0000000009209000 CR4: 00000000003406f0
kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
kernel: Call Trace:
kernel: transport_free_session+0x67/0x140
kernel: transport_deregister_session+0x7a/0xc0
kernel: iscsit_close_session+0x92/0x210
kernel: iscsit_close_connection+0x5f9/0x840
kernel: iscsit_take_action_for_connection_exit+0xfe/0x110
kernel: iscsi_target_tx_thread+0x140/0x1e0
kernel: ? wait_woken+0x90/0x90
kernel: kthread+0x124/0x160
kernel: ? iscsit_thread_get_cpumask+0x90/0x90
kernel: ? kthread_create_on_node+0x40/0x40
kernel: ret_from_fork+0x22/0x30
kernel: Code: 00 48 89 fb 4c 8b a7 48 01 00 00 74 68 4d 8d 6c 24 08 4c
89 ef e8 e8 28 43 00 48 8b 93 20 04 00 00 48 8b 83 28 04 00 00 4c 89
ef <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 20
kernel: RIP: target_put_nacl+0x49/0xb0 RSP: ffffc90007887d70
kernel: ---[ end trace f12821adbfd46fed ]---
To address this, go ahead and use proper list_del_list() for all
cases of se_nacl->acl_list deletion.
Reported-by: Justin Maggard <jmaggard01@gmail.com>
Tested-by: Justin Maggard <jmaggard01@gmail.com>
Cc: Justin Maggard <jmaggard01@gmail.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7b0d44e25fdbf7aa786538cbe2d41f9cae0c5947
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Wed Jul 26 11:49:19 2017 -0400
usb-storage: fix deadlock involving host lock and scsi_done
commit 8b52291a0743fc4db4a7495c846a6f31ee84d282 upstream.
Christoph Hellwig says that since version 4.12, the kernel switched to
using blk-mq by default. The old code used a softirq for handling
request completions, but blk-mq can handle completions in the caller's
context. This may cause a problem for usb-storage, because it invokes
the ->scsi_done callback while holding the host lock, and the
completion routine sometimes tries to acquire the same lock (when
running the error handler, for example).
The consequence is that the existing code will sometimes deadlock upon
error completion of a SCSI command (with a lockdep warning).
This is easy enough to fix, since usb-storage doesn't really need to
hold the host lock while the callback runs. It was simpler to write
it that way, but moving the call outside the locked region is pretty
easy and there's no downside. That's what this patch does.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Arthur Marsh <arthur.marsh@internode.on.net>
CC: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 428048128bf08766ffddb3571fd5040951dfc8c9
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Fri Aug 4 23:59:31 2017 -0700
iscsi-target: Fix iscsi_np reset hung task during parallel delete
commit 978d13d60c34818a41fc35962602bdfa5c03f214 upstream.
This patch fixes a bug associated with iscsit_reset_np_thread()
that can occur during parallel configfs rmdir of a single iscsi_np
used across multiple iscsi-target instances, that would result in
hung task(s) similar to below where configfs rmdir process context
was blocked indefinately waiting for iscsi_np->np_restart_comp
to finish:
[ 6726.112076] INFO: task dcp_proxy_node_:15550 blocked for more than 120 seconds.
[ 6726.119440] Tainted: G W O 4.1.26-3321 #2
[ 6726.125045] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 6726.132927] dcp_proxy_node_ D ffff8803f202bc88 0 15550 1 0x00000000
[ 6726.140058] ffff8803f202bc88 ffff88085c64d960 ffff88083b3b1ad0 ffff88087fffeb08
[ 6726.147593] ffff8803f202c000 7fffffffffffffff ffff88083f459c28 ffff88083b3b1ad0
[ 6726.155132] ffff88035373c100 ffff8803f202bca8 ffffffff8168ced2 ffff8803f202bcb8
[ 6726.162667] Call Trace:
[ 6726.165150] [<ffffffff8168ced2>] schedule+0x32/0x80
[ 6726.170156] [<ffffffff8168f5b4>] schedule_timeout+0x214/0x290
[ 6726.176030] [<ffffffff810caef2>] ? __send_signal+0x52/0x4a0
[ 6726.181728] [<ffffffff8168d7d6>] wait_for_completion+0x96/0x100
[ 6726.187774] [<ffffffff810e7c80>] ? wake_up_state+0x10/0x10
[ 6726.193395] [<ffffffffa035d6e2>] iscsit_reset_np_thread+0x62/0xe0 [iscsi_target_mod]
[ 6726.201278] [<ffffffffa0355d86>] iscsit_tpg_disable_portal_group+0x96/0x190 [iscsi_target_mod]
[ 6726.210033] [<ffffffffa0363f7f>] lio_target_tpg_store_enable+0x4f/0xc0 [iscsi_target_mod]
[ 6726.218351] [<ffffffff81260c5a>] configfs_write_file+0xaa/0x110
[ 6726.224392] [<ffffffff811ea364>] vfs_write+0xa4/0x1b0
[ 6726.229576] [<ffffffff811eb111>] SyS_write+0x41/0xb0
[ 6726.234659] [<ffffffff8169042e>] system_call_fastpath+0x12/0x71
It would happen because each iscsit_reset_np_thread() sets state
to ISCSI_NP_THREAD_RESET, sends SIGINT, and then blocks waiting
for completion on iscsi_np->np_restart_comp.
However, if iscsi_np was active processing a login request and
more than a single iscsit_reset_np_thread() caller to the same
iscsi_np was blocked on iscsi_np->np_restart_comp, iscsi_np
kthread process context in __iscsi_target_login_thread() would
flush pending signals and only perform a single completion of
np->np_restart_comp before going back to sleep within transport
specific iscsit_transport->iscsi_accept_np code.
To address this bug, add a iscsi_np->np_reset_count and update
__iscsi_target_login_thread() to keep completing np->np_restart_comp
until ->np_reset_count has reached zero.
Reported-by: Gary Guo <ghg@datera.io>
Tested-by: Gary Guo <ghg@datera.io>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f838bd1752be732c6c9e0ff50935be5dc4fef48f
Author: Varun Prakash <varun@chelsio.com>
Date: Sun Jul 23 20:03:33 2017 +0530
iscsi-target: fix memory leak in iscsit_setup_text_cmd()
commit ea8dc5b4cd2195ee582cae28afa4164c6dea1738 upstream.
On receiving text request iscsi-target allocates buffer for
payload in iscsit_handle_text_cmd() and assigns buffer pointer
to cmd->text_in_ptr, this buffer is currently freed in
iscsit_release_cmd(), if iscsi-target sets 'C' bit in text
response then it will receive another text request from the
initiator with ttt != 0xffffffff in this case iscsi-target
will find cmd using itt and call iscsit_setup_text_cmd()
which will set cmd->text_in_ptr to NULL without freeing
previously allocated buffer.
This patch fixes this issue by calling kfree(cmd->text_in_ptr)
in iscsit_setup_text_cmd() before assigning NULL to it.
For the first text request cmd->text_in_ptr is NULL as
cmd is memset to 0 in iscsit_allocate_cmd().
Signed-off-by: Varun Prakash <varun@chelsio.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0e1953e0310ad79c9aa6ff019b5425d342566aa
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
Date: Mon Jul 31 10:31:27 2017 +0200
mtd: nand: Declare tBERS, tR and tPROG as u64 to avoid integer overflow
commit 6d29231000bbe0fb9e4893a9c68151ffdd3b5469 upstream.
All timings in nand_sdr_timings are expressed in picoseconds but some
of them may not fit in an u32.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: 204e7ecd47e2 ("mtd: nand: Add a few more timings to nand_sdr_timings")
Reported-by: Alexander Dahl <ada@thorsis.com>
Reviewed-by: Alexander Dahl <ada@thorsis.com>
Tested-by: Alexander Dahl <ada@thorsis.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 867c07788e9764cee324bbe1193ba93febe08e3c
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
Date: Mon Jul 31 10:29:56 2017 +0200
mtd: nand: Fix timing setup for NANDs that do not support SET FEATURES
commit a11bf5ed951f8900d244d09eb03a888b59c7fc82 upstream.
Some ONFI NANDs do not support the SET/GET FEATURES commands, which,
according to the spec, is perfectly valid.
On these NANDs we can't set a specific timing mode using the "timing
mode" feature, and we should assume the NAND does not require any setup
to enter a specific timing mode.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: d8e725dd8311 ("mtd: nand: automate NAND timings selection")
Reported-by: Alexander Dahl <ada@thorsis.com>
Tested-by: Alexander Dahl <ada@thorsis.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a34d48d5ca47c7ba740783ed8490b93499e0f870
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
Date: Mon Jul 17 20:20:08 2017 +0200
mtd: nand: atmel: Fix DT backward compatibility in pmecc.c
commit 3aa0907675a38498d8f2d343e94207ad28a117cf upstream.
PMECC caps extraction from old DT bindings is broken, thus leading to
erroneous EL registers offset, which in turn make HW ECC unusable on
sama5d2 when old bindings are in use.
Passing the NAND dev node instead of the NFC node to of_match_node()
solves the problem.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
Tested-by: Romain Izard <romain.izard.pro@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0eda7e0bf2389a4dd5e752dcaa4a8d48bb799172
Author: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Tue Aug 1 17:57:20 2017 +0200
pinctrl: armada-37xx: Fix number of pin in south bridge
commit 6b67c3906cd74d88da4f6717b4b294bd52fce56a upstream.
On the south bridge we have pin from to 29, so it gives 30 pins (and not
29).
Without this patch the kernel complain with the following traces:
cat /sys/kernel/debug/pinctrl/d0018800.pinctrl/pingroups
[ 154.530205] armada-37xx-pinctrl d0018800.pinctrl: failed to get pin(29) name
[ 154.537567] ------------[ cut here ]------------
[ 154.542348] WARNING: CPU: 1 PID: 1347 at /home/gclement/open/kernel/marvell-mainline-linux/drivers/pinctrl/core.c:1610 pinctrl_groups_show+0x15c/0x1a0
[ 154.555918] Modules linked in:
[ 154.558890] CPU: 1 PID: 1347 Comm: cat Tainted: G W 4.13.0-rc1-00001-g19e1b9fa219d #525
[ 154.568316] Hardware name: Marvell Armada 3720 Development Board DB-88F3720-DDR3 (DT)
[ 154.576311] task: ffff80001d32d100 task.stack: ffff80001bdc0000
[ 154.583048] PC is at pinctrl_groups_show+0x15c/0x1a0
[ 154.587816] LR is at pinctrl_groups_show+0x148/0x1a0
[ 154.592847] pc : [<ffff0000083e3adc>] lr : [<ffff0000083e3ac8>] pstate: 00000145
[ 154.600840] sp : ffff80001bdc3c80
[ 154.604255] x29: ffff80001bdc3c80 x28: 00000000f7750000
[ 154.609825] x27: ffff80001d05d198 x26: 0000000000000009
[ 154.615224] x25: ffff0000089ead20 x24: 0000000000000002
[ 154.620705] x23: ffff000008c8e1d0 x22: ffff80001be55700
[ 154.626187] x21: ffff80001d05d100 x20: 0000000000000005
[ 154.631667] x19: 0000000000000006 x18: 0000000000000010
[ 154.637238] x17: 0000000000000000 x16: ffff0000081fc4b8
[ 154.642726] x15: 0000000000000006 x14: ffff0000899e537f
[ 154.648214] x13: ffff0000099e538d x12: 206f742064656c69
[ 154.653613] x11: 6166203a6c727463 x10: 0000000005f5e0ff
[ 154.659094] x9 : ffff80001bdc38c0 x8 : 286e697020746567
[ 154.664576] x7 : ffff000008551870 x6 : 000000000000011b
[ 154.670146] x5 : 0000000000000000 x4 : 0000000000000000
[ 154.675544] x3 : 0000000000000000 x2 : 0000000000000000
[ 154.681025] x1 : ffff000008c8e1d0 x0 : ffff80001be55700
[ 154.686507] Call trace:
[ 154.688668] Exception stack(0xffff80001bdc3ab0 to 0xffff80001bdc3be0)
[ 154.695224] 3aa0: 0000000000000006 0001000000000000
[ 154.703310] 3ac0: ffff80001bdc3c80 ffff0000083e3adc ffff80001bdc3bb0 00000000ffffffd8
[ 154.711304] 3ae0: 4554535953425553 6f6674616c703d4d 4349564544006d72 6674616c702b3d45
[ 154.719478] 3b00: 313030643a6d726f 6e69702e30303838 ffff80006c727463 ffff0000089635d8
[ 154.727562] 3b20: ffff80001d1ca0cb ffff000008af0fa4 ffff80001bdc3b40 ffff000008c8e1dc
[ 154.735648] 3b40: ffff80001bdc3bc0 ffff000008223174 ffff80001be55700 ffff000008c8e1d0
[ 154.743731] 3b60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 154.752354] 3b80: 000000000000011b ffff000008551870 286e697020746567 ffff80001bdc38c0
[ 154.760446] 3ba0: 0000000005f5e0ff 6166203a6c727463 206f742064656c69 ffff0000099e538d
[ 154.767910] 3bc0: ffff0000899e537f 0000000000000006 ffff0000081fc4b8 0000000000000000
[ 154.776085] [<ffff0000083e3adc>] pinctrl_groups_show+0x15c/0x1a0
[ 154.782823] [<ffff000008222abc>] seq_read+0x184/0x460
[ 154.787505] [<ffff000008344120>] full_proxy_read+0x60/0xa8
[ 154.793431] [<ffff0000081f9bec>] __vfs_read+0x1c/0x110
[ 154.799001] [<ffff0000081faff4>] vfs_read+0x84/0x140
[ 154.803860] [<ffff0000081fc4fc>] SyS_read+0x44/0xa0
[ 154.808983] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[ 154.814459] ---[ end trace 4cbb00a92d616b95 ]---
Fixes: 87466ccd9401 ("pinctrl: armada-37xx: Add pin controller support
for Armada 37xx")
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8452494828f74b72b230fd84b8ebc2ca95397716
Author: Jan Kara <jack@suse.cz>
Date: Wed Aug 2 12:37:16 2017 -0700
xfs: Fix leak of discard bio
commit ea7bd56fa309d10a41b1041827a63c0746c47554 upstream.
The bio describing discard operation is allocated by
__blkdev_issue_discard() which returns us a reference to it. That
reference is never released and thus we leak this bio. Drop the bio
reference once it completes in xlog_discard_endio().
Fixes: 4560e78f40cb55bd2ea8f1ef4001c5baa88531c7
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0af6995672cb78c527661f4c5f6ce9931d96e100
Author: Max Filippov <jcmvbkbc@gmail.com>
Date: Tue Aug 1 11:02:46 2017 -0700
xtensa: don't limit csum_partial export by CONFIG_NET
commit 7f81e55c737a8fa82c71f290945d729a4902f8d2 upstream.
csum_partial and csum_partial_copy_generic are defined unconditionally
and are available even when CONFIG_NET is disabled. They are used not
only by the network drivers, but also by scsi and media.
Don't limit these functions export by CONFIG_NET.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 094849d602a0e8bbe90464b209521159cbd8ecea
Author: Max Filippov <jcmvbkbc@gmail.com>
Date: Tue Aug 1 11:15:15 2017 -0700
xtensa: mm/cache: add missing EXPORT_SYMBOLs
commit bc652eb6a0d5cffaea7dc8e8ad488aab2a1bf1ed upstream.
Functions clear_user_highpage, copy_user_highpage, flush_dcache_page,
local_flush_cache_range and local_flush_cache_page may be used from
modules. Export them.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5e96389b3adc71ded6075bfad5d179c3ace8b138
Author: Max Filippov <jcmvbkbc@gmail.com>
Date: Fri Jul 28 17:42:59 2017 -0700
xtensa: fix cache aliasing handling code for WT cache
commit 6d0f581d1768d3eaba15776e7dd1fdfec10cfe36 upstream.
Currently building kernel for xtensa core with aliasing WT cache fails
with the following messages:
mm/memory.c:2152: undefined reference to `flush_dcache_page'
mm/memory.c:2332: undefined reference to `local_flush_cache_page'
mm/memory.c:1919: undefined reference to `local_flush_cache_range'
mm/memory.c:4179: undefined reference to `copy_to_user_page'
mm/memory.c:4183: undefined reference to `copy_from_user_page'
This happens because implementation of these functions is only compiled
when data cache is WB, which looks wrong: even when data cache doesn't
need flushing it still needs invalidation. The functions like
__flush_[invalidate_]dcache_* are correctly defined for both WB and WT
caches (and even if they weren't that'd still be ok, just slower).
Fix this by providing the same implementation of the above functions for
both WB and WT cache.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5c1d458de22bfde86efb8f59fbd318166961376d
Author: Mel Gorman <mgorman@suse.de>
Date: Wed Aug 9 08:27:11 2017 +0100
futex: Remove unnecessary warning from get_futex_key
commit 48fb6f4db940e92cfb16cd878cddd59ea6120d06 upstream.
Commit 65d8fc777f6d ("futex: Remove requirement for lock_page() in
get_futex_key()") removed an unnecessary lock_page() with the
side-effect that page->mapping needed to be treated very carefully.
Two defensive warnings were added in case any assumption was missed and
the first warning assumed a correct application would not alter a
mapping backing a futex key. Since merging, it has not triggered for
any unexpected case but Mark Rutland reported the following bug
triggering due to the first warning.
kernel BUG at kernel/futex.c:679!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 3695 Comm: syz-executor1 Not tainted 4.13.0-rc3-00020-g307fec773ba3 #3
Hardware name: linux,dummy-virt (DT)
task: ffff80001e271780 task.stack: ffff000010908000
PC is at get_futex_key+0x6a4/0xcf0 kernel/futex.c:679
LR is at get_futex_key+0x6a4/0xcf0 kernel/futex.c:679
pc : [<ffff00000821ac14>] lr : [<ffff00000821ac14>] pstate: 80000145
The fact that it's a bug instead of a warning was due to an unrelated
arm64 problem, but the warning itself triggered because the underlying
mapping changed.
This is an application issue but from a kernel perspective it's a
recoverable situation and the warning is unnecessary so this patch
removes the warning. The warning may potentially be triggered with the
following test program from Mark although it may be necessary to adjust
NR_FUTEX_THREADS to be a value smaller than the number of CPUs in the
system.
#include <linux/futex.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/syscall.h>
#include <sys/time.h>
#include <unistd.h>
#define NR_FUTEX_THREADS 16
pthread_t threads[NR_FUTEX_THREADS];
void *mem;
#define MEM_PROT (PROT_READ | PROT_WRITE)
#define MEM_SIZE 65536
static int futex_wrapper(int *uaddr, int op, int val,
const struct timespec *timeout,
int *uaddr2, int val3)
{
syscall(SYS_futex, uaddr, op, val, timeout, uaddr2, val3);
}
void *poll_futex(void *unused)
{
for (;;) {
futex_wrapper(mem, FUTEX_CMP_REQUEUE_PI, 1, NULL, mem + 4, 1);
}
}
int main(int argc, char *argv[])
{
int i;
mem = mmap(NULL, MEM_SIZE, MEM_PROT,
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
printf("Mapping @ %p\n", mem);
printf("Creating futex threads...\n");
for (i = 0; i < NR_FUTEX_THREADS; i++)
pthread_create(&threads[i], NULL, poll_futex, NULL);
printf("Flipping mapping...\n");
for (;;) {
mmap(mem, MEM_SIZE, MEM_PROT,
MAP_FIXED | MAP_SHARED | MAP_ANONYMOUS, -1, 0);
}
return 0;
}
Reported-and-tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5f064f8a0d4b4a3d17eda6444a9f06437e34fbe0
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu Aug 10 15:24:24 2017 -0700
mm: fix list corruptions on shmem shrinklist
commit d041353dc98a6339182cd6f628b4c8f111278cb3 upstream.
We saw many list corruption warnings on shmem shrinklist:
WARNING: CPU: 18 PID: 177 at lib/list_debug.c:59 __list_del_entry+0x9e/0xc0
list_del corruption. prev->next should be ffff9ae5694b82d8, but was ffff9ae5699ba960
Modules linked in: intel_rapl sb_edac edac_core x86_pkg_temp_thermal coretemp iTCO_wdt iTCO_vendor_support crct10dif_pclmul crc32_pclmul ghash_clmulni_intel raid0 dcdbas shpchp wmi hed i2c_i801 ioatdma lpc_ich i2c_smbus acpi_cpufreq tcp_diag inet_diag sch_fq_codel ipmi_si ipmi_devintf ipmi_msghandler igb ptp crc32c_intel pps_core i2c_algo_bit i2c_core dca ipv6 crc_ccitt
CPU: 18 PID: 177 Comm: kswapd1 Not tainted 4.9.34-t3.el7.twitter.x86_64 #1
Hardware name: Dell Inc. PowerEdge C6220/0W6W6G, BIOS 2.2.3 11/07/2013
Call Trace:
dump_stack+0x4d/0x66
__warn+0xcb/0xf0
warn_slowpath_fmt+0x4f/0x60
__list_del_entry+0x9e/0xc0
shmem_unused_huge_shrink+0xfa/0x2e0
shmem_unused_huge_scan+0x20/0x30
super_cache_scan+0x193/0x1a0
shrink_slab.part.41+0x1e3/0x3f0
shrink_slab+0x29/0x30
shrink_node+0xf9/0x2f0
kswapd+0x2d8/0x6c0
kthread+0xd7/0xf0
ret_from_fork+0x22/0x30
WARNING: CPU: 23 PID: 639 at lib/list_debug.c:33 __list_add+0x89/0xb0
list_add corruption. prev->next should be next (ffff9ae5699ba960), but was ffff9ae5694b82d8. (prev=ffff9ae5694b82d8).
Modules linked in: intel_rapl sb_edac edac_core x86_pkg_temp_thermal coretemp iTCO_wdt iTCO_vendor_support crct10dif_pclmul crc32_pclmul ghash_clmulni_intel raid0 dcdbas shpchp wmi hed i2c_i801 ioatdma lpc_ich i2c_smbus acpi_cpufreq tcp_diag inet_diag sch_fq_codel ipmi_si ipmi_devintf ipmi_msghandler igb ptp crc32c_intel pps_core i2c_algo_bit i2c_core dca ipv6 crc_ccitt
CPU: 23 PID: 639 Comm: systemd-udevd Tainted: G W 4.9.34-t3.el7.twitter.x86_64 #1
Hardware name: Dell Inc. PowerEdge C6220/0W6W6G, BIOS 2.2.3 11/07/2013
Call Trace:
dump_stack+0x4d/0x66
__warn+0xcb/0xf0
warn_slowpath_fmt+0x4f/0x60
__list_add+0x89/0xb0
shmem_setattr+0x204/0x230
notify_change+0x2ef/0x440
do_truncate+0x5d/0x90
path_openat+0x331/0x1190
do_filp_open+0x7e/0xe0
do_sys_open+0x123/0x200
SyS_open+0x1e/0x20
do_syscall_64+0x61/0x170
entry_SYSCALL64_slow_path+0x25/0x25
The problem is that shmem_unused_huge_shrink() moves entries from the
global sbinfo->shrinklist to its local lists and then releases the
spinlock. However, a parallel shmem_setattr() could access one of these
entries directly and add it back to the global shrinklist if it is
removed, with the spinlock held.
The logic itself looks solid since an entry could be either in a local
list or the global list, otherwise it is removed from one of them by
list_del_init(). So probably the race condition is that, one CPU is in
the middle of INIT_LIST_HEAD() but the other CPU calls list_empty()
which returns true too early then the following list_add_tail() sees a
corrupted entry.
list_empty_careful() is designed to fix this situation.
[akpm@linux-foundation.org: add comments]
Link: http://lkml.kernel.org/r/20170803054630.18775-1-xiyou.wangcong@gmail.com
Fixes: 779750d20b93 ("shmem: split huge pages beyond i_size under memory pressure")
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Hugh Dickins <hughd@google.com>
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 10df347170c39961ef93efb070213b68fc674202
Author: Jonathan Toppins <jtoppins@redhat.com>
Date: Thu Aug 10 15:23:35 2017 -0700
mm: ratelimit PFNs busy info message
commit 75dddef32514f7aa58930bde6a1263253bc3d4ba upstream.
The RDMA subsystem can generate several thousand of these messages per
second eventually leading to a kernel crash. Ratelimit these messages
to prevent this crash.
Doug said:
"I've been carrying a version of this for several kernel versions. I
don't remember when they started, but we have one (and only one) class
of machines: Dell PE R730xd, that generate these errors. When it
happens, without a rate limit, we get rcu timeouts and kernel oopses.
With the rate limit, we just get a lot of annoying kernel messages but
the machine continues on, recovers, and eventually the memory
operations all succeed"
And:
"> Well... why are all these EBUSY's occurring? It sounds inefficient
> (at least) but if it is expected, normal and unavoidable then
> perhaps we should just remove that message altogether?
I don't have an answer to that question. To be honest, I haven't
looked real hard. We never had this at all, then it started out of the
blue, but only on our Dell 730xd machines (and it hits all of them),
but no other classes or brands of machines. And we have our 730xd
machines loaded up with different brands and models of cards (for
instance one dedicated to mlx4 hardware, one for qib, one for mlx5, an
ocrdma/cxgb4 combo, etc), so the fact that it hit all of the machines
meant it wasn't tied to any particular brand/model of RDMA hardware.
To me, it always smelled of a hardware oddity specific to maybe the
CPUs or mainboard chipsets in these machines, so given that I'm not an
mm expert anyway, I never chased it down.
A few other relevant details: it showed up somewhere around 4.8/4.9 or
thereabouts. It never happened before, but the prinkt has been there
since the 3.18 days, so possibly the test to trigger this message was
changed, or something else in the allocator changed such that the
situation started happening on these machines?
And, like I said, it is specific to our 730xd machines (but they are
all identical, so that could mean it's something like their specific
ram configuration is causing the allocator to hit this on these
machine but not on other machines in the cluster, I don't want to say
it's necessarily the model of chipset or CPU, there are other bits of
identicalness between these machines)"
Link: http://lkml.kernel.org/r/499c0f6cc10d6eb829a67f2a4d75b4228a9b356e.1501695897.git.jtoppins@redhat.com
Signed-off-by: Jonathan Toppins <jtoppins@redhat.com>
Reviewed-by: Doug Ledford <dledford@redhat.com>
Tested-by: Doug Ledford <dledford@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
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>