commit a0fb6543b40f216f72ef57ff3f61df918047c0fc Author: Greg Kroah-Hartman Date: Wed Aug 16 13:47:18 2017 -0700 Linux 4.12.8 commit 1d4efdd222c4fdf1fd91937fad5c57c78dff4fc1 Author: Michael Neuling 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 Signed-off-by: Michael Ellerman Signed-off-by: Stewart Smith Signed-off-by: Greg Kroah-Hartman commit d40a5450000866c4c5c475bc275042c241953fed Author: Steven J. Hill 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 Reviewed-by: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16906/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit bc60edb6aa3f559bd2b10e9639ad054e2877c7b6 Author: Paul Burton Date: Tue Aug 1 13:32:57 2017 -0700 Revert "MIPS: Don't unnecessarily include kmalloc.h into ." commit ae5b0675942ab30cde96099c68a2290bd1aafcca upstream. Commit 296e46db0073 ("MIPS: Don't unnecessarily include kmalloc.h into .") 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 .") Signed-off-by: Paul Burton Fixes: 296e46db0073 ("MIPS: Don't unnecessarily include kmalloc.h into .") Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16895/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 0a5a16f6cefdd3eea80d96fe7e9df5e7aae0769a Author: Maciej W. Rozycki 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 Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16893/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 888986477133a05348b7f19b628a8941c6032f9c Author: Neil Armstrong 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 Reviewed-by: Jerome Brunet Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit d7b28b4cae66ffdd752bc5b88cf483efe18f5ea6 Author: Neil Armstrong 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 Reviewed-by: Jerome Brunet Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 155407bbf9f21414881e9157d8e43aee3243f91e Author: Thomas Gleixner 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 Cc: Krzysztof Kozlowski Cc: Sylwester Nawrocki Cc: Linus Walleij Cc: Kukjin Kim Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-gpio@vger.kernel.org Acked-by: Tomasz Figa Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 21d22dffc34478d8112b65eaba5664fc80c8d35d Author: Masahiro Yamada 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 Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 338ac5dd59b9c682a63bdb8ad58a171ba06344be Author: Masahiro Yamada 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 Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit be9f65893e3ba91716ad3a85bc4d438c87fb5af1 Author: Andy Shevchenko 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 Acked-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 5fa72b4b746aec106eb3cdfa4760a248e6f0d041 Author: Icenowy Zheng 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 Reviewed-by: Chen-Yu Tsai Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit c75a48eed01f80ac0c17216fd5e404bb07f3a402 Author: Andy Shevchenko 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 Acked-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit cc7f330bed7139e8df059996160d8396708b8a18 Author: Christoph Hellwig 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 Reported-by: Arnd Bergmann Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing") Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit e8a1edad18fae0a967a1225e242908412497ee61 Author: Stefan-Gabriel Mirea 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 Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0e1f0eaed6c20db41ff61e024b361ee3ec9d686c Author: Marc Zyngier 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 Signed-off-by: Marc Zyngier Signed-off-by: Bjorn Helgaas Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit ea9647cf87f59a71845fc3b137772830812ff2cf Author: Marc Zyngier 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 Signed-off-by: Marc Zyngier [bhelgaas: folded in fix for conflict with 52354b9d1f46 ("PCI: Remove __pci_dev_reset() and pci_dev_reset()")] Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit c71305e6854d9b16191be12944029f4f09948022 Author: Christoph Hellwig 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 Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 31e71939a4dd66426da46f76d81e1eb33a817ad1 Author: Christoph Hellwig 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 : http://lkml.kernel.org/r/20170701135323.x5vaj4e2wcs2mcro@mwanda] Link: http://lkml.kernel.org/r/20170601111039.8913-2-hch@lst.de Reported-by: Rakesh Pandit Tested-by: Rakesh Pandit Signed-off-by: Christoph Hellwig Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit b23ef7b8dd7e88c2fbddb4c8b0e13366d6c23766 Author: Sandeep Singh 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 Signed-off-by: Shyam Sundar S K cc: Nehal Shah Reviewed-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 73e7a2dca9ccfc43bd456f97e453176d0c3152c2 Author: Kai-Heng Feng 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 Signed-off-by: Greg Kroah-Hartman commit 488f4d8048e202f9a0053c1fa16d0b17ebe575cb Author: Bin Liu 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 Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit 7ff799af2c2171605e3bcf859e8bf65b21f2fbf8 Author: Alan Stern 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 Reported-and-tested-by: Zdenek Kabelac Reviewed-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit c45923eb94130287582e50d4ac12fd4f5f99c3bb Author: Yoshihiro Shimoda 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 Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit f5324020bcef034f832291bacd0d214d02f27919 Author: Yoshihiro Shimoda 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 Tested-by: Kazuya Mizuguchi Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 7926348676f575024cb7d7e302b6584331208f01 Author: Bart Van Assche 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 Cc: Mike Snitzer Cc: Laurence Oberman Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 67e1a98e3a74a5e728f311f59282a242ab34406d Author: Luis R. Rodriguez 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" Suggested-by: Dmitry Torokhov Tested-by: Martin Fuzzey Reported-by: Martin Fuzzey Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman commit b1b5c0b23a909c0e6f7f8bddc111a68caf128242 Author: Luis R. Rodriguez 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 Reported-by: John Ewalt Reported-by: Jakub Kicinski Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman commit c2c32ed5e6bf3aa81d4c5e04be9f9ec2598ef2db Author: Luis R. Rodriguez 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 Fixes: 5b029624948d ("firmware: do not use fw_lock for fw_state protection") Reported-by: Jakub Kicinski Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman commit f0834df3d97e5cb7370848f668a27a75172dd70d Author: Alan Swanson 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 Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit c208cb9a5596661a3fce7c5352bc9f1f4980f31d Author: Ian Abbott 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 Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 20035abc9e083387a3c163207f185468f5c137bb Author: Hans de Goede 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 Signed-off-by: Hans de Goede Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c1164cc258bc657e31b860ef643d2a83bd064298 Author: Akinobu Mita 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 Signed-off-by: Akinobu Mita Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 39e07a5c112cbac6999c57a87e171c0b3450db87 Author: Lorenzo Bianconi 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 Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8886738d06fac8cee8626a0e042569e9879f02ab Author: Hans de Goede 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 Reviewed-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3fdd0854800e3f026fda1668b0df29a7eb99bd42 Author: Lorenzo Bianconi 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 Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5f26ebe1afdcf348a9daafd419f97bca02e1a49c Author: Mykola Kostenok 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 Reviewed-by: Rick Altherr Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f0ab97d1aa1468d769ce6663e52a850601f68f37 Author: Arnd Bergmann 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 Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9ccd63a6fdbd9ca6b7eb90898da4809c9dfcac6d Author: Rafael J. Wysocki 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 Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 792c00cb2377c373c0d46a249169362244bd9ced Author: Bin Liu 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 Signed-off-by: Greg Kroah-Hartman commit ab51515ece30bd49314579f3323cd055200f7484 Author: Greg Kroah-Hartman 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 Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 492eb6125c83ede23f017c78d948a297adee085e Author: Stefan Triller 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 Reviewed-by: Frans Klaver Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit b576de1e12c980ba6bd38a142f0d58b9048b884d Author: Hector Martin 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 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 59f1322cc1e5fc9a4aa186c1862a027df97132fc Author: Maarten Lankhorst 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 Reported-by: Martin Peres Cc: Martin Peres Fixes: 82cf435b3134 ("drm/i915: Implement color management on bdw/skl/bxt/kbl") Cc: Shashank Sharma Cc: Kiran S Kumar Cc: Kausal Malladi Cc: Lionel Landwerlin Cc: Matt Roper Cc: Daniel Vetter Cc: Jani Nikula 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 (cherry picked from commit 09a92bc8773b4314e02b478e003fe5936ce85adb) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 4eedc8a7f03b15a9daad69b4d54e43f79fa0e16e Author: Wladimir J. van der Laan 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 Reviewed-by: Philipp Zabel Reviewed-by: Christian Gmeiner Signed-off-by: Lucas Stach Signed-off-by: Greg Kroah-Hartman commit 8f0f15cc167d550cb50adbdf14472968b619d244 Author: Lucas Stach 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 Signed-off-by: Lucas Stach Signed-off-by: Archit Taneja Link: https://patchwork.freedesktop.org/patch/msgid/20170710124125.9019-1-l.stach@pengutronix.de Signed-off-by: Greg Kroah-Hartman commit 1cc5cd5b97b51a19cbc0a918787b5a9b63aa7140 Author: Weston Andros Adamson 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 Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 8d189f60407f878aff3bc782e109edd713da9655 Author: Haibo Chen 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 Reviewed-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 3329fe0e05f8eb1a82b04d921b07c2ece0e3c802 Author: Miquel Raynal 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 Fixes: 41b207a70d3a ("mtd: nand: implement the default mtd_ooblayout_ops") Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit 1f2f0f1a75bda5776c5d5aba015fc9b3d1fd82cb Author: Hans de Goede 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 Reviewed-by: Andy Shevchenko Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit cfea0422a154cd45de0ff1a8146d2e303647a5cf Author: Mateusz Jurczyk 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 Fixes: 37fb3a30b462 ("fuse: fix flock") Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 59c74236092d7bf6581dfc9c3b29315d26f6a5eb Author: Nicholas Bellinger 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 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 Tested-by: Justin Maggard Cc: Justin Maggard Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 7b0d44e25fdbf7aa786538cbe2d41f9cae0c5947 Author: Alan Stern 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 Reported-and-tested-by: Arthur Marsh CC: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 428048128bf08766ffddb3571fd5040951dfc8c9 Author: Nicholas Bellinger 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] [] schedule+0x32/0x80 [ 6726.170156] [] schedule_timeout+0x214/0x290 [ 6726.176030] [] ? __send_signal+0x52/0x4a0 [ 6726.181728] [] wait_for_completion+0x96/0x100 [ 6726.187774] [] ? wake_up_state+0x10/0x10 [ 6726.193395] [] iscsit_reset_np_thread+0x62/0xe0 [iscsi_target_mod] [ 6726.201278] [] iscsit_tpg_disable_portal_group+0x96/0x190 [iscsi_target_mod] [ 6726.210033] [] lio_target_tpg_store_enable+0x4f/0xc0 [iscsi_target_mod] [ 6726.218351] [] configfs_write_file+0xaa/0x110 [ 6726.224392] [] vfs_write+0xa4/0x1b0 [ 6726.229576] [] SyS_write+0x41/0xb0 [ 6726.234659] [] 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 Tested-by: Gary Guo Cc: Mike Christie Cc: Hannes Reinecke Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit f838bd1752be732c6c9e0ff50935be5dc4fef48f Author: Varun Prakash 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 Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit a0e1953e0310ad79c9aa6ff019b5425d342566aa Author: Boris Brezillon 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 Fixes: 204e7ecd47e2 ("mtd: nand: Add a few more timings to nand_sdr_timings") Reported-by: Alexander Dahl Reviewed-by: Alexander Dahl Tested-by: Alexander Dahl Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit 867c07788e9764cee324bbe1193ba93febe08e3c Author: Boris Brezillon 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 Fixes: d8e725dd8311 ("mtd: nand: automate NAND timings selection") Reported-by: Alexander Dahl Tested-by: Alexander Dahl Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit a34d48d5ca47c7ba740783ed8490b93499e0f870 Author: Boris Brezillon 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 Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Tested-by: Romain Izard Signed-off-by: Greg Kroah-Hartman commit 0eda7e0bf2389a4dd5e752dcaa4a8d48bb799172 Author: Gregory CLEMENT 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 : [] lr : [] 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] [] pinctrl_groups_show+0x15c/0x1a0 [ 154.782823] [] seq_read+0x184/0x460 [ 154.787505] [] full_proxy_read+0x60/0xa8 [ 154.793431] [] __vfs_read+0x1c/0x110 [ 154.799001] [] vfs_read+0x84/0x140 [ 154.803860] [] SyS_read+0x44/0xa0 [ 154.808983] [] 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 Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 8452494828f74b72b230fd84b8ebc2ca95397716 Author: Jan Kara 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 Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 0af6995672cb78c527661f4c5f6ce9931d96e100 Author: Max Filippov 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 Signed-off-by: Greg Kroah-Hartman commit 094849d602a0e8bbe90464b209521159cbd8ecea Author: Max Filippov 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 Signed-off-by: Greg Kroah-Hartman commit 5e96389b3adc71ded6075bfad5d179c3ace8b138 Author: Max Filippov 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 Signed-off-by: Greg Kroah-Hartman commit 5c1d458de22bfde86efb8f59fbd318166961376d Author: Mel Gorman 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 : [] lr : [] 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 #include #include #include #include #include #include #include #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 Signed-off-by: Mel Gorman Acked-by: Peter Zijlstra (Intel) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5f064f8a0d4b4a3d17eda6444a9f06437e34fbe0 Author: Cong Wang 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 Acked-by: Linus Torvalds Acked-by: Kirill A. Shutemov Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 10df347170c39961ef93efb070213b68fc674202 Author: Jonathan Toppins 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 Reviewed-by: Doug Ledford Tested-by: Doug Ledford Cc: Michal Hocko Cc: Vlastimil Babka Cc: Mel Gorman Cc: Hillf Danton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman