commit a651a90b61d85346decb55c33a079610a8d45bbc Author: Alexandre Frade Date: Fri May 25 15:28:08 2018 -0300 4.14.44-xanmod33 Signed-off-by: Alexandre Frade commit 91e51f553a5ebeeb30f3bc6219b4bad062fa67c7 Merge: f85cfb175b8c 102b97d6241d Author: Alexandre Frade Date: Fri May 25 15:26:47 2018 -0300 Merge tag 'v4.14.44' into 4.14 This is the 4.14.44 stable release commit 102b97d6241d938ac153193504a5936fc0be27ed Author: Greg Kroah-Hartman Date: Fri May 25 16:18:02 2018 +0200 Linux 4.14.44 commit 6b73dfbd3cfc9af7cb50fc109585b8735e404201 Author: James Hogan Date: Tue Jan 16 14:45:21 2018 +0000 rtc: goldfish: Add missing MODULE_LICENSE [ Upstream commit 82d632b85eb89f97051530f556cb49ee1c04bde7 ] Fix the following warning in MIPS allmodconfig by adding a MODULE_LICENSE() at the end of rtc-goldfish.c, based on the file header comment which says GNU General Public License version 2: WARNING: modpost: missing MODULE_LICENSE() in drivers/rtc/rtc-goldfish.o Fixes: f22d9cdcb5eb ("rtc: goldfish: Add RTC driver for Android emulator") Signed-off-by: James Hogan Cc: Miodrag Dinic Cc: Alessandro Zummo Cc: Alexandre Belloni Cc: linux-rtc@vger.kernel.org Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6f34e436509ec90703365972cf0aef90d41c009f Author: Alexandre Belloni Date: Mon Feb 12 23:47:49 2018 +0100 rtc: rp5c01: fix possible race condition [ Upstream commit bcdd559268039d8340d38fa58668393596e29fdc ] The probe function is not allowed to fail after registering the RTC because the following may happen: CPU0: CPU1: sys_load_module() do_init_module() do_one_initcall() cmos_do_probe() rtc_device_register() __register_chrdev() cdev->owner = struct module* open("/dev/rtc0") rtc_device_unregister() module_put() free_module() module_free(mod->module_core) /* struct module *module is now freed */ chrdev_open() spin_lock(cdev_lock) cdev_get() try_module_get() module_is_live() /* dereferences already freed struct module* */ Switch to devm_rtc_allocate_device/rtc_register_device to register the rtc as late as possible. Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 78227b671e0db669eac33f2302bef45a7d5ea33a Author: Colin Ian King Date: Thu Feb 15 19:36:14 2018 +0000 rtc: tx4939: avoid unintended sign extension on a 24 bit shift [ Upstream commit 347876ad47b9923ce26e686173bbf46581802ffa ] The shifting of buf[5] by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to an unsigned long. If the top bit of buf[5] is set then all then all the upper bits sec end up as also being set because of the sign-extension. Fix this by casting buf[5] to an unsigned long before the shift. Detected by CoverityScan, CID#1465292 ("Unintended sign extension") Fixes: 0e1492330cd2 ("rtc: add rtc-tx4939 driver") Signed-off-by: Colin Ian King Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 459aa4904ab20d0544dc3e237d264e7211fc7aa5 Author: Alexandre Belloni Date: Sun Feb 25 21:14:31 2018 +0100 rtc: m41t80: fix race conditions [ Upstream commit 10d0c768cc6d581523d673b9d1b54213f8a5eb24 ] The IRQ is requested before the struct rtc is allocated and registered, but this struct is used in the IRQ handler, leading to: Unable to handle kernel NULL pointer dereference at virtual address 0000017c pgd = a38a2f9b [0000017c] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 PID: 613 Comm: irq/48-m41t80 Not tainted 4.16.0-rc1+ #42 Hardware name: Atmel SAMA5 PC is at mutex_lock+0x14/0x38 LR is at m41t80_handle_irq+0x1c/0x9c pc : [] lr : [] psr: 20000013 sp : dec73f30 ip : 00000000 fp : dec56d98 r10: df437cf0 r9 : c0a03008 r8 : c0145ffc r7 : df5c4300 r6 : dec568d0 r5 : df593000 r4 : 0000017c r3 : df592800 r2 : 60000013 r1 : df593000 r0 : 0000017c Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c53c7d Table: 20004059 DAC: 00000051 Process irq/48-m41t80 (pid: 613, stack limit = 0xb52d091e) Stack: (0xdec73f30 to 0xdec74000) 3f20: dec56840 df5c4300 00000001 df5c4300 3f40: c0145ffc c0146018 dec56840 ffffe000 00000001 c0146290 dec567c0 00000000 3f60: c0146084 ed7c9a62 c014615c dec56d80 dec567c0 00000000 dec72000 dec56840 3f80: c014615c c012ffc0 dec72000 dec567c0 c012fe80 00000000 00000000 00000000 3fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 29282726 2d2c2b2a [] (mutex_lock) from [] (m41t80_handle_irq+0x1c/0x9c) [] (m41t80_handle_irq) from [] (irq_thread_fn+0x1c/0x54) [] (irq_thread_fn) from [] (irq_thread+0x134/0x1c0) [] (irq_thread) from [] (kthread+0x140/0x148) [] (kthread) from [] (ret_from_fork+0x14/0x2c) Exception stack(0xdec73fb0 to 0xdec73ff8) 3fa0: 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Code: e3c33d7f e3c3303f f5d0f000 e593300c (e1901f9f) ---[ end trace 22b027302eb7c604 ]--- genirq: exiting task "irq/48-m41t80" (613) is an active IRQ thread (irq 48) Also, there is another possible race condition. The probe function is not allowed to fail after the RTC is registered because the following may happen: CPU0: CPU1: sys_load_module() do_init_module() do_one_initcall() cmos_do_probe() rtc_device_register() __register_chrdev() cdev->owner = struct module* open("/dev/rtc0") rtc_device_unregister() module_put() free_module() module_free(mod->module_core) /* struct module *module is now freed */ chrdev_open() spin_lock(cdev_lock) cdev_get() try_module_get() module_is_live() /* dereferences already freed struct module* */ Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc before requesting the IRQ and register it as late as possible. Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6266010c38950eec0dd304d04a79540e6115b71b Author: Alexandre Belloni Date: Wed Feb 21 11:57:05 2018 +0100 rtc: rk808: fix possible race condition [ Upstream commit 201fac95e799c3d0304ec724d555e1251b9f6e84 ] The probe function is not allowed to fail after registering the RTC because the following may happen: CPU0: CPU1: sys_load_module() do_init_module() do_one_initcall() cmos_do_probe() rtc_device_register() __register_chrdev() cdev->owner = struct module* open("/dev/rtc0") rtc_device_unregister() module_put() free_module() module_free(mod->module_core) /* struct module *module is now freed */ chrdev_open() spin_lock(cdev_lock) cdev_get() try_module_get() module_is_live() /* dereferences already freed struct module* */ Switch to devm_rtc_allocate_device/rtc_register_device to register the rtc as late as possible. Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6c1c17116484cf376aee8a072fa37553da9ac0bd Author: Alexandre Belloni Date: Thu Mar 8 23:27:31 2018 +0100 rtc: hctosys: Ensure system time doesn't overflow time_t [ Upstream commit b3a5ac42ab18b7d1a8f2f072ca0ee76a3b754a43 ] On 32bit platforms, time_t is still a signed 32bit long. If it is overflowed, userspace and the kernel cant agree on the current system time. This causes multiple issues, in particular with systemd: https://github.com/systemd/systemd/issues/1143 A good workaround is to simply avoid using hctosys which is something I greatly encourage as the time is better set by userspace. However, many distribution enable it and use systemd which is rendering the system unusable in case the RTC holds a date after 2038 (and more so after 2106). Many drivers have workaround for this case and they should be eliminated so there is only one place left to fix when userspace is able to cope with dates after the 31bit overflow. Acked-by: Arnd Bergmann Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 731d965a587c96ebd319bca7e09448482e01d7b1 Author: Bryan O'Donoghue Date: Wed Mar 28 20:14:05 2018 +0100 rtc: snvs: Fix usage of snvs_rtc_enable [ Upstream commit 1485991c024603b2fb4ae77beb7a0d741128a48e ] commit 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces the SNVS RTC driver with a function snvs_rtc_enable(). snvs_rtc_enable() can return an error on the enable path however this driver does not currently trap that failure on the probe() path and consequently if enabling the RTC fails we encounter a later error spinning forever in rtc_write_sync_lp(). [ 36.093481] [] (__irq_svc) from [] (_raw_spin_unlock_irqrestore+0x34/0x44) [ 36.102122] [] (_raw_spin_unlock_irqrestore) from [] (regmap_read+0x4c/0x5c) [ 36.110938] [] (regmap_read) from [] (rtc_write_sync_lp+0x6c/0x98) [ 36.118881] [] (rtc_write_sync_lp) from [] (snvs_rtc_alarm_irq_enable+0x40/0x4c) [ 36.128041] [] (snvs_rtc_alarm_irq_enable) from [] (rtc_timer_do_work+0xd8/0x1a8) [ 36.137291] [] (rtc_timer_do_work) from [] (process_one_work+0x28c/0x76c) [ 36.145840] [] (process_one_work) from [] (worker_thread+0x34/0x58c) [ 36.153961] [] (worker_thread) from [] (kthread+0x138/0x150) [ 36.161388] [] (kthread) from [] (ret_from_fork+0x14/0x20) [ 36.168635] rcu_sched kthread starved for 2602 jiffies! g496 c495 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0 [ 36.178564] rcu_sched R running task 0 8 2 0x00000000 [ 36.185664] [] (__schedule) from [] (schedule+0x3c/0xa0) [ 36.192739] [] (schedule) from [] (schedule_timeout+0x78/0x4e0) [ 36.200422] [] (schedule_timeout) from [] (rcu_gp_kthread+0x648/0x1864) [ 36.208800] [] (rcu_gp_kthread) from [] (kthread+0x138/0x150) [ 36.216309] [] (kthread) from [] (ret_from_fork+0x14/0x20) This patch fixes by parsing the result of rtc_write_sync_lp() and propagating both in the probe and elsewhere. If the RTC doesn't start we don't proceed loading the driver and don't get into this loop mess later on. Fixes: 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") Signed-off-by: Bryan O'Donoghue Acked-by: Shawn Guo Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8293e6238e03a91cd74c60d2901bc0a825526b9f Author: Uwe Kleine-König Date: Thu Jan 25 14:30:43 2018 +0100 serial: altera: ensure port->regshift is honored consistently [ Upstream commit 0e254963b6ba4d63ac911e79537fea38dd03dc50 ] Most register accesses in the altera driver honor port->regshift by using altera_uart_writel(). There are a few accesses however that were missed when the driver was converted to use port->regshift and some others were added later in commit 4d9d7d896d77 ("serial: altera_uart: add earlycon support"). Fixes: 2780ad42f5fe ("tty: serial: altera_uart: Use port->regshift to store bus shift") Signed-off-by: Uwe Kleine-König Acked-by: Tobias Klauser Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e10bbc220e1a37ce0292217dbbc98773b330b525 Author: Vignesh R Date: Thu Feb 8 18:25:41 2018 +0530 serial: 8250: Don't service RX FIFO if interrupts are disabled [ Upstream commit 2e9fe539108320820016f78ca7704a7342788380 ] Currently, data in RX FIFO is read based on UART_LSR register state even if RDI and RLSI interrupts are disabled in UART_IER register. This is because when IRQ handler is called due to TX FIFO empty event, RX FIFO is serviced based on UART_LSR register status instead of UART_IIR status. This defeats the purpose of disabling UART RX FIFO interrupts during throttling(see, omap_8250_throttle()) as IRQ handler continues to drain UART RX FIFO resulting in overflow of buffer at tty layer. Fix this by making sure that driver drains UART RX FIFO only when UART_IIR_RDI is set along with UART_LSR_BI or UART_LSR_DR bits. Signed-off-by: Vignesh R Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1c447ea137037fb3dae452efc28f607020df76d0 Author: Geert Uytterhoeven Date: Fri Feb 23 14:38:29 2018 +0100 serial: arc_uart: Fix out-of-bounds access through DT alias [ Upstream commit f9f5786987e81d166c60833edcb7d1836aa16944 ] The arc_uart_ports[] array is indexed using a value derived from the "serialN" alias in DT, which may lead to an out-of-bounds access. Fix this by adding a range check. Note that the array size is defined by a Kconfig symbol (CONFIG_SERIAL_ARC_NR_PORTS), so this can even be triggered using a legitimate DTB. Fixes: ea28fd56fcde69af ("serial/arc-uart: switch to devicetree based probing") Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit db69a1a58844c2227e93fc023821f67279d60573 Author: Geert Uytterhoeven Date: Fri Feb 23 14:38:30 2018 +0100 serial: fsl_lpuart: Fix out-of-bounds access through DT alias [ Upstream commit ffab87fdecc655cc676f8be8dd1a2c5e22bd6d47 ] The lpuart_ports[] array is indexed using a value derived from the "serialN" alias in DT, which may lead to an out-of-bounds access. Fix this by adding a range check. Fixes: c9e2e946fb0ba5d2 ("tty: serial: add Freescale lpuart driver support") Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 24182ff06635a2c5fdbe389e443d7b66416a421f Author: Geert Uytterhoeven Date: Fri Feb 23 14:38:31 2018 +0100 serial: imx: Fix out-of-bounds access through serial port index [ Upstream commit 5673444821406dda5fc25e4b52aca419f8065a19 ] The imx_ports[] array is indexed using a value derived from the "serialN" alias in DT, or from platform data, which may lead to an out-of-bounds access. Fix this by adding a range check. Fixes: ff05967a07225ab6 ("serial/imx: add of_alias_get_id() reference back") Signed-off-by: Geert Uytterhoeven Reviewed-by: Uwe Kleine-König Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5f53807e751ef0b01e56d46d06d1f1a5828de249 Author: Geert Uytterhoeven Date: Fri Feb 23 14:38:32 2018 +0100 serial: mxs-auart: Fix out-of-bounds access through serial port index [ Upstream commit dd345a31bfdec350d2593e6de5964e55c7f19c76 ] The auart_port[] array is indexed using a value derived from the "serialN" alias in DT, or from platform data, which may lead to an out-of-bounds access. Fix this by adding a range check. Fixes: 1ea6607d4cdc9179 ("serial: mxs-auart: Allow device tree probing") Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 491e61fe3c53d1f5cf74da10b1474cca0a6bbaaa Author: Geert Uytterhoeven Date: Fri Feb 23 14:38:34 2018 +0100 serial: samsung: Fix out-of-bounds access through serial port index [ Upstream commit 49ee23b71877831ac087d6083f6f397dc19c9664 ] The s3c24xx_serial_ports[] array is indexed using a value derived from the "serialN" alias in DT, or from an incrementing probe index, which may lead to an out-of-bounds access. Fix this by adding a range check. Note that the array size is defined by a Kconfig symbol (CONFIG_SERIAL_SAMSUNG_UARTS), so this can even be triggered using a legitimate DTB or legitimate board code. Fixes: 13a9f6c64fdc55eb ("serial: samsung: Consider DT alias when probing ports") Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit eb81dd52b425dc0a653a1c7944188c09c6be0aee Author: Geert Uytterhoeven Date: Fri Feb 23 14:38:35 2018 +0100 serial: sh-sci: Fix out-of-bounds access through DT alias [ Upstream commit 090fa4b0dccfa3d04e1c5ab0fe4eba16e6713895 ] The sci_ports[] array is indexed using a value derived from the "serialN" alias in DT, which may lead to an out-of-bounds access. Fix this by adding a range check. Note that the array size is defined by a Kconfig symbol (CONFIG_SERIAL_SH_SCI_NR_UARTS), so this can even be triggered using a legitimate DTB. Fixes: 97ed9790c514066b ("serial: sh-sci: Remove unused platform data capabilities field") Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d1e7f966521d9f264ae662394210eb44b0b10074 Author: Geert Uytterhoeven Date: Fri Feb 23 14:38:37 2018 +0100 serial: xuartps: Fix out-of-bounds access through DT alias [ Upstream commit e7d75e18d0fc3f7193b65282b651f980c778d935 ] The cdns_uart_port[] array is indexed using a value derived from the "serialN" alias in DT, which may lead to an out-of-bounds access. Fix this by adding a range check. Fixes: 928e9263492069ee ("tty: xuartps: Initialize ports according to aliases") Signed-off-by: Geert Uytterhoeven Reviewed-by: Michal Simek Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 604e648e8bf02b2995afa3b825a074943a5ec4ed Author: Colin Ian King Date: Wed Jan 31 12:33:09 2018 -0500 media: cx25821: prevent out-of-bounds read on array card [ Upstream commit 67300abdbe9f1717532aaf4e037222762716d0f6 ] Currently an out of range dev->nr is detected by just reporting the issue and later on an out-of-bounds read on array card occurs because of this. Fix this by checking the upper range of dev->nr with the size of array card (removes the hard coded size), move this check earlier and also exit with the error -ENOSYS to avoid the later out-of-bounds array read. Detected by CoverityScan, CID#711191 ("Out-of-bounds-read") Fixes: commit 02b20b0b4cde ("V4L/DVB (12730): Add conexant cx25821 driver") Signed-off-by: Colin Ian King Signed-off-by: Hans Verkuil [hans.verkuil@cisco.com: %ld -> %zd] Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9b7c44c4394621bec8ff7753089441e0ea9323ca Author: Hans Verkuil Date: Thu Feb 1 02:36:33 2018 -0500 media: vivid: fix incorrect capabilities for radio [ Upstream commit 65243386f41d38460bfd4375d231a7c0346d0401 ] The vivid driver has two custom controls that change the behavior of RDS. Depending on the control setting the V4L2_CAP_READWRITE capability is toggled. However, after an earlier commit the capability was no longer set correctly. This is now fixed. Fixes: 9765a32cd8 ("vivid: set device_caps in video_device") Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8cfcd5bbb72319fc4cc338cbfb08ae51370ae734 Author: Masami Hiramatsu Date: Tue Feb 6 03:02:23 2018 -0500 media: vb2: Fix videobuf2 to map correct area [ Upstream commit d13a0139d7874a0577b5955d6eed895517d23b72 ] Fixes vb2_vmalloc_get_userptr() to ioremap correct area. Since the current code does ioremap the page address, if the offset > 0, it does not do ioremap the last page and results in kernel panic. This fixes to pass the size + offset to ioremap so that ioremap can map correct area. Also, this uses __pfn_to_phys() to get the physical address of given PFN. Signed-off-by: Masami Hiramatsu Reported-by: Takao Orito Reported-by: Fumihiro ATSUMI Reviewed-by: Marek Szyprowski Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 81173a58638f3e54e6af21ec2cc218b6cb733daf Author: Kieran Bingham Date: Mon Jan 8 13:14:04 2018 -0500 media: i2c: adv748x: fix HDMI field heights [ Upstream commit 9f564184e6cc21a86c26bab920afac1bab7653ff ] The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field types. The correct specification for the height on the mbus is the image height, in this instance, the field height. The AFE component already correctly adjusts the height on the mbus, but the HDMI component got left behind. Adjust the mbus height to correctly describe the image height of the fields when processing interlaced video for HDMI pipelines. Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver") Reviewed-by: Niklas Söderlund Signed-off-by: Kieran Bingham Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 93c72937a26bf899b10b2af6193f89f9c113577c Author: Laurent Pinchart Date: Sun Dec 3 05:06:57 2017 -0500 media: v4l: vsp1: Fix display stalls when requesting too many inputs [ Upstream commit 5e3e4cb5e24b92773b194aa90066170b12133bc6 ] Make sure we don't accept more inputs than the hardware can handle. This is a temporary fix to avoid display stall, we need to instead allocate the BRU or BRS to display pipelines dynamically based on the number of planes they each use. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d600eadf7d80edf8575462d8a0c117adbbceba52 Author: Brad Love Date: Thu Jan 4 19:04:15 2018 -0500 media: em28xx: Add Hauppauge SoloHD/DualHD bulk models [ Upstream commit f2a326c928cca1f5e36a3dceaf66e8c6b34e9cb8 ] Add additional pids to driver list Signed-off-by: Brad Love Reviewed-by: Michael Ira Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d62c8d80f84fa4c9dba0f61b27376339afde2f35 Author: Brad Love Date: Fri Jan 5 09:57:13 2018 -0500 media: lgdt3306a: Fix a double kfree on i2c device remove [ Upstream commit 94448e21cf08b10f7dc7acdaca387594370396b0 ] Both lgdt33606a_release and lgdt3306a_remove kfree state, but _release is called first, then _remove operates on states members before kfree'ing it. This can lead to random oops/GPF/etc on USB disconnect. Signed-off-by: Brad Love Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 53ba3526baad31528f72bd57bbc1b66378b60c3f Author: Arnd Bergmann Date: Tue Jan 16 16:52:15 2018 -0500 media: s3c-camif: fix out-of-bounds array access [ Upstream commit a398e043637a4819a0e96467bfecaabf3224dd62 ] While experimenting with older compiler versions, I ran into a warning that no longer shows up on gcc-4.8 or newer: drivers/media/platform/s3c-camif/camif-capture.c: In function '__camif_subdev_try_format': drivers/media/platform/s3c-camif/camif-capture.c:1265:25: error: array subscript is below array bounds This is an off-by-one bug, leading to an access before the start of the array, while newer compilers silently assume this undefined behavior cannot happen and leave the loop at index 0 if no other entry matches. As Sylvester explains, we actually need to ensure that the value is within the range, so this reworks the loop to be easier to parse correctly, and an additional check to fall back on the first format value for any unexpected input. I found an existing gcc bug for it and added a reduced version of the function there. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69249#c3 Fixes: babde1c243b2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface") Signed-off-by: Arnd Bergmann Reviewed-by: Laurent Pinchart Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5ebcb461274843c4f2d7c6de68ab05caddedd091 Author: Brad Love Date: Tue Mar 6 14:15:36 2018 -0500 media: cx23885: Set subdev host data to clk_freq pointer [ Upstream commit 5ceade1d97fc6687e050c44c257382c192f56276 ] Currently clk_freq is ignored entirely, because the cx235840 driver configures the xtal at the chip defaults. This is an issue if a board is produced with a non-default frequency crystal. If clk_freq is not zero the cx25840 will attempt to use the setting provided, or fall back to defaults otherwise. Signed-off-by: Brad Love Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 24858b9c030ae48d876f9102a142f69c696762e5 Author: Brad Love Date: Tue Mar 6 14:15:37 2018 -0500 media: cx23885: Override 888 ImpactVCBe crystal frequency [ Upstream commit 779c79d4b833ec646b0aed878da38edb45bbe156 ] Hauppauge produced a revision of ImpactVCBe using an 888, with a 25MHz crystal, instead of using the default third overtone 50Mhz crystal. This overrides that frequency so that the cx25840 is properly configured. Without the proper crystal setup the cx25840 cannot load the firmware or decode video. Signed-off-by: Brad Love Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1c94830eeea533f617a0642e98dbac51214329a1 Author: Akinobu Mita Date: Mon Mar 19 12:14:17 2018 -0400 media: ov5645: add missing of_node_put() in error path [ Upstream commit 06fe932307d58108a11c3e603517dd2a73a57b80 ] The device node obtained with of_graph_get_next_endpoint() should be released by calling of_node_put(). But it was not released when v4l2_fwnode_endpoint_parse() failed. This change moves the of_node_put() call before the error check and fixes the issue. Cc: Mauro Carvalho Chehab Signed-off-by: Akinobu Mita Acked-by: Todor Tomov Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cc4b4af51c13c0aec5c0368986295eb9dcfcdab1 Author: Mauro Carvalho Chehab Date: Mon Feb 19 13:23:39 2018 -0500 media: Don't let tvp5150_get_vbi() go out of vbi_ram_default array [ Upstream commit 3dd6b560dc5d59e7cb6dbda6e85dc9af7925fcf8 ] As pointed by Dan, possible values for bits[3:0] of te Line Mode Registers can range from 0x0 to 0xf, but the check logic allow values ranging from 0x0 to 0xe. As static arrays are initialized with zero, using a value without an explicit initializer at the array won't cause any harm. Reported-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 07999bccf2e01312bc299c60aca1b18ba83626be Author: Mauro Carvalho Chehab Date: Sun Feb 11 05:44:21 2018 -0500 media: dmxdev: fix error code for invalid ioctls [ Upstream commit a145f64c6107d3aa5a7cec9f8977d04ac2a896c9 ] Returning -EINVAL when an ioctl is not implemented is a very bad idea, as it is hard to distinguish from other error contitions that an ioctl could lead. Replace it by its right error code: -ENOTTY. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7bc147610d1e74ca70ffb8a48d8fc44621bfc760 Author: Andrzej Hajda Date: Fri Feb 16 15:57:48 2018 +0100 clk: samsung: exynos3250: Fix PLL rates [ Upstream commit a8321e7887410a2b2e80ab89d1ef7b30562658ea ] Rates declared in PLL rate tables should match exactly rates calculated from PLL coefficients. If that is not the case, rate of the PLL's child clock might be set not as expected. For instance, if in the PLL rates table we have a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate will return 393216003. If we now attempt to set rate of a PLL's child divider clock to 393216000/2 its rate will be 131072001, rather than 196608000. That is, the divider will be set to 3 instead of 2, because 393216003/2 is greater than 196608000. To fix this issue declared rates are changed to exactly match rates generated by the PLL, as calculated from the P, M, S, K coefficients. In this patch an erroneous P value for 74176002 output frequency is also corrected. Signed-off-by: Andrzej Hajda Acked-by: Chanwoo Choi Acked-by: Tomasz Figa Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3fabe01cdf75445e432c7f730a6a4d082795c60a Author: Andrzej Hajda Date: Fri Feb 16 15:57:49 2018 +0100 clk: samsung: exynos5250: Fix PLL rates [ Upstream commit 2ac051eeabaa411ef89ae7cd5bb8e60cb41ad780 ] Rates declared in PLL rate tables should match exactly rates calculated from PLL coefficients. If that is not the case, rate of the PLL's child clock might be set not as expected. For instance, if in the PLL rates table we have a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate will return 393216003. If we now attempt to set rate of a PLL's child divider clock to 393216000/2 its rate will be 131072001, rather than 196608000. That is, the divider will be set to 3 instead of 2, because 393216003/2 is greater than 196608000. To fix this issue declared rates are changed to exactly match rates generated by the PLL, as calculated from the P, M, S, K coefficients. Signed-off-by: Andrzej Hajda Acked-by: Chanwoo Choi Acked-by: Tomasz Figa Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 90e14be44331243de96ad040c50abc3111a140d5 Author: Andrzej Hajda Date: Fri Feb 16 15:57:51 2018 +0100 clk: samsung: exynos5433: Fix PLL rates [ Upstream commit ab0447845cffc0fd752df2ccd6b4e34006000ce4 ] Rates declared in PLL rate tables should match exactly rates calculated from the PLL coefficients. If that is not the case, rate of the PLL's child clock might be set not as expected. For instance, if in the PLL rates table we have a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate will return 393216003. If we now attempt to set rate of a PLL's child divider clock to 393216000/2 its rate will be 131072001, rather than 196608000. That is, the divider will be set to 3 instead of 2, because 393216003/2 is greater than 196608000. To fix this issue declared rates are changed to exactly match rates generated by the PLL, as calculated from the P, M, S, K coefficients. Signed-off-by: Andrzej Hajda Acked-by: Tomasz Figa Acked-by: Chanwoo Choi Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 256499854098069898ca1a35818961aa15c3cd83 Author: Andrzej Hajda Date: Fri Feb 16 15:57:50 2018 +0100 clk: samsung: exynos5260: Fix PLL rates [ Upstream commit cdb68fbd4e7962be742c4f29475220c5bf28d8a5 ] Rates declared in PLL rate tables should match exactly rates calculated from the PLL coefficients. If that is not the case, rate of the PLL's child clock might be set not as expected. For instance, if in the PLL rates table we have a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate will return 393216003. If we now attempt to set rate of a PLL's child divider clock to 393216000/2 its rate will be 131072001, rather than 196608000. That is, the divider will be set to 3 instead of 2, because 393216003/2 is greater than 196608000. To fix this issue declared rates are changed to exactly match rates generated by the PLL, as calculated from the P, M, S, K coefficients. Signed-off-by: Andrzej Hajda Acked-by: Tomasz Figa Acked-by: Chanwoo Choi Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8f4eef93e1abc3956f67865069df88df85c5c28e Author: Andrzej Hajda Date: Fri Feb 16 15:57:52 2018 +0100 clk: samsung: exynos7: Fix PLL rates [ Upstream commit 7e4db0c2836e892766565965207eee051c8037b9 ] Rates declared in PLL rate tables should match exactly rates calculated from the PLL coefficients. If that is not the case, rate of the PLL's child clock might be set not as expected. For instance, if in the PLL rates table we have a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate will return 393216003. If we now attempt to set rate of a PLL's child divider clock to 393216000/2 its rate will be 131072001, rather than 196608000. That is, the divider will be set to 3 instead of 2, because 393216003/2 is greater than 196608000. To fix this issue declared rates are changed to exactly match rates generated by the PLL, as calculated from the P, M, S, K coefficients. Signed-off-by: Andrzej Hajda Acked-by: Tomasz Figa Acked-by: Chanwoo Choi Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 264530c6ad12fbf04a5cff9461fda7b925d2e67c Author: Andrzej Hajda Date: Fri Feb 16 15:57:53 2018 +0100 clk: samsung: s3c2410: Fix PLL rates [ Upstream commit 179db533c08431f509a3823077549773d519358b ] Rates declared in PLL rate tables should match exactly rates calculated from the PLL coefficients. If that is not the case, rate of the PLL's child clock might be set not as expected. For instance, if in the PLL rates table we have a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate will return 393216003. If we now attempt to set rate of a PLL's child divider clock to 393216000/2 its rate will be 131072001, rather than 196608000. That is, the divider will be set to 3 instead of 2, because 393216003/2 is greater than 196608000. To fix this issue declared rates are changed to exactly match rates generated by the PLL, as calculated from the P, M, S, K coefficients. Signed-off-by: Andrzej Hajda Acked-by: Tomasz Figa Acked-by: Chanwoo Choi Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 573dda18a809cce3ae4dc94de614cc6fe74ce176 Author: Shawn Lin Date: Mon Mar 5 11:25:58 2018 +0800 clk: rockchip: Prevent calculating mmc phase if clock rate is zero [ Upstream commit 4bf59902b50012b1dddeeaa23b217d9c4956cdda ] The MMC sample and drv clock for rockchip platforms are derived from the bus clock output to the MMC/SDIO card. So it should never happens that the clk rate is zero given it should inherits the clock rate from its parent. If something goes wrong and makes the clock rate to be zero, the calculation would be wrong but may still make the mmc tuning process work luckily. However it makes people harder to debug when the following data transfer is unstable. Signed-off-by: Shawn Lin Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 04adc8209a9a6518ce8ff545e9d97dbf6d3b8adf Author: Marcel Ziswiler Date: Fri Feb 23 00:04:51 2018 +0100 clk: tegra: Fix pll_u rate configuration [ Upstream commit c35b518f9ba06c9de79fb3ff62eed7462d804995 ] Turns out latest upstream U-Boot does not configure/enable pll_u which leaves it at some default rate of 500 kHz: root@apalis-t30:~# cat /sys/kernel/debug/clk/clk_summary | grep pll_u pll_u 3 3 0 500000 0 Of course this won't quite work leading to the following messages: [ 6.559593] usb 2-1: new full-speed USB device number 2 using tegra- ehci [ 11.759173] usb 2-1: device descriptor read/64, error -110 [ 27.119453] usb 2-1: device descriptor read/64, error -110 [ 27.389217] usb 2-1: new full-speed USB device number 3 using tegra- ehci [ 32.559454] usb 2-1: device descriptor read/64, error -110 [ 47.929777] usb 2-1: device descriptor read/64, error -110 [ 48.049658] usb usb2-port1: attempt power cycle [ 48.759475] usb 2-1: new full-speed USB device number 4 using tegra- ehci [ 59.349457] usb 2-1: device not accepting address 4, error -110 [ 59.509449] usb 2-1: new full-speed USB device number 5 using tegra- ehci [ 70.069457] usb 2-1: device not accepting address 5, error -110 [ 70.079721] usb usb2-port1: unable to enumerate USB device Fix this by actually allowing the rate also being set from within the Linux kernel. Signed-off-by: Marcel Ziswiler Tested-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 99f29b5c1cc4670b3ea5e2e9013737a6201e49a5 Author: Arnd Bergmann Date: Tue Feb 20 16:15:21 2018 +0100 clk: hisilicon: mark wdt_mux_p[] as const [ Upstream commit df934cbcbff7afbc024bf05f02615917c61f6470 ] The symbol is in the __initconst section but not marked init, which caused a warning when building with LTO. This makes it 'const' as was obviously intended. Signed-off-by: Arnd Bergmann Fixes: c80dfd9bf54e ("clk: hisilicon: add CRG driver for Hi3516CV300 SoC") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2dc1d1a8715ec6e2459f61be70b1faf43af29bf1 Author: Shawn Lin Date: Wed Mar 14 08:28:31 2018 +0800 clk: Don't show the incorrect clock phase [ Upstream commit 1f9c63e8de3d7b377c9d74e4a17524cfb60e6384 ] It's found that the clock phase output from clk_summary is wrong compared to the actual phase reading from the register. cat /sys/kernel/debug/clk/clk_summary | grep sdio_sample sdio_sample 0 1 0 50000000 0 -22 It exposes an issue that clk core, clk_core_get_phase, always returns the cached core->phase which should be either updated by calling clk_set_phase or directly from the first place the clk was registered. When registering the clk, the core->phase geting from ->get_phase() may return negative value indicating error. This is quite common since the clk's phase may be highly related to its parent chain, but it was temporarily orphan when registered, since its parent chains hadn't be ready at that time, so the clk drivers decide to return error in this case. However, if no clk_set_phase is called or maybe the ->set_phase() isn't even implemented, the core->phase would never be updated. This is wrong, and we should try to update it when all its parent chains are settled down, like the way of updating clock rate for that. But it's not deserved to complicate the code now and just update it anyway when calling clk_core_get_phase, which would be much simple and enough. Signed-off-by: Shawn Lin Acked-by: Jerome Brunet Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a225a3ba32137fb61ecf13f9dbe7aeb25e55d7cb Author: Shawn Lin Date: Wed Mar 21 10:39:19 2018 +0800 clk: rockchip: Fix wrong parent for SDMMC phase clock for rk3228 [ Upstream commit 4b0556a441dd37e598887215bc89b49a6ef525b3 ] commit c420c1e4db22 ("clk: rockchip: Prevent calculating mmc phase if clock rate is zero") catches one gremlin again for clk-rk3228.c that the parent of SDMMC phase clock should be sclk_sdmmc0, but not sclk_sdmmc. However, the naming of the sdmmc clocks varies in the manual with the card clock having the 0 while the hclk is named without appended 0. So standardize one one format to prevent confusion, as there also is only one (non-sdio) mmc controller on the soc. Signed-off-by: Shawn Lin Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9311d0b6b4666fed722f712a285b0a7069409f30 Author: Sylwester Nawrocki Date: Mon Feb 5 16:43:56 2018 +0100 ASoC: samsung: i2s: Ensure the RCLK rate is properly determined [ Upstream commit 647d04f8e07afc7c3b7a42b3ee01a8b28db29631 ] If the RCLK mux clock configuration is specified in DT and no set_sysclk() callback is used in the sound card driver the sclk_srcrate field will remain set to 0, leading to an incorrect PSR divider setting. To fix this the frequency value is retrieved from the CLK_I2S_RCLK_SRC clock, so the actual RCLK mux selection is taken into account. Signed-off-by: Sylwester Nawrocki Acked-by: Krzysztof Kozlowski Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27cbb1df79c5079c0cf398f0164d7f5a7c38c268 Author: Ranjani Sridharan Date: Fri Mar 9 11:11:17 2018 -0800 ASoC: topology: create TLV data for dapm widgets [ Upstream commit bde8b3887add8368ecf0ca71117baf2fd56a6fc9 ] This patch adds the change required to create the TLV data for dapm widget kcontrols from topology. This also fixes the following TLV read error shown in amixer while showing the card control contents. "amixer: Control hw:1 element TLV read error: No such device or address" Signed-off-by: Ranjani Sridharan Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fbeec965b8d1ca4005f2b63f70fd6ed54a147027 Author: Sylwester Nawrocki Date: Wed Mar 14 17:41:13 2018 +0100 ASoC: samsung: odroid: Fix 32000 sample rate handling [ Upstream commit 1d22c337dc8f3a25638f7262e7bcb5729a34d140 ] In case of sample rates lower than 44100 currently there is too low MCLK frequency set for the CODEC. Playback fails with following errors: $ speaker-test -c2 -t sine -f 1500 -l2 -r 32000 Sine wave rate is 1500.0000Hz Rate set to 32000Hz (requested 32000Hz) Buffer size range from 128 to 131072 Period size range from 64 to 65536 Using max buffer size 131072 Periods = 4 Unable to set hw params for playback: Invalid argument Setting of hwparams failed: Invalid argument [ 497.883700] max98090 1-0010: Invalid master clock frequency To fix this the I2S root clock's frequency is increased, depending on sampling rate. Signed-off-by: Sylwester Nawrocki Acked-by: Krzysztof Kozlowski Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b3bbda7bad73d900fcc49528712305331a1bd491 Author: Ezequiel Garcia Date: Tue Mar 20 13:03:31 2018 -0300 ASoC: rockchip: rk3288-hdmi-analog: Select needed codecs [ Upstream commit b1d0db067fbe2598d62b248beea5d705a0ea7642 ] The driver does not select all the codec drivers that needs. Fix it by selecting the analog and HDMI codecs. Cc: Sjoerd Simons Signed-off-by: Ezequiel Garcia Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 98ffb5cf47e4d0b9c0bf0f53e20cff00d1ba7ee2 Author: Peter Ujfalusi Date: Tue Feb 20 16:19:05 2018 +0200 ASoC: hdmi-codec: Fix module unloading caused kernel crash [ Upstream commit 5e558f8afaec8957932b1dbe5aeff800f9fc6957 ] The hcp->chmap_info must not be freed up in the hdmi_codec_remove() function as it leads to kernel crash due ALSA core's pcm_chmap_ctl_private_free() is trying to free it up again when the card destroyed via snd_card_free. Commit cd6111b26280a ("ASoC: hdmi-codec: add channel mapping control") should not have added the kfree(hcp->chmap_info); to the hdmi_codec_remove function. Signed-off-by: Peter Ujfalusi Reviewed-by: Jyri Sarha Tested-by: Jyri Sarha Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 48e835f89769a1fcb1cf15259c734600891d87f5 Author: James Smart Date: Tue Jan 30 15:58:45 2018 -0800 scsi: lpfc: Fix frequency of Release WQE CQEs [ Upstream commit 04673e38f56b30cd39b1fa0f386137d818b17781 ] The driver controls when the hardware sends completions that communicate consumption of elements from the WQ. This is done by setting a WQEC bit on a WQE. The current driver sets it on every Nth WQE posting. However, the driver isn't clearing the bit if the WQE is reused. Thus, if the queue depth isn't evenly divisible by N, with enough time, it can be set on every element, creating a lot of overhead and risking CQ full conditions. Correct by clearing the bit when not setting it on an Nth element. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8fd4131a9fcc0ad8a60554c0505804b258362552 Author: James Smart Date: Tue Jan 30 15:58:54 2018 -0800 scsi: lpfc: Fix soft lockup in lpfc worker thread during LIP testing [ Upstream commit 161df4f09987ae2e9f0f97f0b38eee298b4a39ff ] During link bounce testing in a point-to-point topology, the host may enter a soft lockup on the lpfc_worker thread: Call Trace: lpfc_work_done+0x1f3/0x1390 [lpfc] lpfc_do_work+0x16f/0x180 [lpfc] kthread+0xc7/0xe0 ret_from_fork+0x3f/0x70 The driver was simultaneously setting a combination of flags that caused lpfc_do_work()to effectively spin between slow path work and new event data, causing the lockup. Ensure in the typical wq completions, that new event data flags are set if the slow path flag is running. The slow path will eventually reschedule the wq handling. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d5d331cdfcb27e6c5dd5c10ac0452f7442bbc6c5 Author: James Smart Date: Tue Jan 30 15:58:55 2018 -0800 scsi: lpfc: Fix issue_lip if link is disabled [ Upstream commit 2289e9598dde9705400559ca2606fb8c145c34f0 ] The driver ignored checks on whether the link should be kept administratively down after a link bounce. Correct the checks. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a9bcbce385ed5c496a14991039bbdfa69992ae12 Author: Wilfried Weissmann Date: Fri Feb 23 20:52:34 2018 +0100 scsi: mvsas: fix wrong endianness of sgpio api [ Upstream commit e75fba9c0668b3767f608ea07485f48d33c270cf ] This patch fixes the byte order of the SGPIO api and brings it back in sync with ledmon v0.80 and above. [mkp: added missing SoB and fixed whitespace] Signed-off-by: Wilfried Weissmann Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5e315f31faefefdf3757529642884e3f87294d3d Author: Douglas Gilbert Date: Tue Mar 6 22:19:49 2018 -0500 scsi: core: Make SCSI Status CONDITION MET equivalent to GOOD [ Upstream commit 1875ede02ed5e176a18dccbca84abc28d5b3e141 ] The SCSI PRE-FETCH (10 or 16) command is present both on hard disks and some SSDs. It is useful when the address of the next block(s) to be read is known but it is not following the LBA of the current READ (so read-ahead won't help). It returns two "good" SCSI Status values. If the requested blocks have fitted (or will most likely fit (when the IMMED bit is set)) into the disk's cache, it returns CONDITION MET. If it didn't (or will not) fit then it returns GOOD status. The goal of this patch is to stop the SCSI subsystem treating the CONDITION MET SCSI status as an error. The current state makes the PRE-FETCH command effectively unusable via pass-throughs. Signed-off-by: Douglas Gilbert Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3de235c7753b84b18eb806e3cea76560681eda03 Author: Dave Carroll Date: Tue Apr 3 15:50:42 2018 -0600 scsi: aacraid: Insure command thread is not recursively stopped [ Upstream commit 1c6b41fb92936fa5facea464d5d7cbf855966d04 ] If a recursive IOP_RESET is invoked, usually due to the eh_thread handling errors after the first reset, be sure we flag that the command thread has been stopped to avoid an Oops of the form; [ 336.620256] CPU: 28 PID: 1193 Comm: scsi_eh_0 Kdump: loaded Not tainted 4.14.0-49.el7a.ppc64le #1 [ 336.620297] task: c000003fd630b800 task.stack: c000003fd61a4000 [ 336.620326] NIP: c000000000176794 LR: c00000000013038c CTR: c00000000024bc10 [ 336.620361] REGS: c000003fd61a7720 TRAP: 0300 Not tainted (4.14.0-49.el7a.ppc64le) [ 336.620395] MSR: 9000000000009033 CR: 22084022 XER: 20040000 [ 336.620435] CFAR: c000000000130388 DAR: 0000000000000000 DSISR: 40000000 SOFTE: 1 [ 336.620435] GPR00: c00000000013038c c000003fd61a79a0 c0000000014c7e00 0000000000000000 [ 336.620435] GPR04: 000000000000000c 000000000000000c 9000000000009033 0000000000000477 [ 336.620435] GPR08: 0000000000000477 0000000000000000 0000000000000000 c008000010f7d940 [ 336.620435] GPR12: c00000000024bc10 c000000007a33400 c0000000001708a8 c000003fe3b881d8 [ 336.620435] GPR16: c000003fe3b88060 c000003fd61a7d10 fffffffffffff000 000000000000001e [ 336.620435] GPR20: 0000000000000001 c000000000ebf1a0 0000000000000001 c000003fe3b88000 [ 336.620435] GPR24: 0000000000000003 0000000000000002 c000003fe3b88840 c000003fe3b887e8 [ 336.620435] GPR28: c000003fe3b88000 c000003fc8181788 0000000000000000 c000003fc8181700 [ 336.620750] NIP [c000000000176794] exit_creds+0x34/0x160 [ 336.620775] LR [c00000000013038c] __put_task_struct+0x8c/0x1f0 [ 336.620804] Call Trace: [ 336.620817] [c000003fd61a79a0] [c000003fe3b88000] 0xc000003fe3b88000 (unreliable) [ 336.620853] [c000003fd61a79d0] [c00000000013038c] __put_task_struct+0x8c/0x1f0 [ 336.620889] [c000003fd61a7a00] [c000000000171418] kthread_stop+0x1e8/0x1f0 [ 336.620922] [c000003fd61a7a40] [c008000010f7448c] aac_reset_adapter+0x14c/0x8d0 [aacraid] [ 336.620959] [c000003fd61a7b00] [c008000010f60174] aac_eh_host_reset+0x84/0x100 [aacraid] [ 336.621010] [c000003fd61a7b30] [c000000000864f24] scsi_try_host_reset+0x74/0x180 [ 336.621046] [c000003fd61a7bb0] [c000000000867ac0] scsi_eh_ready_devs+0xc00/0x14d0 [ 336.625165] [c000003fd61a7ca0] [c0000000008699e0] scsi_error_handler+0x550/0x730 [ 336.632101] [c000003fd61a7dc0] [c000000000170a08] kthread+0x168/0x1b0 [ 336.639031] [c000003fd61a7e30] [c00000000000b528] ret_from_kernel_thread+0x5c/0xb4 [ 336.645971] Instruction dump: [ 336.648743] 384216a0 7c0802a6 fbe1fff8 f8010010 f821ffd1 7c7f1b78 60000000 60000000 [ 336.657056] 39400000 e87f0838 f95f0838 7c0004ac <7d401828> 314affff 7d40192d 40c2fff4 [ 336.663997] -[ end trace 4640cf8d4945ad95 ]- So flag when the thread is stopped by setting the thread pointer to NULL. Signed-off-by: Dave Carroll Reviewed-by: Raghava Aditya Renukunta Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 10859964e0e1591860171b49eed5189f5cd465ee Author: Jianchao Wang Date: Wed Mar 7 20:29:03 2018 +0800 scsi: iscsi_tcp: set BDI_CAP_STABLE_WRITES when data digest enabled [ Upstream commit 89d0c804392bb962553f23dc4c119d11b6bd1675 ] iscsi tcp will first send out data, then calculate and send data digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will be written in spite of the on going writeback. Consequently, wrong digest will be got and sent to target. To fix this, set BDI_CAP_STABLE_WRITES when data digest is enabled in iscsi_tcp .slave_configure callback. Signed-off-by: Jianchao Wang Acked-by: Chris Leech Acked-by: Lee Duncan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b1a706fdb5a89e1e432f2fc2e3e48a8eb9a9fbb6 Author: Jeremy Cline Date: Tue Mar 6 21:47:32 2018 +0000 scsi: sd: Keep disk read-only when re-reading partition [ Upstream commit 20bd1d026aacc5399464f8328f305985c493cde3 ] If the read-only flag is true on a SCSI disk, re-reading the partition table sets the flag back to false. To observe this bug, you can run: 1. blockdev --setro /dev/sda 2. blockdev --rereadpt /dev/sda 3. blockdev --getro /dev/sda This commit reads the disk's old state and combines it with the device disk-reported state rather than unconditionally marking it as RW. Reported-by: Li Ning Signed-off-by: Jeremy Cline Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2bb6b7decff05262b04c7ef62b6d3b311420bc37 Author: Hannes Reinecke Date: Mon Feb 26 15:26:01 2018 +0100 scsi: mpt3sas: Do not mark fw_event workqueue as WQ_MEM_RECLAIM [ Upstream commit 864449eea7c600596e305ffdc4a6a846414b222c ] The firmware event workqueue should not be marked as WQ_MEM_RECLAIM as it's doesn't need to make forward progress under memory pressure. In the current state it will result in a deadlock if the device had been forcefully removed. Cc: Sreekanth Reddy Cc: Suganath Prabu Subramani Acked-by: Sreekanth Reddy Signed-off-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fbc80171609276ae68c8d7f271355d0fa84bb44c Author: Manish Rangankar Date: Mon Feb 26 01:01:17 2018 -0800 scsi: qedi: Fix kernel crash during port toggle [ Upstream commit 967823d6c3980a30e214b92bfe6a101e7b46d025 ] BUG: unable to handle kernel NULL pointer dereference at 0000000000000100 [ 985.596918] IP: _raw_spin_lock_bh+0x17/0x30 [ 985.601581] PGD 0 P4D 0 [ 985.604405] Oops: 0002 [#1] SMP : [ 985.704533] CPU: 16 PID: 1156 Comm: qedi_thread/16 Not tainted 4.16.0-rc2 #1 [ 985.712397] Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 2.4.3 01/17/2017 [ 985.720747] RIP: 0010:_raw_spin_lock_bh+0x17/0x30 [ 985.725996] RSP: 0018:ffffa4b1c43d3e10 EFLAGS: 00010246 [ 985.731823] RAX: 0000000000000000 RBX: ffff94a31bd03000 RCX: 0000000000000000 [ 985.739783] RDX: 0000000000000001 RSI: ffff94a32fa16938 RDI: 0000000000000100 [ 985.747744] RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000a33 [ 985.755703] R10: 0000000000000000 R11: ffffa4b1c43d3af0 R12: 0000000000000000 [ 985.763662] R13: ffff94a301f40818 R14: 0000000000000000 R15: 000000000000000c [ 985.771622] FS: 0000000000000000(0000) GS:ffff94a32fa00000(0000) knlGS:0000000000000000 [ 985.780649] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 985.787057] CR2: 0000000000000100 CR3: 000000067a009006 CR4: 00000000001606e0 [ 985.795017] Call Trace: [ 985.797747] qedi_fp_process_cqes+0x258/0x980 [qedi] [ 985.803294] qedi_percpu_io_thread+0x10f/0x1b0 [qedi] [ 985.808931] kthread+0xf5/0x130 [ 985.812434] ? qedi_free_uio+0xd0/0xd0 [qedi] [ 985.817298] ? kthread_bind+0x10/0x10 [ 985.821372] ? do_syscall_64+0x6e/0x1a0 Signed-off-by: Manish Rangankar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dc6cb0cb91d51dcc501bf8e62029b86c24d8e7e0 Author: Manish Rangankar Date: Sun Feb 11 22:48:41 2018 -0800 scsi: qla4xxx: skip error recovery in case of register disconnect. [ Upstream commit 1bc5ad3a6acdcf56f83272f2de1cd2389ea9e9e2 ] A system crashes when continuously removing/re-adding the storage controller. Signed-off-by: Manish Rangankar Reviewed-by: Ewan D. Milne Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b24fd4cd949106826bfe54c79df20d514c5a975c Author: Meelis Roos Date: Fri Feb 9 08:57:44 2018 +0200 scsi: aacraid: fix shutdown crash when init fails [ Upstream commit 00c20cdc79259c6c5bf978b21af96c2d3edb646d ] When aacraid init fails with "AAC0: adapter self-test failed.", shutdown leads to UBSAN warning and then oops: [154316.118423] ================================================================================ [154316.118508] UBSAN: Undefined behaviour in drivers/scsi/scsi_lib.c:2328:27 [154316.118566] member access within null pointer of type 'struct Scsi_Host' [154316.118631] CPU: 2 PID: 14530 Comm: reboot Tainted: G W 4.15.0-dirty #89 [154316.118701] Hardware name: Hewlett Packard HP NetServer/HP System Board, BIOS 4.06.46 PW 06/25/2003 [154316.118774] Call Trace: [154316.118848] dump_stack+0x48/0x65 [154316.118916] ubsan_epilogue+0xe/0x40 [154316.118976] __ubsan_handle_type_mismatch+0xfb/0x180 [154316.119043] scsi_block_requests+0x20/0x30 [154316.119135] aac_shutdown+0x18/0x40 [aacraid] [154316.119196] pci_device_shutdown+0x33/0x50 [154316.119269] device_shutdown+0x18a/0x390 [...] [154316.123435] BUG: unable to handle kernel NULL pointer dereference at 000000f4 [154316.123515] IP: scsi_block_requests+0xa/0x30 This is because aac_shutdown() does struct Scsi_Host *shost = pci_get_drvdata(dev); scsi_block_requests(shost); and that assumes shost has been assigned with pci_set_drvdata(). However, pci_set_drvdata(pdev, shost) is done in aac_probe_one() far after bailing out with error from calling the init function ((*aac_drivers[index].init)(aac)), and when the init function fails, no error is returned from aac_probe_one() so PCI layer assumes there is driver attached, and tries to shut it down later. Fix it by returning error from aac_probe_one() when card-specific init function fails. This fixes reboot on my HP NetRAID-4M with dead battery. Signed-off-by: Meelis Roos Reviewed-by: Dave Carroll Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 942cb7bd774ae1c66e79d2ae720c1e1eee5ba0be Author: Andrew Vasquez Date: Wed Feb 7 08:12:35 2018 -0800 scsi: qedi: Fix truncation of CHAP name and secret [ Upstream commit 1683ce57f568c7c92d53e9234624a53554a29cd5 ] The data in NVRAM is not guaranteed to be NUL terminated. Since snprintf expects byte-stream to accommodate null byte, the CHAP secret is truncated. Use sprintf instead of snprintf to fix the truncation of CHAP name and secret. Signed-off-by: Andrew Vasquez Signed-off-by: Nilesh Javali Reviewed-by: Bart Van Assche Acked-by: Chris Leech Acked-by: Lee Duncan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a9eb1e1031a075570468bc03c1b72fa0c2e22a69 Author: Michael Kelley (EOSG) Date: Wed Jan 24 22:49:57 2018 +0000 scsi: storvsc: Increase cmd_per_lun for higher speed devices [ Upstream commit cabe92a55e3a12005a4ac4d3954c9a174b0efe2a ] Increase cmd_per_lun to allow more I/Os in progress per device, particularly for NVMe's. The Hyper-V host side can handle the higher count with no issues. Signed-off-by: Michael Kelley Reviewed-by: K. Y. Srinivasan Acked-by: K. Y. Srinivasan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1ad71103e12e2b8da7f0fbcc8d69f0aa3409b523 Author: Bart Van Assche Date: Thu Jan 25 08:24:29 2018 -0800 scsi: qla2xxx: Avoid triggering undefined behavior in qla2x00_mbx_completion() [ Upstream commit c02189e12ce3bf3808cb880569d3b10249f50bd9 ] A left shift must shift less than the bit width of the left argument. Avoid triggering undefined behavior if ha->mbx_count == 32. This patch avoids that UBSAN reports the following complaint: UBSAN: Undefined behaviour in drivers/scsi/qla2xxx/qla_isr.c:275:14 shift exponent 32 is too large for 32-bit type 'int' Call Trace: dump_stack+0x4e/0x6c ubsan_epilogue+0xd/0x3b __ubsan_handle_shift_out_of_bounds+0x112/0x14c qla2x00_mbx_completion+0x1c5/0x25d [qla2xxx] qla2300_intr_handler+0x1ea/0x3bb [qla2xxx] qla2x00_mailbox_command+0x77b/0x139a [qla2xxx] qla2x00_mbx_reg_test+0x83/0x114 [qla2xxx] qla2x00_chip_diag+0x354/0x45f [qla2xxx] qla2x00_initialize_adapter+0x2c2/0xa4e [qla2xxx] qla2x00_probe_one+0x1681/0x392e [qla2xxx] pci_device_probe+0x10b/0x1f1 driver_probe_device+0x21f/0x3a4 __driver_attach+0xa9/0xe1 bus_for_each_dev+0x6e/0xb5 driver_attach+0x22/0x3c bus_add_driver+0x1d1/0x2ae driver_register+0x78/0x130 __pci_register_driver+0x75/0xa8 qla2x00_module_init+0x21b/0x267 [qla2xxx] do_one_initcall+0x5a/0x1e2 do_init_module+0x9d/0x285 load_module+0x20db/0x38e3 SYSC_finit_module+0xa8/0xbc SyS_finit_module+0x9/0xb do_syscall_64+0x77/0x271 entry_SYSCALL64_slow_path+0x25/0x25 Reported-by: Meelis Roos Signed-off-by: Bart Van Assche Cc: Himanshu Madhani Reviewed-by: Laurence Oberman Acked-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 62d16de3109f8dff76f97b58d66ce502970b2f3f Author: Dan Carpenter Date: Thu Jan 25 17:27:27 2018 +0300 scsi: mptfusion: Add bounds check in mptctl_hp_targetinfo() [ Upstream commit a7043e9529f3c367cc4d82997e00be034cbe57ca ] My static checker complains about an out of bounds read: drivers/message/fusion/mptctl.c:2786 mptctl_hp_targetinfo() error: buffer overflow 'hd->sel_timeout' 255 <= u32max. It's true that we probably should have a bounds check here. Signed-off-by: Dan Carpenter Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0bf213d90bb2c25d1f36811d14f239126764b130 Author: Dan Carpenter Date: Thu Jan 25 17:13:40 2018 +0300 scsi: sym53c8xx_2: iterator underflow in sym_getsync() [ Upstream commit e6f791d95313c85f3dd4a26141e28e50ae9aa0ae ] We wanted to exit the loop with "div" set to zero, but instead, if we don't hit the break then "div" is -1 when we finish the loop. It leads to an array underflow a few lines later. Signed-off-by: Dan Carpenter Reviewed-by: Johannes Thumshirn Acked-by: Matthew Wilcox Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a1ac3da8431afd57a3d08e24b8eb460e6255bf99 Author: Chad Dupuis Date: Wed Jan 24 08:07:06 2018 -0800 scsi: bnx2fc: Fix check in SCSI completion handler for timed out request [ Upstream commit ecf7ff49945f5741fa1da112f994939f942031d3 ] When a request times out we set the io_req flag BNX2FC_FLAG_IO_COMPL so that if a subsequent completion comes in on that task ID we will ignore it. The issue is that in the check for this flag there is a missing return so we will continue to process a request which may have already been returned to the ownership of the SCSI layer. This can cause unpredictable results. Solution is to add in the missing return. [mkp: typo plus title shortening] Signed-off-by: Chad Dupuis Reviewed-by: Laurence Oberman Tested-by: Laurence Oberman Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit af9930622461584c82aeec6843de97b3495ff40a Author: Sujit Reddy Thumma Date: Wed Jan 24 09:52:35 2018 +0530 scsi: ufs: Enable quirk to ignore sending WRITE_SAME command [ Upstream commit 84af7e8b895088d89f246d6b0f82717fafdebf61 ] WRITE_SAME command is not supported by UFS. Enable a quirk for the upper level drivers to not send WRITE SAME command. [mkp: botched patch, applied by hand] Signed-off-by: Sujit Reddy Thumma Signed-off-by: Subhash Jadavani Signed-off-by: Asutosh Das Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b0ef004e86cf7ddc9498a4db4d9624d3fd5b3c07 Author: Quinn Tran Date: Tue Jan 23 11:05:21 2018 -0800 scsi: qla2xxx: Fix memory corruption during hba reset test [ Upstream commit 2ce87cc5b269510de9ca1185ca8a6e10ec78c069 ] This patch fixes memory corrpution while performing HBA Reset test. Following stack trace is seen: [ 466.397219] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 466.433669] IP: [] qlt_free_session_done+0x260/0x5f0 [qla2xxx] [ 466.467731] PGD 0 [ 466.476718] Oops: 0000 [#1] SMP Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 59ad4bb717141ee814db7843835c13e11032ed41 Author: Tomas Henzl Date: Fri Jan 19 16:22:05 2018 +0100 scsi: mpt3sas: fix an out of bound write [ Upstream commit 4a8842de8db4953fdda7866626b78b12fb8adb97 ] cpu_msix_table is allocated to store online cpus, but pci_irq_get_affinity may return cpu_possible_mask which is then used to access cpu_msix_table. That causes bad user experience. Fix limits access to only online cpus, I've also added an additional test to protect from an unlikely change in cpu_online_mask. [mkp: checkpatch] Fixes: 1d55abc0e98a ("scsi: mpt3sas: switch to pci_alloc_irq_vectors") Signed-off-by: Tomas Henzl Acked-by: Suganath Prabu Subramani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2b2a92910c1968d2922f07b2a44a6a51d63ef6d7 Author: Antoine Tenart Date: Tue Feb 13 09:26:55 2018 +0100 crypto: inside-secure - fix the invalidation step during cra_exit [ Upstream commit b7007dbccd92f7b8c00e590020bee542a48c6a2c ] When exiting a transformation, the cra_exit() helper is called in each driver providing one. The Inside Secure SafeXcel driver has one, which is responsible of freeing some areas and of sending one invalidation request to the crypto engine, to invalidate the context that was used during the transformation. We could see in some setups (when lots of transformations were being used with a short lifetime, and hence lots of cra_exit() calls) NULL pointer dereferences and other weird issues. All these issues were coming from accessing the tfm context. The issue is the invalidation request completion is checked using a wait_for_completion_interruptible() call in both the cipher and hash cra_exit() helpers. In some cases this was interrupted while the invalidation request wasn't processed yet. And then cra_exit() returned, and its caller was freeing the tfm instance. Only then the request was being handled by the SafeXcel driver, which lead to the said issues. This patch fixes this by using wait_for_completion() calls in these specific cases. Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Signed-off-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c787fb6bdac2045494fa240ab6687f72b7fa0d4a Author: Peter Robinson Date: Sun Feb 11 23:15:37 2018 +0000 crypto: sunxi-ss - Add MODULE_ALIAS to sun4i-ss [ Upstream commit 7c73cf4cc2ac16465f5102437dc0a12d66671bd6 ] The MODULE_ALIAS is required to enable the sun4i-ss driver to load automatically when built at a module. Tested on a Cubietruck. Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Signed-off-by: Peter Robinson Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d03a0a61dc82f27fcb56561992f564f2ebc1e4b3 Author: Antoine Tenart Date: Tue Feb 13 09:26:52 2018 +0100 crypto: inside-secure - fix the extra cache computation [ Upstream commit c1a8fa6e240ed4b99778d48ab790743565cb61c8 ] This patch fixes the extra cache computation when the queued data is a multiple of a block size. This fixes the hash support in some cases. Fixes: 809778e02cd4 ("crypto: inside-secure - fix hash when length is a multiple of a block") Signed-off-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6df26587d22d69b3f8310303f11f57199a738872 Author: Antoine Tenart Date: Tue Feb 13 09:26:53 2018 +0100 crypto: inside-secure - fix the cache_len computation [ Upstream commit 666a9c70b04fccabde5cea5e680ae1ae92460a62 ] This patch fixes the cache length computation as cache_len could end up being a negative value. The check between the queued size and the block size is updated to reflect the caching mechanism which can cache up to a full block size (included!). Fixes: 809778e02cd4 ("crypto: inside-secure - fix hash when length is a multiple of a block") Signed-off-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a04b30fd74a1b00f9d8fa010bee5cde37aaa9803 Author: Antoine Tenart Date: Tue Feb 13 09:26:54 2018 +0100 crypto: inside-secure - do not process request if no command was issued [ Upstream commit 95831ceafc0de7d94a5fe86ebb1c2042317cc2cd ] This patch adds a check in the SafeXcel dequeue function, to avoid processing request further if no hardware command was issued. This can happen in certain cases where the ->send() function caches all the data that would have been send. Fixes: 809778e02cd4 ("crypto: inside-secure - fix hash when length is a multiple of a block") Signed-off-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 41b6f0ffb3ac1d486bcd2545f0b1d25189d78695 Author: Sebastian Andrzej Siewior Date: Fri Feb 23 23:33:07 2018 +0100 crypto: ccp - don't disable interrupts while setting up debugfs [ Upstream commit 79eb382b5e06a6dca5806465d7195d686a463ab0 ] I don't why we need take a single write lock and disable interrupts while setting up debugfs. This is what what happens when we try anyway: |ccp 0000:03:00.2: enabling device (0000 -> 0002) |BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:69 |in_atomic(): 1, irqs_disabled(): 1, pid: 3, name: kworker/0:0 |irq event stamp: 17150 |hardirqs last enabled at (17149): [<0000000097a18c49>] restore_regs_and_return_to_kernel+0x0/0x23 |hardirqs last disabled at (17150): [<000000000773b3a9>] _raw_write_lock_irqsave+0x1b/0x50 |softirqs last enabled at (17148): [<0000000064d56155>] __do_softirq+0x3b8/0x4c1 |softirqs last disabled at (17125): [<0000000092633c18>] irq_exit+0xb1/0xc0 |CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.16.0-rc2+ #30 |Workqueue: events work_for_cpu_fn |Call Trace: | dump_stack+0x7d/0xb6 | ___might_sleep+0x1eb/0x250 | down_write+0x17/0x60 | start_creating+0x4c/0xe0 | debugfs_create_dir+0x9/0x100 | ccp5_debugfs_setup+0x191/0x1b0 | ccp5_init+0x8a7/0x8c0 | ccp_dev_init+0xb8/0xe0 | sp_init+0x6c/0x90 | sp_pci_probe+0x26e/0x590 | local_pci_probe+0x3f/0x90 | work_for_cpu_fn+0x11/0x20 | process_one_work+0x1ff/0x650 | worker_thread+0x1d4/0x3a0 | kthread+0xfe/0x130 | ret_from_fork+0x27/0x50 If any locking is required, a simple mutex will do it. Cc: Gary R Hook Signed-off-by: Sebastian Andrzej Siewior Acked-by: Gary R Hook Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 223ba92a80594ed6c071b39402660ee07937ac8a Author: Antoine Tenart Date: Fri Feb 23 10:01:40 2018 +0100 crypto: atmel-aes - fix the keys zeroing on errors [ Upstream commit 5d804a5157dbaa64872a675923ae87161165c66b ] The Atmel AES driver uses memzero_explicit on the keys on error, but the variable zeroed isn't the right one because of a typo. Fix this by using the right variable. Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes") Signed-off-by: Antoine Tenart Reviewed-by: Tudor Ambarus Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 173c55493b8184623f415799aac8c62d0c5574b6 Author: Antoine Tenart Date: Mon Feb 26 14:45:12 2018 +0100 crypto: inside-secure - wait for the request to complete if in the backlog [ Upstream commit 4dc5475ae0375ea4f9283dfd9b2ddc91b20d4c4b ] This patch updates the safexcel_hmac_init_pad() function to also wait for completion when the digest return code is -EBUSY, as it would mean the request is in the backlog to be processed later. Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Suggested-by: Ofer Heifetz Signed-off-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 43624647a97c113e71ab23775b295ba0cccf0319 Author: NeilBrown Date: Fri Feb 23 09:09:33 2018 +1100 staging: lustre: lmv: correctly iput lmo_root [ Upstream commit 17556cdbe6ed70a6a20e597b228628f7f34387f8 ] Commit 8f18c8a48b73 ("staging: lustre: lmv: separate master object with master stripe") changed how lmo_root inodes were managed, particularly when LMV_HASH_FLAG_MIGRATION is not set. Previously lsm_md_oinfo[0].lmo_root was always a borrowed inode reference and didn't need to by iput(). Since the change, that special case only applies when LMV_HASH_FLAG_MIGRATION is set In the upstream (lustre-release) version of this patch [Commit 60e07b972114 ("LU-4690 lod: separate master object with master stripe")] the for loop in the lmv_unpack_md() was changed to count from 0 and to ignore entry 0 if LMV_HASH_FLAG_MIGRATION is set. In the patch that got applied to Linux, that change was missing, so lsm_md_oinfo[0].lmo_root is never iput(). This results in a "VFS: Busy inodes" warning at unmount. Fixes: 8f18c8a48b73 ("staging: lustre: lmv: separate master object with master stripe") Signed-off-by: NeilBrown Reviewed-by: James Simmons Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 281bb7920cc0cd3e3bbe06b48a3d42b2dbeaa3cc Author: Quytelda Kahja Date: Wed Feb 28 21:19:07 2018 -0800 staging: ks7010: Use constants from ieee80211_eid instead of literal ints. [ Upstream commit dc13498ab47fdfae3cda4df712beb2e4244b3fe0 ] The case statement in get_ap_information() should not use literal integers to parse information element IDs when these values are provided by name in 'enum ieee80211_eid' in the header 'linux/ieee80211.h'. Signed-off-by: Quytelda Kahja Reviewed-by: Tobin C. Harding Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d5ae597ed13da51d203adea4deb524728c45da71 Author: Colin Ian King Date: Wed Feb 28 11:28:49 2018 +0000 staging: rtl8192u: return -ENOMEM on failed allocation of priv->oldaddr [ Upstream commit e1a7418529e33bc4efc346324557251a16a3e79b ] Currently the allocation of priv->oldaddr is not null checked which will lead to subsequent errors when accessing priv->oldaddr. Fix this with a null pointer check and a return of -ENOMEM on allocation failure. Detected with Coccinelle: drivers/staging/rtl8192u/r8192U_core.c:1708:2-15: alloc with no test, possible model on line 1723 Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging") Signed-off-by: Colin Ian King Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 20b9506df1b40367c782bd98a77497e3021baaa1 Author: Ioana Radulescu Date: Mon Feb 26 10:28:06 2018 -0600 staging: fsl-dpaa2/eth: Fix incorrect casts [ Upstream commit 75c583ab9709692a60871d4719006391cde8dc1d ] The DPAA2 Ethernet driver incorrectly assumes virtual addresses are always 64b long, which causes compiler errors when building for a 32b platform. Fix this by using explicit casts to uintptr_t where necessary. Signed-off-by: Ioana Radulescu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ff8eb22e5bb83ffc8fb3e633711cf3fc785dd60f Author: NeilBrown Date: Fri Mar 2 10:31:25 2018 +1100 staging: lustre: fix bug in osc_enter_cache_try [ Upstream commit 2fab9faf9b27298c4536c1c1b14072ab18b8f80b ] The lustre-release patch commit bdc5bb52c554 ("LU-4933 osc: Automatically increase the max_dirty_mb") changed - if (cli->cl_dirty + PAGE_CACHE_SIZE <= cli->cl_dirty_max && + if (cli->cl_dirty_pages < cli->cl_dirty_max_pages && When this patch landed in Linux a couple of years later, it landed as - if (cli->cl_dirty + PAGE_SIZE <= cli->cl_dirty_max && + if (cli->cl_dirty_pages <= cli->cl_dirty_max_pages && which is clearly different ('<=' vs '<'), and allows cl_dirty_pages to increase beyond cl_dirty_max_pages - which causes a latter assertion to fails. Fixes: 3147b268400a ("staging: lustre: osc: Automatically increase the max_dirty_mb") Signed-off-by: NeilBrown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bf30d26981a857454bf9c71edc61fccc42dd6b83 Author: Kirill Marinushkin Date: Fri Mar 23 20:32:54 2018 +0100 staging: bcm2835-audio: Release resources on module_exit() [ Upstream commit 626118b472d2eb45f83a0276a18d3e6a01c69f6a ] In the current implementation, `rmmod snd_bcm2835` does not release resources properly. It causes an oops when trying to list sound devices. This commit fixes it. The details WRT allocation / free are described below. Device structure WRT allocation: pdev \childdev[] \card \chip \pcm \ctl Allocation / register sequence: * childdev: devm_kzalloc - freed during driver detach * childdev: device_initialize - freed during device_unregister * pdev: devres_alloc - freed during driver detach * childdev: device_add - removed during device_unregister * pdev, childdev: devres_add - freed during driver detach * card: snd_card_new - freed during snd_card_free * chip: kzalloc - freed during kfree * card, chip: snd_device_new - freed during snd_device_free * chip: new_pcm - TODO: free pcm * chip: new_ctl - TODO: free ctl * card: snd_card_register - unregistered during snd_card_free Free / unregister sequence: * card: snd_card_free * card, chip: snd_device_free * childdev: device_unregister * chip: kfree Steps to reproduce the issue before this commit: ~~~~ $ rmmod snd_bcm2835 $ aplay -L [ 138.648130] Unable to handle kernel paging request at virtual address 7f1343c0 [ 138.660415] pgd = ad8f0000 [ 138.665567] [7f1343c0] *pgd=3864c811, *pte=00000000, *ppte=00000000 [ 138.674887] Internal error: Oops: 7 [#1] SMP ARM [ 138.683571] Modules linked in: sha256_generic cfg80211 rfkill snd_pcm snd_timer snd fixed uio_pdrv_genirq uio ip_tables x_tables ipv6 [last unloaded: snd_bcm2835 ] [ 138.706594] CPU: 3 PID: 463 Comm: aplay Tainted: G WC 4.15.0-rc1-v 7+ #6 [ 138.719833] Hardware name: BCM2835 [ 138.726016] task: b877ac00 task.stack: aebec000 [ 138.733408] PC is at try_module_get+0x38/0x24c [ 138.740813] LR is at snd_ctl_open+0x58/0x194 [snd] [ 138.748485] pc : [<801c4d5c>] lr : [<7f0e6b2c>] psr: 20000013 [ 138.757709] sp : aebedd60 ip : aebedd88 fp : aebedd84 [ 138.765884] r10: 00000000 r9 : 00000004 r8 : 7f0ed440 [ 138.774040] r7 : b7e469b0 r6 : 7f0e6b2c r5 : afd91900 r4 : 7f1343c0 [ 138.783571] r3 : aebec000 r2 : 00000001 r1 : b877ac00 r0 : 7f1343c0 [ 138.793084] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 138.803300] Control: 10c5387d Table: 2d8f006a DAC: 00000055 [ 138.812064] Process aplay (pid: 463, stack limit = 0xaebec210) [ 138.820868] Stack: (0xaebedd60 to 0xaebee000) [ 138.828207] dd60: 00000000 b848d000 afd91900 00000000 b7e469b0 7f0ed440 aebedda4 aebedd88 [ 138.842371] dd80: 7f0e6b2c 801c4d30 afd91900 7f0ea4dc 00000000 b7e469b0 aebeddcc aebedda8 [ 138.856611] dda0: 7f0e250c 7f0e6ae0 7f0e2464 b8478ec0 b7e469b0 afd91900 7f0ea388 00000000 [ 138.870864] ddc0: aebeddf4 aebeddd0 802ce590 7f0e2470 8090ab64 afd91900 afd91900 b7e469b0 [ 138.885301] dde0: afd91908 802ce4e4 aebede1c aebeddf8 802c57b4 802ce4f0 afd91900 aebedea8 [ 138.900110] de00: b7fa4c00 00000000 00000000 00000004 aebede3c aebede20 802c6ba8 802c56b4 [ 138.915260] de20: aebedea8 00000000 aebedf5c 00000000 aebedea4 aebede40 802d9a68 802c6b58 [ 138.930661] de40: b874ddd0 00000000 00000000 00000001 00000041 00000000 afd91900 aebede70 [ 138.946402] de60: 00000000 00000000 00000002 b7e469b0 b8a87610 b8d6ab80 801852f8 00080000 [ 138.962314] de80: aebedf5c aebedea8 00000001 80108464 aebec000 00000000 aebedf4c aebedea8 [ 138.978414] dea0: 802dacd4 802d970c b8a87610 b8d6ab80 a7982bc6 00000009 af363019 b9231480 [ 138.994617] dec0: 00000000 b8c038a0 b7e469b0 00000101 00000002 00000238 00000000 00000000 [ 139.010823] dee0: 00000000 aebedee8 00080000 0000000f aebedf3c aebedf00 802ed7e4 80843f94 [ 139.027025] df00: 00000003 00080000 b9231490 b9231480 00000000 00080000 af363000 00000000 [ 139.043229] df20: 00000005 00000002 ffffff9c 00000000 00080000 ffffff9c af363000 00000003 [ 139.059430] df40: aebedf94 aebedf50 802c6f70 802dac70 aebec000 00000000 00000001 00000000 [ 139.075629] df60: 00020000 00000004 00000100 00000001 7ebe577c 0002e038 00000000 00000005 [ 139.091828] df80: 80108464 aebec000 aebedfa4 aebedf98 802c7060 802c6e6c 00000000 aebedfa8 [ 139.108025] dfa0: 801082c0 802c7040 7ebe577c 0002e038 7ebe577c 00080000 00000b98 e81c8400 [ 139.124222] dfc0: 7ebe577c 0002e038 00000000 00000005 7ebe57e4 00a20af8 7ebe57f0 76f87394 [ 139.140419] dfe0: 00000000 7ebe55c4 76ec88e8 76df1d9c 60000010 7ebe577c 00000000 00000000 [ 139.156715] [<801c4d5c>] (try_module_get) from [<7f0e6b2c>] (snd_ctl_open+0x58/0x194 [snd]) [ 139.173222] [<7f0e6b2c>] (snd_ctl_open [snd]) from [<7f0e250c>] (snd_open+0xa8/0x14c [snd]) [ 139.189683] [<7f0e250c>] (snd_open [snd]) from [<802ce590>] (chrdev_open+0xac/0x188) [ 139.205465] [<802ce590>] (chrdev_open) from [<802c57b4>] (do_dentry_open+0x10c/0x314) [ 139.221347] [<802c57b4>] (do_dentry_open) from [<802c6ba8>] (vfs_open+0x5c/0x88) [ 139.236788] [<802c6ba8>] (vfs_open) from [<802d9a68>] (path_openat+0x368/0x944) [ 139.248270] [<802d9a68>] (path_openat) from [<802dacd4>] (do_filp_open+0x70/0xc4) [ 139.263731] [<802dacd4>] (do_filp_open) from [<802c6f70>] (do_sys_open+0x110/0x1d4) [ 139.279378] [<802c6f70>] (do_sys_open) from [<802c7060>] (SyS_open+0x2c/0x30) [ 139.290647] [<802c7060>] (SyS_open) from [<801082c0>] (ret_fast_syscall+0x0/0x28) [ 139.306021] Code: e3c3303f e5932004 e2822001 e5832004 (e5943000) [ 139.316265] ---[ end trace 7f3f7f6193b663ed ]--- [ 139.324956] note: aplay[463] exited with preempt_count 1 ~~~~ Signed-off-by: Kirill Marinushkin Cc: Eric Anholt Cc: Stefan Wahren Cc: Greg Kroah-Hartman Cc: Florian Fainelli Cc: Ray Jui Cc: Scott Branden Cc: bcm-kernel-feedback-list@broadcom.com Cc: Michael Zoran Cc: Andy Shevchenko Cc: linux-rpi-kernel@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: devel@driverdev.osuosl.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0fe68f20e09f7b1ce276db20ef580fb8d9f69e0b Author: Mathias Nyman Date: Fri Mar 16 16:33:06 2018 +0200 xhci: Show what USB release number the xHC supports from protocol capablity [ Upstream commit 0ee78c101425aae681c631ba59c6ac7f44b1d83a ] xhci driver displays the supported xHC USB revision in a message during driver load: "Host supports USB 3.1 Enhanced SuperSpeed" Get the USB minor revision number from the xhci protocol capability. This will show the correct supported revisions for new USB 3.2 and later hosts Don't rely on the SBRN (serial bus revision number) register, it's often showing 0x30 (USB3.0) for hosts that support USB 3.1 Signed-off-by: Mathias Nyman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0249054e4bfd3237d042c9f0bc651e2db50fc9a8 Author: Larry Finger Date: Sun Feb 11 12:24:32 2018 -0600 Bluetooth: btusb: Add device ID for RTL8822BE [ Upstream commit fed03fe7e55b7dc16077f672bd9d7bbe92b3a691 ] The Asus Z370-I contains a Realtek RTL8822BE device with an associated BT chip using a USB ID of 0b05:185c. This device is added to the driver. Signed-off-by: Hon Weng Chong Signed-off-by: Larry Finger Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e4504b80e012f6ca569a738b2dc3b70ae4f4ceb3 Author: Brad Love Date: Thu Jan 4 19:04:13 2018 -0500 media: em28xx: USB bulk packet size fix [ Upstream commit c7c7e8d7803406daa21e96d00c357de8b77b6764 ] Hauppauge em28xx bulk devices exhibit continuity errors and corrupted packets, when run in VMWare virtual machines. Unknown if other manufacturers bulk models exhibit the same issue. KVM/Qemu is unaffected. According to documentation the maximum packet multiplier for em28xx in bulk transfer mode is 256 * 188 bytes. This changes the size of bulk transfers to maximum supported value and have a bonus beneficial alignment. Before: After: This sets up USB to expect just as many bytes as the em28xx is set to emit. Successful usage under load afterwards natively and in both VMWare and KVM/Qemu virtual machines. Signed-off-by: Brad Love Reviewed-by: Michael Ira Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f5f6bff50f36edf9cf503d8ea56a2b2e649236f4 Author: Brad Love Date: Fri Jan 5 09:57:12 2018 -0500 media: lgdt3306a: Fix module count mismatch on usb unplug [ Upstream commit 835d66173a38538c072a7c393d02360dcfac8582 ] When used as an i2c device there is a module usage count mismatch on removal, preventing the driver from being used thereafter. dvb_attach increments the usage count so it is properly balanced on removal. On disconnect of Hauppauge SoloHD/DualHD before: lsmod | grep lgdt3306a lgdt3306a 28672 -1 i2c_mux 16384 1 lgdt3306a On disconnect of Hauppauge SoloHD/DualHD after: lsmod | grep lgdt3306a lgdt3306a 28672 0 i2c_mux 16384 1 lgdt3306a Signed-off-by: Brad Love Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f3f3442027b5b4f7633fc008ade8b2f5558b16c9 Author: Chris Dickens Date: Sun Dec 31 18:59:42 2017 -0800 usb: gadget: composite: fix incorrect handling of OS desc requests [ Upstream commit 5d6ae4f0da8a64a185074dabb1b2f8c148efa741 ] When handling an OS descriptor request, one of the first operations is to zero out the request buffer using the wLength from the setup packet. There is no bounds checking, so a wLength > 4096 would clobber memory adjacent to the request buffer. Fix this by taking the min of wLength and the request buffer length prior to the memset. While at it, define the buffer length in a header file so that magic numbers don't appear throughout the code. When returning data to the host, the data length should be the min of the wLength and the valid data we have to return. Currently we are returning wLength, thus requests for a wLength greater than the amount of data in the OS descriptor buffer would return invalid (albeit zero'd) data following the valid descriptor data. Fix this by counting the number of bytes when constructing the data and using this when determining the length of the request. Signed-off-by: Chris Dickens Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9170c1411eca5a2409fe4ec03152ce416ab45f97 Author: Wolfram Sang Date: Tue Feb 6 09:50:40 2018 +0100 usb: gadget: udc: change comparison to bitshift when dealing with a mask [ Upstream commit ac87e560f7c0f91b62012e9a159c0681a373b922 ] Due to a typo, the mask was destroyed by a comparison instead of a bit shift. Reported-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b80114337d31e617196b3d10820886038d8128d0 Author: Ben Hutchings Date: Mon Jan 29 00:04:18 2018 +0000 usbip: Correct maximum value of CONFIG_USBIP_VHCI_HC_PORTS [ Upstream commit 351a8d4837ae0d61744e64262c3a80ab92ff3e42 ] Now that usbip supports USB3, the maximum number of ports allowed on a hub is 15 (USB_SS_MAXPORTS), not 31 (USB_MAXCHILDREN). Reported-by: Gianluigi Tiesi Reported-by: Borissh1983 References: https://bugs.debian.org/878866 Fixes: 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed support") Signed-off-by: Ben Hutchings Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dd5541c7a60d9fe8715a0b7f90dbdac6c2457636 Author: Lars-Peter Clausen Date: Fri Jan 12 11:05:02 2018 +0100 usb: gadget: ffs: Execute copy_to_user() with USER_DS set [ Upstream commit 4058ebf33cb0be88ca516f968eda24ab7b6b93e4 ] When using a AIO read() operation on the function FS gadget driver a URB is submitted asynchronously and on URB completion the received data is copied to the userspace buffer associated with the read operation. This is done from a kernel worker thread invoking copy_to_user() (through copy_to_iter()). And while the user space process memory is made available to the kernel thread using use_mm(), some architecture require in addition to this that the operation runs with USER_DS set. Otherwise the userspace memory access will fail. For example on ARM64 with Privileged Access Never (PAN) and User Access Override (UAO) enabled the following crash occurs. Internal error: Accessing user space memory with fs=KERNEL_DS: 9600004f [#1] SMP Modules linked in: CPU: 2 PID: 1636 Comm: kworker/2:1 Not tainted 4.9.0-04081-g8ab2dfb-dirty #487 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) Workqueue: events ffs_user_copy_worker task: ffffffc87afc8080 task.stack: ffffffc87a00c000 PC is at __arch_copy_to_user+0x190/0x220 LR is at copy_to_iter+0x78/0x3c8 [...] [] __arch_copy_to_user+0x190/0x220 [] ffs_user_copy_worker+0x70/0x130 [] process_one_work+0x1dc/0x460 [] worker_thread+0x50/0x4b0 [] kthread+0xd8/0xf0 [] ret_from_fork+0x10/0x50 Address this by placing a set_fs(USER_DS) before of the copy operation and revert it again once the copy operation has finished. This patch is analogous to commit d7ffde35e31a ("vhost: use USER_DS in vhost_worker thread") which addresses the same underlying issue. Signed-off-by: Lars-Peter Clausen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7f48c9ddca72a0c488331e775d21fe280c1f71f1 Author: Lars-Peter Clausen Date: Fri Jan 12 11:26:16 2018 +0100 usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS [ Upstream commit 946ef68ad4e45aa048a5fb41ce8823ed29da866a ] Some UDC drivers (like the DWC3) expect that the response to a setup() request is queued from within the setup function itself so that it is available as soon as setup() has completed. Upon receiving a setup request the function fs driver creates an event that is made available to userspace. And only once userspace has acknowledged that event the response to the setup request is queued. So it violates the requirement of those UDC drivers and random failures can be observed. This is basically a race condition and if userspace is able to read the event and queue the response fast enough all is good. But if it is not, for example because other processes are currently scheduled to run, the USB host that sent the setup request will observe an error. To avoid this the gadget framework provides the USB_GADGET_DELAYED_STATUS return code. If a setup() callback returns this value the UDC driver is aware that response is not yet available and can uses the appropriate methods to handle this case. Since in the case of function fs the response will never be available when the setup() function returns make sure that this status code is used. This fixed random occasional failures that were previously observed on a DWC3 based system under high system load. Signed-off-by: Lars-Peter Clausen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 11cb14a196793ce2f9fb3fa9811f2dbaf348141c Author: Minas Harutyunyan Date: Fri Jan 19 14:44:20 2018 +0400 usb: dwc2: host: Fix transaction errors in host mode [ Upstream commit 92a8dd26464e1f21f1d869ec53717bd2c1200d63 ] Added missing GUSBCFG programming in host mode, which fixes transaction errors issue on HiKey and Altera Cyclone V boards. These field even if was programmed in device mode (in function dwc2_hsotg_core_init_disconnected()) will be resetting to POR values after core soft reset applied. So, each time when switching to host mode required to set this field to correct value. Acked-by: John Youn Signed-off-by: Minas Harutyunyan Signed-off-by: Grigor Tovmasyan Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 51250a9357d8b371fe1b8ab052c9b1ffe5f9a670 Author: Minas Harutyunyan Date: Fri Jan 19 14:43:53 2018 +0400 usb: dwc2: hcd: Fix host channel halt flow [ Upstream commit a82c7abdf8fc3b09c4a0ed2eee6d43ecef2ccdb0 ] According databook in Buffer and External DMA mode non-split periodic channels can't be halted. Acked-by: John Youn Signed-off-by: Minas Harutyunyan Signed-off-by: Grigor Tovmasyan Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit db81323e6a5d32a93ad7a1a419f99fe141df952e Author: Grigor Tovmasyan Date: Tue Feb 6 19:07:38 2018 +0400 usb: dwc2: Fix interval type issue [ Upstream commit 12814a3f8f9b247531d7863170cc82b3fe4218fd ] The maximum value that unsigned char can hold is 255, meanwhile the maximum value of interval is 2^(bIntervalMax-1)=2^15. Signed-off-by: Grigor Tovmasyan Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 39280c27031b32639c5757da6e3462ba397df58c Author: Mathias Nyman Date: Fri Mar 16 16:33:01 2018 +0200 xhci: zero usb device slot_id member when disabling and freeing a xhci slot [ Upstream commit a400efe455f7b61ac9a801ac8d0d01f8c8d82dd5 ] set udev->slot_id to zero when disabling and freeing the xhci slot. Prevents usb core from calling xhci with a stale slot id. xHC controller may be reset during resume to recover from some error. All slots are unusable as they are disabled and freed. xhci driver starts slot enumeration again from 1 in the order they are enabled. In the worst case a stale udev->slot_id for one device matches a newly enabled slot_id for a different device, causing us to perform a action on the wrong device. Signed-off-by: Mathias Nyman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 55aaef4bd8a08ec978169a4484c77b1d4cd49695 Author: Felipe Balbi Date: Thu Mar 22 10:45:20 2018 +0200 usb: dwc3: Makefile: fix link error on randconfig [ Upstream commit de948a74ad6f0eefddf36d765b8f2dd6df82caa0 ] If building a kernel without FTRACE but with TRACING, dwc3.ko fails to link due to missing trace events. Fix this by using the correct Kconfig symbol on Makefile. Reported-by: Randy Dunlap Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 834329c4ad4cb59a8cd6c3e5354c8b91540841c3 Author: Thinh Nguyen Date: Fri Mar 16 15:33:54 2018 -0700 usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fields [ Upstream commit 0cab8d26d6e5e053b2bed3356992aaa71dc93628 ] Update two GTXFIFOSIZ bit fields for the DWC_usb31 controller. TXFDEP is a 15-bit value instead of 16-bit value, and bit 15 is TXFRAMNUM. The GTXFIFOSIZ register for DWC_usb31 is as follows: +-------+-----------+----------------------------------+ | BITS | Name | Description | +=======+===========+==================================+ | 31:16 | TXFSTADDR | Transmit FIFOn RAM Start Address | | 15 | TXFRAMNUM | Asynchronous/Periodic TXFIFO | | 14:0 | TXFDEP | TXFIFO Depth | +-------+-----------+----------------------------------+ Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7fb2d2f1b04d983cb8b92ac12c6a15bd905943b2 Author: Thinh Nguyen Date: Fri Mar 16 15:33:48 2018 -0700 usb: dwc3: Add SoftReset PHY synchonization delay [ Upstream commit fab3833338779e1e668bd58d1f76d601657304b8 ] >From DWC_usb31 programming guide section 1.3.2, once DWC3_DCTL_CSFTRST bit is cleared, we must wait at least 50ms before accessing the PHY domain (synchronization delay). Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 81ba08e69fe2af23162c4222ddd67622895f5bac Author: Nobutaka Okabe Date: Fri Mar 23 19:18:22 2018 +0900 ALSA: usb-audio: Add native DSD support for Luxman DA-06 [ Upstream commit 71426535f49fe6034d0e0db77608b91a0c1a022d ] Add native DSD support quirk for Luxman DA-06 DAC, by adding the PID/VID 1852:5065. Rename "is_marantz_denon_dac()" function to "is_itf_usb_dsd_2alts_dac()" to cover broader device family sharing the same USB audio implementation(*). For the same reason, rename "is_teac_dsd_dac()" function to "is_itf_usb_dsd_3alts_dac()". (*) These devices have the same USB controller "ITF-USB DSD", supplied by INTERFACE Co., Ltd. "ITF-USB DSD" USB controller has two patterns, Pattern 1. (2 altsets version) - Altset 0: for control - Altset 1: for stream (S32) - Altset 2: for stream (S32, DSD_U32) Pattern 2. (3 altsets version) - Altset 0: for control - Altset 1: for stream (S16) - Altset 2: for stream (S32) - Altset 3: for stream (S32, DSD_U32) "is_itf_usb_dsd_2alts_dac()" returns true, if the DAC has "Pattern 1" USB controller, and "is_itf_usb_dsd_3alts_dac()" returns true, if "Pattern2". Signed-off-by: Nobutaka Okabe Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d711223606e893e21a92706b269e0c7f1e5b2ce6 Author: Vicente Bergas Date: Tue Mar 20 19:41:10 2018 +0100 Bluetooth: btusb: Add USB ID 7392:a611 for Edimax EW-7611ULB [ Upstream commit a41e0796396eeceff673af4a38feaee149c6ff86 ] This WiFi/Bluetooth USB dongle uses a Realtek chipset, so, use btrtl for it. Product information: https://wikidevi.com/wiki/Edimax_EW-7611ULB >From /sys/kernel/debug/usb/devices T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=7392 ProdID=a611 Rev= 2.00 S: Manufacturer=Realtek S: Product=Edimax Wi-Fi N150 Bluetooth4.0 USB Adapter S: SerialNumber=00e04c000001 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8723bu E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=500us E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Tested-by: Vicente Bergas Signed-off-by: Vicente Bergas Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 89509cdb713f0dd6825fb600b3974a786905fdaf Author: Giuseppe Lippolis Date: Mon Mar 26 16:34:39 2018 +0200 net-usb: add qmi_wwan if on lte modem wistron neweb d18q1 [ Upstream commit d4c4bc11353f3bea6754f7d21e3612c9f32d1d64 ] This modem is embedded on dlink dwr-921 router. The oem configuration states: T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1435 ProdID=0918 Rev= 2.32 S: Manufacturer=Android S: Product=Android S: SerialNumber=0123456789ABCDEF C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 64 Ivl=32ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=32ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none) E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=125us Tested on openwrt distribution Signed-off-by: Giuseppe Lippolis Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 58249157c6ad4d3796eb1c00036689fe078eaef7 Author: Torsten Hilbrich Date: Mon Mar 26 07:19:57 2018 +0200 net/usb/qmi_wwan.c: Add USB id for lt4120 modem [ Upstream commit f3d801baf118c9d452ee7c278df16880c892e669 ] This is needed to support the modem found in HP EliteBook 820 G3. Signed-off-by: Torsten Hilbrich Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ce04fbcdb39af0d3afc96115f10b39e46501e9b5 Author: Fredrik Noring Date: Fri Mar 9 18:34:34 2018 +0100 USB: OHCI: Fix NULL dereference in HCDs using HCD_LOCAL_MEM [ Upstream commit d6c931ea32dc08ac2665bb5f009f9c40ad1bbdb3 ] Scatter-gather needs to be disabled when using dma_declare_coherent_memory and HCD_LOCAL_MEM. Andrea Righi made the equivalent fix for EHCI drivers in commit 4307a28eb01284 "USB: EHCI: fix NULL pointer dererence in HCDs that use HCD_LOCAL_MEM". The following NULL pointer WARN_ON_ONCE triggered with OHCI drivers: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 49 at drivers/usb/core/hcd.c:1379 hcd_alloc_coherent+0x4c/0xc8 Modules linked in: CPU: 0 PID: 49 Comm: usb-storage Not tainted 4.15.0+ #1014 Stack : 00000000 00000000 805a78d2 0000003a 81f5c2cc 8053d367 804d77fc 00000031 805a3a08 00000563 81ee9400 805a0000 00000000 10058c00 81f61b10 805c0000 00000000 00000000 805a0000 00d9038e 00000004 803ee818 00000006 312e3420 805c0000 00000000 00000073 81f61958 00000000 00000000 802eb380 804fd538 00000009 00000563 81ee9400 805a0000 00000002 80056148 00000000 805a0000 ... Call Trace: [<578af360>] show_stack+0x74/0x104 [<2f3702c6>] __warn+0x118/0x120 [] warn_slowpath_null+0x44/0x58 [] hcd_alloc_coherent+0x4c/0xc8 [<3578fa36>] usb_hcd_map_urb_for_dma+0x4d8/0x534 [<110bc94c>] usb_hcd_submit_urb+0x82c/0x834 [<02eb5baf>] usb_sg_wait+0x14c/0x1a0 [] usb_stor_bulk_transfer_sglist.part.1+0xac/0x124 [<87a5c34c>] usb_stor_bulk_srb+0x40/0x60 [] usb_stor_Bulk_transport+0x160/0x37c [] usb_stor_invoke_transport+0x3c/0x500 [<004754f4>] usb_stor_control_thread+0x258/0x28c [<22edf42e>] kthread+0x134/0x13c [] ret_from_kernel_thread+0x14/0x1c ---[ end trace bcdb825805eefdcc ]--- Signed-off-by: Fredrik Noring Acked-by: Alan Stern Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e5c8a6d499a1010eacacaef0ffc3e8c807282530 Author: Yoshihiro Shimoda Date: Thu Mar 8 17:17:16 2018 +0200 usb: host: xhci-plat: revert "usb: host: xhci-plat: enable clk in resume timing" [ Upstream commit d56e57ca030c8b4296944a2ae61ac167bf979c07 ] This patch reverts the commit 835e4241e714 ("usb: host: xhci-plat: enable clk in resume timing") because this driver also has runtime PM and the commit 560869100b99 ("clk: renesas: cpg-mssr: Restore module clocks during resume") will restore the clock on R-Car H3 environment. If the xhci_plat_suspend() disables the clk, the system cannot enable the clk in resume like the following behavior: < In resume > - genpd_resume_noirq() runs and enable the clk (enable_count = 1) - cpg_mssr_resume_noirq() restores the clk register. -- Since the clk was disabled in suspend, cpg_mssr_resume_noirq() will disable the clk and keep the enable_count. - Even if xhci_plat_resume() calls clk_prepare_enable(), since the enable_count is 1, the clk will be not enabled. After this patch is applied, the cpg-mssr driver will save the clk as enable, so the clk will be enabled in resume. Fixes: 835e4241e714 ("usb: host: xhci-plat: enable clk in resume timing") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Mathias Nyman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 38ed02d8584024951164d1fd2ec512fd9865de6d Author: Leonard Crestez Date: Thu Mar 1 14:52:08 2018 +0200 ARM: dts: imx7d-sdb: Fix regulator-usb-otg2-vbus node name [ Upstream commit 970656b3246d30955894951ed16bd658e42d8c24 ] The two usb-otg regulators for imx7d-sdb are both called "regulator-usb-otg1-vbus" and they effectively override each other. This is most likely a copy-paste error. Fixes: b877039aa1fe ("ARM: dts: imx7d-sdb: Adjust the regulator nodes") Signed-off-by: Leonard Crestez Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5788084ba3cd9da81342be9c64ef8cb76a9874fd Author: Eric Dumazet Date: Mon Mar 5 11:41:13 2018 -0800 net: usbnet: fix potential deadlock on 32bit hosts [ Upstream commit 2695578b896aea472b2c0dcbe9d92daa71738484 ] Marek reported a LOCKDEP issue occurring on 32bit host, that we tracked down to the fact that usbnet could either run from soft or hard irqs. This patch adds u64_stats_update_begin_irqsave() and u64_stats_update_end_irqrestore() helpers to solve this case. [ 17.768040] ================================ [ 17.772239] WARNING: inconsistent lock state [ 17.776511] 4.16.0-rc3-next-20180227-00007-g876c53a7493c #453 Not tainted [ 17.783329] -------------------------------- [ 17.787580] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 17.793607] swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes: [ 17.798751] (&syncp->seq#5){?.-.}, at: [<9b22e5f0>] asix_rx_fixup_internal+0x188/0x288 [ 17.806790] {IN-HARDIRQ-W} state was registered at: [ 17.811677] tx_complete+0x100/0x208 [ 17.815319] __usb_hcd_giveback_urb+0x60/0xf0 [ 17.819770] xhci_giveback_urb_in_irq+0xa8/0x240 [ 17.824469] xhci_td_cleanup+0xf4/0x16c [ 17.828367] xhci_irq+0xe74/0x2240 [ 17.831827] usb_hcd_irq+0x24/0x38 [ 17.835343] __handle_irq_event_percpu+0x98/0x510 [ 17.840111] handle_irq_event_percpu+0x1c/0x58 [ 17.844623] handle_irq_event+0x38/0x5c [ 17.848519] handle_fasteoi_irq+0xa4/0x138 [ 17.852681] generic_handle_irq+0x18/0x28 [ 17.856760] __handle_domain_irq+0x6c/0xe4 [ 17.860941] gic_handle_irq+0x54/0xa0 [ 17.864666] __irq_svc+0x70/0xb0 [ 17.867964] arch_cpu_idle+0x20/0x3c [ 17.871578] arch_cpu_idle+0x20/0x3c [ 17.875190] do_idle+0x144/0x218 [ 17.878468] cpu_startup_entry+0x18/0x1c [ 17.882454] start_kernel+0x394/0x400 [ 17.886177] irq event stamp: 161912 [ 17.889616] hardirqs last enabled at (161912): [<7bedfacf>] __netdev_alloc_skb+0xcc/0x140 [ 17.897893] hardirqs last disabled at (161911): [] __netdev_alloc_skb+0x94/0x140 [ 17.904903] exynos5-hsi2c 12ca0000.i2c: tx timeout [ 17.906116] softirqs last enabled at (161904): [<387102ff>] irq_enter+0x78/0x80 [ 17.906123] softirqs last disabled at (161905): [] irq_exit+0x134/0x158 [ 17.925722]. [ 17.925722] other info that might help us debug this: [ 17.933435] Possible unsafe locking scenario: [ 17.933435]. [ 17.940331] CPU0 [ 17.942488] ---- [ 17.944894] lock(&syncp->seq#5); [ 17.948274] [ 17.950847] lock(&syncp->seq#5); [ 17.954386]. [ 17.954386] *** DEADLOCK *** [ 17.954386]. [ 17.962422] no locks held by swapper/0/0. Fixes: c8b5d129ee29 ("net: usbnet: support 64bit stats") Signed-off-by: Eric Dumazet Reported-by: Marek Szyprowski Cc: Greg Ungerer Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7b3f33c79b77c42cb5621d79a2c05b0085d53ed Author: Dominik Bozek Date: Thu Feb 15 21:27:48 2018 -0800 usb: cdc_acm: prevent race at write to acm while system resumes [ Upstream commit b86b8eb6fecb5a4bac1ed0ca925c4082a61ea6e9 ] ACM driver may accept data to transmit while system is not fully resumed. In this case ACM driver buffers data and prepare URBs on usb anchor list. There is a little chance that two tasks put a char and initiate acm_tty_flush_chars(). In such a case, driver will put one URB twice on usb anchor list. This patch also reset length of data before resue of a buffer. This not only prevent sending rubbish, but also lower risc of race. Without this patch we hit following kernel panic in one of our stabilty/stress tests. [ 46.884442] *list_add double add*: new=ffff9b2ab7289330, prev=ffff9b2ab7289330, next=ffff9b2ab81e28e0. [ 46.884476] Modules linked in: hci_uart btbcm bluetooth rfkill_gpio igb_avb(O) cfg80211 snd_soc_sst_bxt_tdf8532 snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_sst_acpi snd_soc_sst_match snd_hda_ext_core snd_hda_core trusty_timer trusty_wall trusty_log trusty_virtio trusty_ipc trusty_mem trusty_irq trusty virtio_ring virtio intel_ipu4_mmu_bxtB0 lib2600_mod_bxtB0 intel_ipu4_isys_mod_bxtB0 lib2600psys_mod_bxtB0 intel_ipu4_psys_mod_bxtB0 intel_ipu4_mod_bxtB0 intel_ipu4_wrapper_bxtB0 intel_ipu4_acpi videobuf2_dma_contig as3638 dw9714 lm3643 crlmodule smiapp smiapp_pll [ 46.884480] CPU: 1 PID: 33 Comm: kworker/u8:1 Tainted: G U W O 4.9.56-quilt-2e5dc0ac-g618ed69ced6e-dirty #4 [ 46.884489] Workqueue: events_unbound flush_to_ldisc [ 46.884494] ffffb98ac012bb08 ffffffffad3e82e5 ffffb98ac012bb58 0000000000000000 [ 46.884497] ffffb98ac012bb48 ffffffffad0a23d1 00000024ad6374dd ffff9b2ab7289330 [ 46.884500] ffff9b2ab81e28e0 ffff9b2ab7289330 0000000000000002 0000000000000000 [ 46.884501] Call Trace: [ 46.884507] [] dump_stack+0x67/0x92 [ 46.884511] [] __warn+0xd1/0xf0 [ 46.884513] [] warn_slowpath_fmt+0x5f/0x80 [ 46.884516] [] __list_add+0xb3/0xc0 [ 46.884521] [] *usb_anchor_urb*+0x4c/0xa0 [ 46.884524] [] *acm_tty_flush_chars*+0x8f/0xb0 [ 46.884527] [] *acm_tty_put_char*+0x41/0x100 [ 46.884530] [] tty_put_char+0x24/0x40 [ 46.884533] [] do_output_char+0xa5/0x200 [ 46.884535] [] __process_echoes+0x148/0x290 [ 46.884538] [] n_tty_receive_buf_common+0x57c/0xb00 [ 46.884541] [] n_tty_receive_buf2+0x14/0x20 [ 46.884543] [] tty_ldisc_receive_buf+0x22/0x50 [ 46.884545] [] flush_to_ldisc+0xc5/0xe0 [ 46.884549] [] process_one_work+0x148/0x440 [ 46.884551] [] worker_thread+0x69/0x4a0 [ 46.884554] [] ? max_active_store+0x80/0x80 [ 46.884556] [] kthread+0x110/0x130 [ 46.884559] [] ? kthread_park+0x60/0x60 [ 46.884563] [] ret_from_fork+0x27/0x40 [ 46.884566] ---[ end trace 3bd599058b8a9eb3 ]--- Signed-off-by: Dominik Bozek Signed-off-by: Kuppuswamy Sathyanarayanan Acked-by: Oliver Neukum Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ee4ed01d4b5cf050fdce241cbf59bea40d079fd9 Author: Vardan Mikayelyan Date: Tue Jan 16 16:04:24 2018 +0400 usb: dwc2: Fix dwc2_hsotg_core_init_disconnected() [ Upstream commit 755d739534f998d92e348fba8ffb0478416576e7 ] We should call dwc2_hsotg_enqueue_setup() after properly setting lx_state. Because it may cause error-out from dwc2_hsotg_enqueue_setup() due to wrong value in lx_state. Issue can be reproduced by loading driver while connected A-Connector (start in A-HOST mode) then disconnect A-Connector to switch to B-DEVICE. Acked-by: John Youn Signed-off-by: Vardan Mikayelyan Signed-off-by: Grigor Tovmasyan Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a3fcccd4a7efc241de5a0c32d9ea31e0f2297ceb Author: Stefan Agner Date: Mon Feb 12 00:14:42 2018 +0100 usb: gadget: fsl_udc_core: fix ep valid checks [ Upstream commit 20c63f4089cceab803438c383631963e34c4d8e5 ] Clang reports the following warning: drivers/usb/gadget/udc/fsl_udc_core.c:1312:10: warning: address of array 'ep->name' will always evaluate to 'true' [-Wpointer-bool-conversion] if (ep->name) ~~ ~~~~^~~~ It seems that the authors intention was to check if the ep has been configured through struct_ep_setup. Check whether struct usb_ep name pointer has been set instead. Signed-off-by: Stefan Agner Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 36d66139a351b499dc902dcc474e150d000726e6 Author: Manu Gautam Date: Thu Dec 21 09:54:25 2017 +0530 usb: gadget: core: Fix use-after-free of usb_request [ Upstream commit e74bd4d358e5455233f1dcc3975425905b270b91 ] Driver is tracing usb_request after freeing it. Fix it by changing the order. Signed-off-by: Manu Gautam Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aefc5ce2342a91235149e6cfeccdb44c31776c1b Author: Roger Quadros Date: Mon Jan 22 15:01:42 2018 +0200 usb: dwc3: omap: don't miss events during suspend/resume [ Upstream commit c49f63055e252810e5d6c83a4943b18db16b3cd8 ] The USB cable state can change during suspend/resume so be sure to check and update the extcon state. Signed-off-by: Roger Quadros Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e8f101ec20c09be9f8635ac053bd2a5dff22482c Author: Brian Norris Date: Wed Jan 17 13:22:49 2018 -0800 usb: dwc3: Undo PHY init if soft reset fails [ Upstream commit 00b42170c86f90ac9dea83a7dfcd3f0c38098fe2 ] In this function, we init the USB2 and USB3 PHYs, but if soft reset times out, we don't unwind this. Noticed by inspection. Signed-off-by: Brian Norris Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0cc948e8ddb5dab378a2648f384dd87350aa7776 Author: John Keeping Date: Fri Jan 12 18:43:32 2018 +0000 usb: gadget: f_uac2: fix bFirstInterface in composite gadget [ Upstream commit 8813a59ed892305b5ac1b5b901740b1ad4b5fefa ] If there are multiple functions associated with a configuration, then the UAC2 interfaces may not start at zero. Set the correct first interface number in the association descriptor so that the audio interfaces are enumerated correctly in this case. Reviewed-by: Krzysztof Opasiak Signed-off-by: John Keeping Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0ff6b2cac941e05ba436ca9468d21e478999e101 Author: Tetsuo Handa Date: Wed May 9 19:42:20 2018 +0900 x86/kexec: Avoid double free_page() upon do_kexec_load() failure commit a466ef76b815b86748d9870ef2a430af7b39c710 upstream. >From ff82bedd3e12f0d3353282054ae48c3bd8c72012 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Wed, 9 May 2018 12:12:39 +0900 Subject: x86/kexec: Avoid double free_page() upon do_kexec_load() failure syzbot is reporting crashes after memory allocation failure inside do_kexec_load() [1]. This is because free_transition_pgtable() is called by both init_transition_pgtable() and machine_kexec_cleanup() when memory allocation failed inside init_transition_pgtable(). Regarding 32bit code, machine_kexec_free_page_tables() is called by both machine_kexec_alloc_page_tables() and machine_kexec_cleanup() when memory allocation failed inside machine_kexec_alloc_page_tables(). Fix this by leaving the error handling to machine_kexec_cleanup() (and optionally setting NULL after free_page()). [1] https://syzkaller.appspot.com/bug?id=91e52396168cf2bdd572fe1e1bc0bc645c1c6b40 Fixes: f5deb79679af6eb4 ("x86: kexec: Use one page table in x86_64 machine_kexec") Fixes: 92be3d6bdf2cb349 ("kexec/i386: allocate page table pages dynamically") Reported-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Thomas Gleixner Acked-by: Baoquan He Cc: thomas.lendacky@amd.com Cc: prudo@linux.vnet.ibm.com Cc: Huang Ying Cc: syzkaller-bugs@googlegroups.com Cc: takahiro.akashi@linaro.org Cc: H. Peter Anvin Cc: akpm@linux-foundation.org Cc: dyoung@redhat.com Cc: kirill.shutemov@linux.intel.com Link: https://lkml.kernel.org/r/201805091942.DGG12448.tMFVFSJFQOOLHO@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman commit f119414a8f8d006f2929b9c236e6443b0fcbbae6 Author: Tetsuo Handa Date: Fri May 18 16:09:16 2018 -0700 hfsplus: stop workqueue when fill_super() failed commit 66072c29328717072fd84aaff3e070e3f008ba77 upstream. syzbot is reporting ODEBUG messages at hfsplus_fill_super() [1]. This is because hfsplus_fill_super() forgot to call cancel_delayed_work_sync(). As far as I can see, it is hfsplus_mark_mdb_dirty() from hfsplus_new_inode() in hfsplus_fill_super() that calls queue_delayed_work(). Therefore, I assume that hfsplus_new_inode() does not fail if queue_delayed_work() was called, and the out_put_hidden_dir label is the appropriate location to call cancel_delayed_work_sync(). [1] https://syzkaller.appspot.com/bug?id=a66f45e96fdbeb76b796bf46eb25ea878c42a6c9 Link: http://lkml.kernel.org/r/964a8b27-cd69-357c-fe78-76b066056201@I-love.SAKURA.ne.jp Signed-off-by: Tetsuo Handa Reported-by: syzbot Cc: Al Viro Cc: David Howells Cc: Ernesto A. Fernandez Cc: Vyacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9f2c35864ad690ba95e6526a136805fd8a8cdb3b Author: Johannes Berg Date: Tue Apr 3 14:33:49 2018 +0200 cfg80211: limit wiphy names to 128 bytes commit a7cfebcb7594a24609268f91299ab85ba064bf82 upstream. There's currently no limit on wiphy names, other than netlink message size and memory limitations, but that causes issues when, for example, the wiphy name is used in a uevent, e.g. in rfkill where we use the same name for the rfkill instance, and then the buffer there is "only" 2k for the environment variables. This was reported by syzkaller, which used a 4k name. Limit the name to something reasonable, I randomly picked 128. Reported-by: syzbot+230d9e642a85d3fec29c@syzkaller.appspotmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 360964411d57d060d0b3f067c7a708ba9aeb5e07 Author: Omar Sandoval Date: Fri Apr 6 09:57:03 2018 -0700 loop: fix LOOP_GET_STATUS lock imbalance commit bdac616db9bbadb90b7d6a406144571015e138f7 upstream. Commit 2d1d4c1e591f made loop_get_status() drop lo_ctx_mutex before returning, but the loop_get_status_old(), loop_get_status64(), and loop_get_status_compat() wrappers don't call loop_get_status() if the passed argument is NULL. The callers expect that the lock is dropped, so make sure we drop it in that case, too. Reported-by: syzbot+31e8daa8b3fc129e75f2@syzkaller.appspotmail.com Fixes: 2d1d4c1e591f ("loop: don't call into filesystem while holding lo_ctl_mutex") Signed-off-by: Omar Sandoval Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c18270ac9f8457c3d383e9b9a58e6368e046ce8a Author: Omar Sandoval Date: Mon Mar 26 21:39:11 2018 -0700 loop: don't call into filesystem while holding lo_ctl_mutex commit 2d1d4c1e591fd40bd7dafd868a249d7d00e215d5 upstream. We hit an issue where a loop device on NFS was stuck in loop_get_status() doing vfs_getattr() after the NFS server died, which caused a pile-up of uninterruptible processes waiting on lo_ctl_mutex. There's no reason to hold this lock while we wait on the filesystem; let's drop it so that other processes can do their thing. We need to grab a reference on lo_backing_file while we use it, and we can get rid of the check on lo_device, which has been unnecessary since commit a34c0ae9ebd6 ("[PATCH] loop: remove the bio remapping capability") in the linux-history tree. Signed-off-by: Omar Sandoval Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3c017b9fede935c21f3585b7deafcce6c6a8f4fb Author: Jens Remus Date: Thu May 3 13:52:47 2018 +0200 scsi: zfcp: fix infinite iteration on ERP ready list commit fa89adba1941e4f3b213399b81732a5c12fd9131 upstream. zfcp_erp_adapter_reopen() schedules blocking of all of the adapter's rports via zfcp_scsi_schedule_rports_block() and enqueues a reopen adapter ERP action via zfcp_erp_action_enqueue(). Both are separately processed asynchronously and concurrently. Blocking of rports is done in a kworker by zfcp_scsi_rport_work(). It calls zfcp_scsi_rport_block(), which then traces a DBF REC "scpdely" via zfcp_dbf_rec_trig(). zfcp_dbf_rec_trig() acquires the DBF REC spin lock and then iterates with list_for_each() over the adapter's ERP ready list without holding the ERP lock. This opens a race window in which the current list entry can be moved to another list, causing list_for_each() to iterate forever on the wrong list, as the erp_ready_head is never encountered as terminal condition. Meanwhile the ERP action can be processed in the ERP thread by zfcp_erp_thread(). It calls zfcp_erp_strategy(), which acquires the ERP lock and then calls zfcp_erp_action_to_running() to move the ERP action from the ready to the running list. zfcp_erp_action_to_running() can move the ERP action using list_move() just during the aforementioned race window. It then traces a REC RUN "erator1" via zfcp_dbf_rec_run(). zfcp_dbf_rec_run() tries to acquire the DBF REC spin lock. If this is held by the infinitely looping kworker, it effectively spins forever. Example Sequence Diagram: Process ERP Thread rport_work ------------------- ------------------- ------------------- zfcp_erp_adapter_reopen() zfcp_erp_adapter_block() zfcp_scsi_schedule_rports_block() lock ERP zfcp_scsi_rport_work() zfcp_erp_action_enqueue(ZFCP_ERP_ACTION_REOPEN_ADAPTER) list_add_tail() on ready !(rport_task==RPORT_ADD) wake_up() ERP thread zfcp_scsi_rport_block() zfcp_dbf_rec_trig() zfcp_erp_strategy() zfcp_dbf_rec_trig() unlock ERP lock DBF REC zfcp_erp_wait() lock ERP | zfcp_erp_action_to_running() | list_for_each() ready | list_move() current entry | ready to running | zfcp_dbf_rec_run() endless loop over running | zfcp_dbf_rec_run_lvl() | lock DBF REC spins forever Any adapter recovery can trigger this, such as setting the device offline or reboot. V4.9 commit 4eeaa4f3f1d6 ("zfcp: close window with unblocked rport during rport gone") introduced additional tracing of (un)blocking of rports. It missed that the adapter->erp_lock must be held when calling zfcp_dbf_rec_trig(). This fix uses the approach formerly introduced by commit aa0fec62391c ("[SCSI] zfcp: Fix sparse warning by providing new entry in dbf") that got later removed by commit ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions."). Introduce zfcp_dbf_rec_trig_lock(), a wrapper for zfcp_dbf_rec_trig() that acquires and releases the adapter->erp_lock for read. Reported-by: Sebastian Ott Signed-off-by: Jens Remus Fixes: 4eeaa4f3f1d6 ("zfcp: close window with unblocked rport during rport gone") Cc: # 2.6.32+ Reviewed-by: Benjamin Block Signed-off-by: Steffen Maier Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d827bea2d18c07ba514f7d48cde49f90da9a1384 Author: Alexander Potapenko Date: Fri May 18 16:23:18 2018 +0200 scsi: sg: allocate with __GFP_ZERO in sg_build_indirect() commit a45b599ad808c3c982fdcdc12b0b8611c2f92824 upstream. This shall help avoid copying uninitialized memory to the userspace when calling ioctl(fd, SG_IO) with an empty command. Reported-by: syzbot+7d26fc1eea198488deab@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Alexander Potapenko Acked-by: Douglas Gilbert Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 58442874542fb41fd53de4ab34be180ad43779c9 Author: Jason Yan Date: Thu Mar 8 10:34:53 2018 +0800 scsi: libsas: defer ata device eh commands to libata commit 318aaf34f1179b39fa9c30fa0f3288b645beee39 upstream. When ata device doing EH, some commands still attached with tasks are not passed to libata when abort failed or recover failed, so libata did not handle these commands. After these commands done, sas task is freed, but ata qc is not freed. This will cause ata qc leak and trigger a warning like below: WARNING: CPU: 0 PID: 28512 at drivers/ata/libata-eh.c:4037 ata_eh_finish+0xb4/0xcc CPU: 0 PID: 28512 Comm: kworker/u32:2 Tainted: G W OE 4.14.0#1 ...... Call trace: [] ata_eh_finish+0xb4/0xcc [] ata_do_eh+0xc4/0xd8 [] ata_std_error_handler+0x44/0x8c [] ata_scsi_port_error_handler+0x480/0x694 [] async_sas_ata_eh+0x4c/0x80 [] async_run_entry_fn+0x4c/0x170 [] process_one_work+0x144/0x390 [] worker_thread+0x144/0x418 [] kthread+0x10c/0x138 [] ret_from_fork+0x10/0x18 If ata qc leaked too many, ata tag allocation will fail and io blocked for ever. As suggested by Dan Williams, defer ata device commands to libata and merge sas_eh_finish_cmd() with sas_eh_defer_cmd(). libata will handle ata qcs correctly after this. Signed-off-by: Jason Yan CC: Xiaofei Tan CC: John Garry CC: Dan Williams Reviewed-by: Dan Williams Signed-off-by: Martin K. Petersen Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit c1a35f5ddf369ed50bd46bf53d1c54697781317f Author: Martin Schwidefsky Date: Wed May 23 18:22:09 2018 +0200 s390: use expoline thunks in the BPF JIT [ Upstream commit de5cb6eb514ebe241e3edeb290cb41deb380b81d ] The BPF JIT need safe guarding against spectre v2 in the sk_load_xxx assembler stubs and the indirect branches generated by the JIT itself need to be converted to expolines. Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 457b944b61e6f192c8a6136451cce5ca0aa92027 Author: Martin Schwidefsky Date: Wed May 23 18:22:08 2018 +0200 s390: extend expoline to BC instructions [ Upstream commit 6deaa3bbca804b2a3627fd685f75de64da7be535 ] The BPF JIT uses a 'b (%r)' instruction in the definition of the sk_load_word and sk_load_half functions. Add support for branch-on-condition instructions contained in the thunk code of an expoline. Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit a206c82f9bc98a314d8aa98f93d9977147e1b6d0 Author: Martin Schwidefsky Date: Wed May 23 18:22:07 2018 +0200 s390: move spectre sysfs attribute code [ Upstream commit 4253b0e0627ee3461e64c2495c616f1c8f6b127b ] The nospec-branch.c file is compiled without the gcc options to generate expoline thunks. The return branch of the sysfs show functions cpu_show_spectre_v1 and cpu_show_spectre_v2 is an indirect branch as well. These need to be compiled with expolines. Move the sysfs functions for spectre reporting to a separate file and loose an '.' for one of the messages. Cc: stable@vger.kernel.org # 4.16 Fixes: d424986f1d ("s390: add sysfs attributes for spectre") Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 2a146a9b32400b52ca763df14344f7ab8c161f55 Author: Martin Schwidefsky Date: Wed May 23 18:22:06 2018 +0200 s390/kernel: use expoline for indirect branches [ Upstream commit c50c84c3ac4d5db683904bdb3257798b6ef980ae ] The assember code in arch/s390/kernel uses a few more indirect branches which need to be done with execute trampolines for CONFIG_EXPOLINE=y. Cc: stable@vger.kernel.org # 4.16 Fixes: f19fbd5ed6 ("s390: introduce execute-trampolines for branches") Reviewed-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit f1bd3b99607b1e131b07847d3a763295ceacc51e Author: Martin Schwidefsky Date: Wed May 23 18:22:05 2018 +0200 s390/ftrace: use expoline for indirect branches [ Upstream commit 23a4d7fd34856da8218c4cfc23dba7a6ec0a423a ] The return from the ftrace_stub, _mcount, ftrace_caller and return_to_handler functions is done with "br %r14" and "br %r1". These are indirect branches as well and need to use execute trampolines for CONFIG_EXPOLINE=y. The ftrace_caller function is a special case as it returns to the start of a function and may only use %r0 and %r1. For a pre z10 machine the standard execute trampoline uses a LARL + EX to do this, but this requires *two* registers in the range %r1..%r15. To get around this the 'br %r1' located in the lowcore is used, then the EX instruction does not need an address register. But the lowcore trick may only be used for pre z14 machines, with noexec=on the mapping for the first page may not contain instructions. The solution for that is an ALTERNATIVE in the expoline THUNK generated by 'GEN_BR_THUNK %r1' to switch to EXRL, this relies on the fact that a machine that supports noexec=on has EXRL as well. Cc: stable@vger.kernel.org # 4.16 Fixes: f19fbd5ed6 ("s390: introduce execute-trampolines for branches") Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 0d201ff077a8160f1bba570a767ea98e901f3323 Author: Martin Schwidefsky Date: Wed May 23 18:22:04 2018 +0200 s390/lib: use expoline for indirect branches [ Upstream commit 97489e0663fa700d6e7febddc43b58df98d7bcda ] The return from the memmove, memset, memcpy, __memset16, __memset32 and __memset64 functions are done with "br %r14". These are indirect branches as well and need to use execute trampolines for CONFIG_EXPOLINE=y. Cc: stable@vger.kernel.org # 4.16 Fixes: f19fbd5ed6 ("s390: introduce execute-trampolines for branches") Reviewed-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit d7aa3f13e146418b7cbf12e64f1e2cb0261681ca Author: Martin Schwidefsky Date: Wed May 23 18:22:03 2018 +0200 s390/crc32-vx: use expoline for indirect branches [ Upstream commit 467a3bf219cee12259182c5cb4821f88fd518a51 ] The return from the crc32_le_vgfm_16/crc32c_le_vgfm_16 and the crc32_be_vgfm_16 functions are done with "br %r14". These are indirect branches as well and need to use execute trampolines for CONFIG_EXPOLINE=y. Cc: stable@vger.kernel.org # 4.16 Fixes: f19fbd5ed6 ("s390: introduce execute-trampolines for branches") Reviewed-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit e3ad546e6094d1be00d71087c5d0d8656ef5d6c2 Author: Martin Schwidefsky Date: Wed May 23 18:22:02 2018 +0200 s390: move expoline assembler macros to a header [ Upstream commit 6dd85fbb87d1d6b87a3b1f02ca28d7b2abd2e7ba ] To be able to use the expoline branches in different assembler files move the associated macros from entry.S to a new header nospec-insn.h. While we are at it make the macros a bit nicer to use. Cc: stable@vger.kernel.org # 4.16 Fixes: f19fbd5ed6 ("s390: introduce execute-trampolines for branches") Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 9a38169fb6025fdc6d468b1111a43e719c2143a6 Author: Martin Schwidefsky Date: Wed May 23 18:22:01 2018 +0200 s390: add assembler macros for CPU alternatives [ Upstream commit fba9eb7946251d6e420df3bdf7bc45195be7be9a ] Add a header with macros usable in assembler files to emit alternative code sequences. It works analog to the alternatives for inline assmeblies in C files, with the same restrictions and capabilities. The syntax is ALTERNATIVE "", \ "", \ "" and ALTERNATIVE_2 "", \ "", \ "", "", \ "" Reviewed-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 131ff238b85971c75679670be41df5feb6b6530e Author: Al Viro Date: Thu May 17 17:18:30 2018 -0400 ext2: fix a block leak commit 5aa1437d2d9a068c0334bd7c9dafa8ec4f97f13b upstream. open file, unlink it, then use ioctl(2) to make it immutable or append only. Now close it and watch the blocks *not* freed... Immutable/append-only checks belong in ->setattr(). Note: the bug is old and backport to anything prior to 737f2e93b972 ("ext2: convert to use the new truncate convention") will need these checks lifted into ext2_setattr(). Cc: stable@kernel.org Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit ea5ffcd46716fcda3da98313cffcf1ae5dcbb2c2 Author: Arvind Yadav Date: Wed Apr 25 20:26:14 2018 +0530 sparc: vio: use put_device() instead of kfree() [ Upstream commit 00ad691ab140b54ab9f5de5e74cb994f552e8124 ] Never directly free @dev after calling device_register(), even if it returned an error. Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c98b38c5ede478b938944109e71798462c36c88c Author: Mohammed Gamal Date: Mon May 14 15:32:22 2018 -0700 hv_netvsc: Fix net device attach on older Windows hosts [ Commit 55be9f25be1ca5bda75c39808fc77e42691bc07f upstream. ] On older windows hosts the net_device instance is returned to the caller of rndis_filter_device_add() without having the presence bit set first. This would cause any subsequent calls to network device operations (e.g. MTU change, channel change) to fail after the device is detached once, returning -ENODEV. Instead of returning the device instabce, we take the exit path where we call netif_device_attach() Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic") Signed-off-by: Mohammed Gamal Reviewed-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c7da51021c8d3d09cc31396a12af75bb222dcfcf Author: Mohammed Gamal Date: Mon May 14 15:32:21 2018 -0700 hv_netvsc: Ensure correct teardown message sequence order [ Commit a56d99d714665591fed8527b90eef21530ea61e0 upstream. ] Prior to commit 0cf737808ae7 ("hv_netvsc: netvsc_teardown_gpadl() split") the call sequence in netvsc_device_remove() was as follows (as implemented in netvsc_destroy_buf()): 1- Send NVSP_MSG1_TYPE_REVOKE_RECV_BUF message 2- Teardown receive buffer GPADL 3- Send NVSP_MSG1_TYPE_REVOKE_SEND_BUF message 4- Teardown send buffer GPADL 5- Close vmbus This didn't work for WS2016 hosts. Commit 0cf737808ae7 ("hv_netvsc: netvsc_teardown_gpadl() split") rearranged the teardown sequence as follows: 1- Send NVSP_MSG1_TYPE_REVOKE_RECV_BUF message 2- Send NVSP_MSG1_TYPE_REVOKE_SEND_BUF message 3- Close vmbus 4- Teardown receive buffer GPADL 5- Teardown send buffer GPADL That worked well for WS2016 hosts, but it prevented guests on older hosts from shutting down after changing network settings. Commit 0ef58b0a05c1 ("hv_netvsc: change GPAD teardown order on older versions") ensured the following message sequence for older hosts 1- Send NVSP_MSG1_TYPE_REVOKE_RECV_BUF message 2- Send NVSP_MSG1_TYPE_REVOKE_SEND_BUF message 3- Teardown receive buffer GPADL 4- Teardown send buffer GPADL 5- Close vmbus However, with this sequence calling `ip link set eth0 mtu 1000` hangs and the process becomes uninterruptible. On futher analysis it turns out that on tearing down the receive buffer GPADL the kernel is waiting indefinitely in vmbus_teardown_gpadl() for a completion to be signaled. Here is a snippet of where this occurs: int vmbus_teardown_gpadl(struct vmbus_channel *channel, u32 gpadl_handle) { struct vmbus_channel_gpadl_teardown *msg; struct vmbus_channel_msginfo *info; unsigned long flags; int ret; info = kmalloc(sizeof(*info) + sizeof(struct vmbus_channel_gpadl_teardown), GFP_KERNEL); if (!info) return -ENOMEM; init_completion(&info->waitevent); info->waiting_channel = channel; [....] ret = vmbus_post_msg(msg, sizeof(struct vmbus_channel_gpadl_teardown), true); if (ret) goto post_msg_err; wait_for_completion(&info->waitevent); [....] } The completion is signaled from vmbus_ongpadl_torndown(), which gets called when the corresponding message is received from the host, which apparently never happens in that case. This patch works around the issue by restoring the first mentioned message sequence for older hosts Fixes: 0ef58b0a05c1 ("hv_netvsc: change GPAD teardown order on older versions") Signed-off-by: Mohammed Gamal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c5345b11680f22cfe8c1439fcb65f602876a9d1d Author: Mohammed Gamal Date: Mon May 14 15:32:20 2018 -0700 hv_netvsc: Split netvsc_revoke_buf() and netvsc_teardown_gpadl() [ Commit 7992894c305eaf504d005529637ff8283d0a849d upstream. ] Split each of the functions into two for each of send/recv buffers. This will be needed in order to implement a fine-grained messaging sequence to the host so that we accommodate the requirements of different Windows versions Fixes: 0ef58b0a05c12 ("hv_netvsc: change GPAD teardown order on older versions") Signed-off-by: Mohammed Gamal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d8c3e04d39132d2aa72bb62df1b14b95f0af90d8 Author: Mohammed Gamal Date: Mon May 14 15:32:19 2018 -0700 hv_netvsc: Use Windows version instead of NVSP version on GPAD teardown commit 2afc5d61a7197de25a61f54ea4ecfb4cb62b1d42A upstram When changing network interface settings, Windows guests older than WS2016 can no longer shutdown. This was addressed by commit 0ef58b0a05c12 ("hv_netvsc: change GPAD teardown order on older versions"), however the issue also occurs on WS2012 guests that share NVSP protocol versions with WS2016 guests. Hence we use Windows version directly to differentiate them. Fixes: 0ef58b0a05c12 ("hv_netvsc: change GPAD teardown order on older versions") Signed-off-by: Mohammed Gamal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit be9c798d0d13ae609a91177323ac816545c39d28 Author: Stephen Hemminger Date: Mon May 14 15:32:18 2018 -0700 hv_netvsc: common detach logic [ Commit 7b2ee50c0cd513a176a26a71f2989facdd75bfea upstream. ] Make common function for detaching internals of device during changes to MTU and RSS. Make sure no more packets are transmitted and all packets have been received before doing device teardown. Change the wait logic to be common and use usleep_range(). Changes transmit enabling logic so that transmit queues are disabled during the period when lower device is being changed. And enabled only after sub channels are setup. This avoids issue where it could be that a packet was being sent while subchannel was not initialized. Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug") Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 905f85c289d7fafd87fccff3f6d87f3782372e6e Author: Stephen Hemminger Date: Mon May 14 15:32:17 2018 -0700 hv_netvsc: change GPAD teardown order on older versions [ Commit 0ef58b0a05c127762f975c3dfe8b922e4aa87a29 upstream. ] On older versions of Windows, the host ignores messages after vmbus channel is closed. Workaround this by doing what Windows does and send the teardown before close on older versions of NVSP protocol. Reported-by: Mohammed Gamal Fixes: 0cf737808ae7 ("hv_netvsc: netvsc_teardown_gpadl() split") Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9c6439c7b1689f27c0c6957391da22343425ca18 Author: Stephen Hemminger Date: Mon May 14 15:32:16 2018 -0700 hv_netvsc: use RCU to fix concurrent rx and queue changes [ Commit 02400fcee2542ee334a2394e0d9f6efd969fe782 upstream. ] The receive processing may continue to happen while the internal network device state is in RCU grace period. The internal RNDIS structure is associated with the internal netvsc_device structure; both have the same RCU lifetime. Defer freeing all associated parts until after grace period. Fixes: 0cf737808ae7 ("hv_netvsc: netvsc_teardown_gpadl() split") Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1f3ef8a7a3c667f72bcb20be61ec4b4214f355b2 Author: Stephen Hemminger Date: Mon May 14 15:32:15 2018 -0700 hv_netvsc: disable NAPI before channel close [ Commit 8348e0460ab1473f06c8b824699dd2eed3c1979d upstream. ] This makes sure that no CPU is still process packets when the channel is closed. Fixes: 76bb5db5c749 ("netvsc: fix use after free on module removal") Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f9aab25e3326842b1986ecbad2af51a75c0dd646 Author: Stephen Hemminger Date: Mon May 14 15:32:14 2018 -0700 hv_netvsc: defer queue selection to VF [ Commit b3bf5666a51068ad5ddd89a76ed877101ef3bc16 upstream. ] When VF is used for accelerated networking it will likely have more queues (and different policy) than the synthetic NIC. This patch defers the queue policy to the VF so that all the queues can be used. This impacts workloads like local generate UDP. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0ac663c5674a8ed1b986e3de82d6b5427536b5ad Author: Stephen Hemminger Date: Mon May 14 15:32:13 2018 -0700 hv_netvsc: fix race in napi poll when rescheduling [ Commit d64e38ae690e3337db0d38d9b149a193a1646c4b upstream. ] There is a race between napi_reschedule and re-enabling interrupts which could lead to missed host interrrupts. This occurs when interrupts are re-enabled (hv_end_read) and vmbus irq callback (netvsc_channel_cb) has already scheduled NAPI. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 99e06589bd5d6631bbea0a5128257bf16dabac9b Author: Stephen Hemminger Date: Mon May 14 15:32:12 2018 -0700 hv_netvsc: cancel subchannel setup before halting device [ Commit a7483ec0267c69b34e818738da60b392623da94b upstream. ] Block setup of multiple channels earlier in the teardown process. This avoids possible races between halt and subchannel initialization. Suggested-by: Haiyang Zhang Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0ed8945b3aa627ef8ec9dda6442b02c91f27bfb4 Author: Stephen Hemminger Date: Mon May 14 15:32:11 2018 -0700 hv_netvsc: fix error unwind handling if vmbus_open fails [ Commit fcfb4a00d1e514e8313277a01ef919de1113025b upstream. ] Need to delete NAPI association if vmbus_open fails. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4857dca4dd65756dfdb90b33946d8f9d5c6447b8 Author: Stephen Hemminger Date: Mon May 14 15:32:10 2018 -0700 hv_netvsc: only wake transmit queue if link is up [ Commit f4950e4586dfc957e0a28226eeb992ddc049b5a2 upstream. ] Don't wake transmit queues if link is not up yet. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0395570f81feeebbf0f390876c8ca763b6ce773c Author: Stephen Hemminger Date: Mon May 14 15:32:09 2018 -0700 hv_netvsc: avoid retry on send during shutdown [ Commit 12f69661a49446840d742d8feb593ace022d9f66 upstream. ] Change the initialization order so that the device is ready to transmit (ie connect vsp is completed) before setting the internal reference to the device with RCU. This avoids any races on initialization and prevents retry issues on shutdown. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 36a9609cef4a32a1cfd9b8c765671f11caf03a7d Author: Haiyang Zhang Date: Mon May 14 15:32:08 2018 -0700 hv_netvsc: Use the num_online_cpus() for channel limit [ Commit 25a39f7f975c3c26a0052fbf9b59201c06744332 upstream. ] Since we no longer localize channel/CPU affiliation within one NUMA node, num_online_cpus() is used as the number of channel cap, instead of the number of processors in a NUMA node. This patch allows a bigger range for tuning the number of channels. Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4c5fef7789571672459e18170add13ca56f33246 Author: Stephen Hemminger Date: Mon May 14 15:32:07 2018 -0700 hv_netvsc: empty current transmit aggregation if flow blocked [ Commit cfd8afd986cdb59ea9adac873c5082498a1eb7c0 upstream. ] If the transmit queue is known full, then don't keep aggregating data. And the cp_partial flag which indicates that the current aggregation buffer is full can be folded in to avoid more conditionals. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 41f24dbef1771a32f3a8e3f9a2f89633c985df0a Author: Vitaly Kuznetsov Date: Mon May 14 15:32:06 2018 -0700 hv_netvsc: preserve hw_features on mtu/channels/ringparam changes [ Commit aefd80e874e98a864915df5b7d90824a4340b450 upstream. ] rndis_filter_device_add() is called both from netvsc_probe() when we initially create the device and from set channels/mtu/ringparam routines where we basically remove the device and add it back. hw_features is reset in rndis_filter_device_add() and filled with host data. However, we lose all additional flags which are set outside of the driver, e.g. register_netdevice() adds NETIF_F_SOFT_FEATURES and many others. Unfortunately, calls to rndis_{query_hwcaps(), _set_offload_params()} calls cannot be avoided on every RNDIS reset: host expects us to set required features explicitly. Moreover, in theory hardware capabilities can change and we need to reflect the change in hw_features. Reset net->hw_features bits according to host data in rndis_netdev_set_hwcaps(), clear corresponding feature bits from net->features in case some features went missing (will never happen in real life I guess but let's be consistent). Signed-off-by: Vitaly Kuznetsov Reviewed-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 284a58c02eeb7f235f0a465580cf1cd739cc7d5d Author: Vitaly Kuznetsov Date: Mon May 14 15:32:05 2018 -0700 hv_netvsc: netvsc_teardown_gpadl() split [ Commit 0cf737808ae7cb25e952be619db46b9147a92f46 upstream. ] It was found that in some cases host refuses to teardown GPADL for send/ receive buffers (probably when some work with these buffere is scheduled or ongoing). Change the teardown logic to be: 1) Send NVSP_MSG1_TYPE_REVOKE_* messages 2) Close the channel 3) Teardown GPADLs. This seems to work reliably. Signed-off-by: Vitaly Kuznetsov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6296e73e459d76ee9c6c83917bd4da6b5f8a049c Author: Haiyang Zhang Date: Mon May 14 15:32:04 2018 -0700 hv_netvsc: Set tx_table to equal weight after subchannels open [ Commit a6fb6aa3cfa9047b62653dbcfc9bcde6e2272b41 upstream. ] In some cases, like internal vSwitch, the host doesn't provide send indirection table updates. This patch sets the table to be equal weight after subchannels are all open. Otherwise, all workload will be on one TX channel. As tested, this patch has largely increased the throughput over internal vSwitch. Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ef1c5903cd2a44c161de86f862182afddb4a9677 Author: Haiyang Zhang Date: Mon May 14 15:32:03 2018 -0700 hv_netvsc: Add initialization of tx_table in netvsc_device_add() [ Commit 6b0cbe315868d613123cf387052ccda5f09d49ea upstream. ] tx_table is part of the private data of kernel net_device. It is only zero-ed out when allocating net_device. We may recreate netvsc_device w/o recreating net_device, so the private netdev data, including tx_table, are not zeroed. It may contain channel numbers for the older netvsc_device. This patch adds initialization of tx_table each time we recreate netvsc_device. Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b3a303352e5142da2405d59d70aaf6aad04ef932 Author: Haiyang Zhang Date: Mon May 14 15:32:02 2018 -0700 hv_netvsc: Rename tx_send_table to tx_table [ Commit 39e91cfbf6f5fb26ba64cc2e8874372baf1671e7 upstream. ] Simplify the variable name: tx_send_table Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5acc4d1e8fe23da9de9f82129c50cf5a3d6cc796 Author: Haiyang Zhang Date: Mon May 14 15:32:01 2018 -0700 hv_netvsc: Rename ind_table to rx_table [ Commit 47371300dfc269dd8d150e5b872bdbbda98ba809 upstream. ] Rename this variable because it is the Receive indirection table. Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 836f8472f1bded05ea4c35b07009f4fd6fcd6bfa Author: Haiyang Zhang Date: Mon May 14 15:32:00 2018 -0700 hv_netvsc: Fix the real number of queues of non-vRSS cases [ Commit 6450f8f269a9271985e4a8c13920b7e4cf21c0f3 upstream. ] For older hosts without multi-channel (vRSS) support, and some error cases, we still need to set the real number of queues to one. This patch adds this missing setting. Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug") Signed-off-by: Haiyang Zhang Reviewed-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 099612827aa3e09decce41f8a5cd1d473232eeb9 Author: hpreg@vmware.com Date: Mon May 14 08:14:49 2018 -0400 vmxnet3: use DMA memory barriers where required [ Upstream commit f3002c1374fb2367c9d8dbb28852791ef90d2bac ] The gen bits must be read first from (resp. written last to) DMA memory. The proper way to enforce this on Linux is to call dma_rmb() (resp. dma_wmb()). Signed-off-by: Regis Duchesne Acked-by: Ronak Doshi Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 74327eda43d039a47ff8d35e3524ab145f8cdbaf Author: hpreg@vmware.com Date: Mon May 14 08:14:34 2018 -0400 vmxnet3: set the DMA mask before the first DMA map operation [ Upstream commit 61aeecea40afb2b89933e27cd4adb10fc2e75cfd ] The DMA mask must be set before, not after, the first DMA map operation, or the first DMA map operation could in theory fail on some systems. Fixes: b0eb57cb97e78 ("VMXNET3: Add support for virtual IOMMU") Signed-off-by: Regis Duchesne Acked-by: Ronak Doshi Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c89d534301a028125432e7d9a39edb08cfd90480 Author: Eric Dumazet Date: Mon May 14 21:14:26 2018 -0700 tcp: purge write queue in tcp_connect_init() [ Upstream commit 7f582b248d0a86bae5788c548d7bb5bca6f7691a ] syzkaller found a reliable way to crash the host, hitting a BUG() in __tcp_retransmit_skb() Malicous MSG_FASTOPEN is the root cause. We need to purge write queue in tcp_connect_init() at the point we init snd_una/write_seq. This patch also replaces the BUG() by a less intrusive WARN_ON_ONCE() kernel BUG at net/ipv4/tcp_output.c:2837! invalid opcode: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 0 PID: 5276 Comm: syz-executor0 Not tainted 4.17.0-rc3+ #51 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__tcp_retransmit_skb+0x2992/0x2eb0 net/ipv4/tcp_output.c:2837 RSP: 0000:ffff8801dae06ff8 EFLAGS: 00010206 RAX: ffff8801b9fe61c0 RBX: 00000000ffc18a16 RCX: ffffffff864e1a49 RDX: 0000000000000100 RSI: ffffffff864e2e12 RDI: 0000000000000005 RBP: ffff8801dae073a0 R08: ffff8801b9fe61c0 R09: ffffed0039c40dd2 R10: ffffed0039c40dd2 R11: ffff8801ce206e93 R12: 00000000421eeaad R13: ffff8801ce206d4e R14: ffff8801ce206cc0 R15: ffff8801cd4f4a80 FS: 0000000000000000(0000) GS:ffff8801dae00000(0063) knlGS:00000000096bc900 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000020000000 CR3: 00000001c47b6000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tcp_retransmit_skb+0x2e/0x250 net/ipv4/tcp_output.c:2923 tcp_retransmit_timer+0xc50/0x3060 net/ipv4/tcp_timer.c:488 tcp_write_timer_handler+0x339/0x960 net/ipv4/tcp_timer.c:573 tcp_write_timer+0x111/0x1d0 net/ipv4/tcp_timer.c:593 call_timer_fn+0x230/0x940 kernel/time/timer.c:1326 expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x79e/0xc50 kernel/time/timer.c:1666 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1d1/0x200 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:525 [inline] smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863 Fixes: cf60af03ca4e ("net-tcp: Fast Open client - sendmsg(MSG_FASTOPEN)") Signed-off-by: Eric Dumazet Cc: Yuchung Cheng Cc: Neal Cardwell Reported-by: syzbot Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit edabcd0f12ae3f4c1bfa7cc1bc655a6f722fd120 Author: Eric Dumazet Date: Fri May 18 04:47:55 2018 -0700 sock_diag: fix use-after-free read in __sk_free [ Upstream commit 9709020c86f6bf8439ca3effc58cfca49a5de192 ] We must not call sock_diag_has_destroy_listeners(sk) on a socket that has no reference on net structure. BUG: KASAN: use-after-free in sock_diag_has_destroy_listeners include/linux/sock_diag.h:75 [inline] BUG: KASAN: use-after-free in __sk_free+0x329/0x340 net/core/sock.c:1609 Read of size 8 at addr ffff88018a02e3a0 by task swapper/1/0 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.17.0-rc5+ #54 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 sock_diag_has_destroy_listeners include/linux/sock_diag.h:75 [inline] __sk_free+0x329/0x340 net/core/sock.c:1609 sk_free+0x42/0x50 net/core/sock.c:1623 sock_put include/net/sock.h:1664 [inline] reqsk_free include/net/request_sock.h:116 [inline] reqsk_put include/net/request_sock.h:124 [inline] inet_csk_reqsk_queue_drop_and_put net/ipv4/inet_connection_sock.c:672 [inline] reqsk_timer_handler+0xe27/0x10e0 net/ipv4/inet_connection_sock.c:739 call_timer_fn+0x230/0x940 kernel/time/timer.c:1326 expire_timers kernel/time/timer.c:1363 [inline] __run_timers+0x79e/0xc50 kernel/time/timer.c:1666 run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692 __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285 invoke_softirq kernel/softirq.c:365 [inline] irq_exit+0x1d1/0x200 kernel/softirq.c:405 exiting_irq arch/x86/include/asm/apic.h:525 [inline] smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863 RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54 RSP: 0018:ffff8801d9ae7c38 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13 RAX: dffffc0000000000 RBX: 1ffff1003b35cf8a RCX: 0000000000000000 RDX: 1ffffffff11a30d0 RSI: 0000000000000001 RDI: ffffffff88d18680 RBP: ffff8801d9ae7c38 R08: ffffed003b5e46c3 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 R13: ffff8801d9ae7cf0 R14: ffffffff897bef20 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0xc2/0x440 arch/x86/kernel/process.c:354 arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:345 default_idle_call+0x6d/0x90 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x395/0x560 kernel/sched/idle.c:262 cpu_startup_entry+0x104/0x120 kernel/sched/idle.c:368 start_secondary+0x426/0x5b0 arch/x86/kernel/smpboot.c:269 secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242 Allocated by task 4557: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554 kmem_cache_zalloc include/linux/slab.h:691 [inline] net_alloc net/core/net_namespace.c:383 [inline] copy_net_ns+0x159/0x4c0 net/core/net_namespace.c:423 create_new_namespaces+0x69d/0x8f0 kernel/nsproxy.c:107 unshare_nsproxy_namespaces+0xc3/0x1f0 kernel/nsproxy.c:206 ksys_unshare+0x708/0xf90 kernel/fork.c:2408 __do_sys_unshare kernel/fork.c:2476 [inline] __se_sys_unshare kernel/fork.c:2474 [inline] __x64_sys_unshare+0x31/0x40 kernel/fork.c:2474 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 69: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x86/0x2d0 mm/slab.c:3756 net_free net/core/net_namespace.c:399 [inline] net_drop_ns.part.14+0x11a/0x130 net/core/net_namespace.c:406 net_drop_ns net/core/net_namespace.c:405 [inline] cleanup_net+0x6a1/0xb20 net/core/net_namespace.c:541 process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145 worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279 kthread+0x345/0x410 kernel/kthread.c:240 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 The buggy address belongs to the object at ffff88018a02c140 which belongs to the cache net_namespace of size 8832 The buggy address is located 8800 bytes inside of 8832-byte region [ffff88018a02c140, ffff88018a02e3c0) The buggy address belongs to the page: page:ffffea0006280b00 count:1 mapcount:0 mapping:ffff88018a02c140 index:0x0 compound_mapcount: 0 flags: 0x2fffc0000008100(slab|head) raw: 02fffc0000008100 ffff88018a02c140 0000000000000000 0000000100000001 raw: ffffea00062a1320 ffffea0006268020 ffff8801d9bdde40 0000000000000000 page dumped because: kasan: bad access detected Fixes: b922622ec6ef ("sock_diag: don't broadcast kernel sockets") Signed-off-by: Eric Dumazet Cc: Craig Gallek Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 01a658c1b9d4b5393c38d5a92d9112ab1425382a Author: Willem de Bruijn Date: Fri May 11 13:24:25 2018 -0400 packet: in packet_snd start writing at link layer allocation [ Upstream commit b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba ] Packet sockets allow construction of packets shorter than dev->hard_header_len to accommodate protocols with variable length link layer headers. These packets are padded to dev->hard_header_len, because some device drivers interpret that as a minimum packet size. packet_snd reserves dev->hard_header_len bytes on allocation. SOCK_DGRAM sockets call skb_push in dev_hard_header() to ensure that link layer headers are stored in the reserved range. SOCK_RAW sockets do the same in tpacket_snd, but not in packet_snd. Syzbot was able to send a zero byte packet to a device with massive 116B link layer header, causing padding to cross over into skb_shinfo. Fix this by writing from the start of the llheader reserved range also in the case of packet_snd/SOCK_RAW. Update skb_set_network_header to the new offset. This also corrects it for SOCK_DGRAM, where it incorrectly double counted reserve due to the skb_push in dev_hard_header. Fixes: 9ed988cd5915 ("packet: validate variable length ll headers") Reported-by: syzbot+71d74a5406d02057d559@syzkaller.appspotmail.com Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c02756173e654eb4dade1dc01d9419e338cf0ffa Author: Willem de Bruijn Date: Thu May 17 13:13:29 2018 -0400 net: test tailroom before appending to linear skb [ Upstream commit 113f99c3358564a0647d444c2ae34e8b1abfd5b9 ] Device features may change during transmission. In particular with corking, a device may toggle scatter-gather in between allocating and writing to an skb. Do not unconditionally assume that !NETIF_F_SG at write time implies that the same held at alloc time and thus the skb has sufficient tailroom. This issue predates git history. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Eric Dumazet Signed-off-by: Willem de Bruijn Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2cedbdda01fe1926d4c7c3ee117d2855803d55a3 Author: Eric Biggers Date: Sun May 13 17:01:30 2018 -0700 net/smc: check for missing nlattrs in SMC_PNETID messages [ Upstream commit d49baa7e12ee70c0a7b821d088a770c94c02e494 ] It's possible to crash the kernel in several different ways by sending messages to the SMC_PNETID generic netlink family that are missing the expected attributes: - Missing SMC_PNETID_NAME => null pointer dereference when comparing names. - Missing SMC_PNETID_ETHNAME => null pointer dereference accessing smc_pnetentry::ndev. - Missing SMC_PNETID_IBNAME => null pointer dereference accessing smc_pnetentry::smcibdev. - Missing SMC_PNETID_IBPORT => out of bounds array access to smc_ib_device::pattr[-1]. Fix it by validating that all expected attributes are present and that SMC_PNETID_IBPORT is nonzero. Reported-by: syzbot+5cd61039dc9b8bfa6e47@syzkaller.appspotmail.com Fixes: 6812baabf24d ("smc: establish pnet table management") Cc: # v4.11+ Signed-off-by: Eric Biggers Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8ffa5f9783941fa24f7c8ffc5d8a494bd26c5a47 Author: Paolo Abeni Date: Fri May 18 14:51:44 2018 +0200 net: sched: red: avoid hashing NULL child [ Upstream commit 44a63b137f7b6e4c7bd6c9cc21615941cb36509d ] Hangbin reported an Oops triggered by the syzkaller qdisc rules: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN PTI Modules linked in: sch_red CPU: 0 PID: 28699 Comm: syz-executor5 Not tainted 4.17.0-rc4.kcov #1 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:qdisc_hash_add+0x26/0xa0 RSP: 0018:ffff8800589cf470 EFLAGS: 00010203 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff824ad971 RDX: 0000000000000007 RSI: ffffc9000ce9f000 RDI: 000000000000003c RBP: 0000000000000001 R08: ffffed000b139ea2 R09: ffff8800589cf4f0 R10: ffff8800589cf50f R11: ffffed000b139ea2 R12: ffff880054019fc0 R13: ffff880054019fb4 R14: ffff88005c0af600 R15: ffff880054019fb0 FS: 00007fa6edcb1700(0000) GS:ffff88005ce00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000740 CR3: 000000000fc16000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: red_change+0x2d2/0xed0 [sch_red] qdisc_create+0x57e/0xef0 tc_modify_qdisc+0x47f/0x14e0 rtnetlink_rcv_msg+0x6a8/0x920 netlink_rcv_skb+0x2a2/0x3c0 netlink_unicast+0x511/0x740 netlink_sendmsg+0x825/0xc30 sock_sendmsg+0xc5/0x100 ___sys_sendmsg+0x778/0x8e0 __sys_sendmsg+0xf5/0x1b0 do_syscall_64+0xbd/0x3b0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x450869 RSP: 002b:00007fa6edcb0c48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fa6edcb16b4 RCX: 0000000000450869 RDX: 0000000000000000 RSI: 00000000200000c0 RDI: 0000000000000013 RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 0000000000008778 R14: 0000000000702838 R15: 00007fa6edcb1700 Code: e9 0b fe ff ff 0f 1f 44 00 00 55 53 48 89 fb 89 f5 e8 3f 07 f3 fe 48 8d 7b 3c 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 51 RIP: qdisc_hash_add+0x26/0xa0 RSP: ffff8800589cf470 When a red qdisc is updated with a 0 limit, the child qdisc is left unmodified, no additional scheduler is created in red_change(), the 'child' local variable is rightfully NULL and must not add it to the hash table. This change addresses the above issue moving qdisc_hash_add() right after the child qdisc creation. It additionally removes unneeded checks for noop_qdisc. Reported-by: Hangbin Liu Fixes: 49b499718fa1 ("net: sched: make default fifo qdiscs appear in the dump") Signed-off-by: Paolo Abeni Acked-by: Jiri Kosina Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 53b2dbbee18dc6bd94d73050eedb9ab4fa1120f6 Author: Davide Caratti Date: Wed May 16 12:54:29 2018 +0200 net/sched: fix refcnt leak in the error path of tcf_vlan_init() [ Upstream commit 5a4931ae0193f8a4a97e8260fd0df1d705d83299 ] Similarly to what was done with commit a52956dfc503 ("net sched actions: fix refcnt leak in skbmod"), fix the error path of tcf_vlan_init() to avoid refcnt leaks when wrong value of TCA_VLAN_PUSH_VLAN_PROTOCOL is given. Fixes: 5026c9b1bafc ("net sched: vlan action fix late binding") CC: Roman Mashak Signed-off-by: Davide Caratti Acked-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5ff45c86e90a493f8e332c9218026c183ce724e2 Author: Tarick Bedeir Date: Sun May 13 16:38:45 2018 -0700 net/mlx4_core: Fix error handling in mlx4_init_port_info. [ Upstream commit 57f6f99fdad9984801cde05c1db68fe39b474a10 ] Avoid exiting the function with a lingering sysfs file (if the first call to device_create_file() fails while the second succeeds), and avoid calling devlink_port_unregister() twice. In other words, either mlx4_init_port_info() succeeds and returns zero, or it fails, returns non-zero, and requires no cleanup. Fixes: 096335b3f983 ("mlx4_core: Allow dynamic MTU configuration for IB ports") Signed-off-by: Tarick Bedeir Reviewed-by: Leon Romanovsky Reviewed-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 047df46d6cef651e4a32637632a84916e24b054b Author: Amritha Nambiar Date: Thu May 17 14:50:44 2018 -0700 net: Fix a bug in removing queues from XPS map [ Upstream commit 6358d49ac23995fdfe157cc8747ab0f274d3954b ] While removing queues from the XPS map, the individual CPU ID alone was used to index the CPUs map, this should be changed to also factor in the traffic class mapping for the CPU-to-queue lookup. Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes") Signed-off-by: Amritha Nambiar Acked-by: Alexander Duyck Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1dff08485b9e835d00bfb34a435bc6f07dadb6fd Author: Greg Kroah-Hartman Date: Tue May 22 18:54:07 2018 +0200 Linux 4.14.43 commit 92a3c944d6d5d3e08335cd3b6a75df907a43a960 Author: Konrad Rzeszutek Wilk Date: Wed May 16 23:18:09 2018 -0400 x86/bugs: Rename SSBD_NO to SSB_NO commit 240da953fcc6a9008c92fae5b1f727ee5ed167ab upstream The "336996 Speculative Execution Side Channel Mitigations" from May defines this as SSB_NO, hence lets sync-up. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit e8837f0a000f79e1e629ad8a00eceb3c452bf3bc Author: Tom Lendacky Date: Thu May 10 22:06:39 2018 +0200 KVM: SVM: Implement VIRT_SPEC_CTRL support for SSBD commit bc226f07dcd3c9ef0b7f6236fe356ea4a9cb4769 upstream Expose the new virtualized architectural mechanism, VIRT_SSBD, for using speculative store bypass disable (SSBD) under SVM. This will allow guests to use SSBD on hardware that uses non-architectural mechanisms for enabling SSBD. [ tglx: Folded the migration fixup from Paolo Bonzini ] Signed-off-by: Tom Lendacky Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 3f44c1a3c29379aa976be27df1da0fc4b9e7c364 Author: Thomas Gleixner Date: Thu May 10 20:42:48 2018 +0200 x86/speculation, KVM: Implement support for VIRT_SPEC_CTRL/LS_CFG commit 47c61b3955cf712cadfc25635bf9bc174af030ea upstream Add the necessary logic for supporting the emulated VIRT_SPEC_CTRL MSR to x86_virt_spec_ctrl(). If either X86_FEATURE_LS_CFG_SSBD or X86_FEATURE_VIRT_SPEC_CTRL is set then use the new guest_virt_spec_ctrl argument to check whether the state must be modified on the host. The update reuses speculative_store_bypass_update() so the ZEN-specific sibling coordination can be reused. Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 71179d5dcbb96afc70c3344fd4b35db0c33d6008 Author: Thomas Gleixner Date: Sat May 12 20:10:00 2018 +0200 x86/bugs: Rework spec_ctrl base and mask logic commit be6fcb5478e95bb1c91f489121238deb3abca46a upstream x86_spec_ctrL_mask is intended to mask out bits from a MSR_SPEC_CTRL value which are not to be modified. However the implementation is not really used and the bitmask was inverted to make a check easier, which was removed in "x86/bugs: Remove x86_spec_ctrl_set()" Aside of that it is missing the STIBP bit if it is supported by the platform, so if the mask would be used in x86_virt_spec_ctrl() then it would prevent a guest from setting STIBP. Add the STIBP bit if supported and use the mask in x86_virt_spec_ctrl() to sanitize the value which is supplied by the guest. Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit d13f068b94a18b8d9fafaf2519fd1f43d4965f36 Author: Thomas Gleixner Date: Sat May 12 20:53:14 2018 +0200 x86/bugs: Remove x86_spec_ctrl_set() commit 4b59bdb569453a60b752b274ca61f009e37f4dae upstream x86_spec_ctrl_set() is only used in bugs.c and the extra mask checks there provide no real value as both call sites can just write x86_spec_ctrl_base to MSR_SPEC_CTRL. x86_spec_ctrl_base is valid and does not need any extra masking or checking. Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 987f49474b0680db37f9bfcecc8e563803c55f52 Author: Thomas Gleixner Date: Sat May 12 20:49:16 2018 +0200 x86/bugs: Expose x86_spec_ctrl_base directly commit fa8ac4988249c38476f6ad678a4848a736373403 upstream x86_spec_ctrl_base is the system wide default value for the SPEC_CTRL MSR. x86_spec_ctrl_get_default() returns x86_spec_ctrl_base and was intended to prevent modification to that variable. Though the variable is read only after init and globaly visible already. Remove the function and export the variable instead. Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 6befd3a735e0228b8128f2916309ed218d9c49dd Author: Borislav Petkov Date: Sat May 12 00:14:51 2018 +0200 x86/bugs: Unify x86_spec_ctrl_{set_guest,restore_host} commit cc69b34989210f067b2c51d5539b5f96ebcc3a01 upstream Function bodies are very similar and are going to grow more almost identical code. Add a bool arg to determine whether SPEC_CTRL is being set for the guest or restored to the host. No functional changes. Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 3e6ab4ca1345b8b7ff09ea00e0abffa276c6919c Author: Thomas Gleixner Date: Thu May 10 20:31:44 2018 +0200 x86/speculation: Rework speculative_store_bypass_update() commit 0270be3e34efb05a88bc4c422572ece038ef3608 upstream The upcoming support for the virtual SPEC_CTRL MSR on AMD needs to reuse speculative_store_bypass_update() to avoid code duplication. Add an argument for supplying a thread info (TIF) value and create a wrapper speculative_store_bypass_update_current() which is used at the existing call site. Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 8e1c285a050ca8bcbe30c47f102497e44319f12c Author: Tom Lendacky Date: Thu May 17 17:09:18 2018 +0200 x86/speculation: Add virtualized speculative store bypass disable support commit 11fb0683493b2da112cd64c9dada221b52463bf7 upstream Some AMD processors only support a non-architectural means of enabling speculative store bypass disable (SSBD). To allow a simplified view of this to a guest, an architectural definition has been created through a new CPUID bit, 0x80000008_EBX[25], and a new MSR, 0xc001011f. With this, a hypervisor can virtualize the existence of this definition and provide an architectural method for using SSBD to a guest. Add the new CPUID feature, the new MSR and update the existing SSBD support to use this MSR when present. Signed-off-by: Tom Lendacky Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 72f46c229ac286c0a734888f50a3af274036290f Author: Thomas Gleixner Date: Wed May 9 23:01:01 2018 +0200 x86/bugs, KVM: Extend speculation control for VIRT_SPEC_CTRL commit ccbcd2674472a978b48c91c1fbfb66c0ff959f24 upstream AMD is proposing a VIRT_SPEC_CTRL MSR to handle the Speculative Store Bypass Disable via MSR_AMD64_LS_CFG so that guests do not have to care about the bit position of the SSBD bit and thus facilitate migration. Also, the sibling coordination on Family 17H CPUs can only be done on the host. Extend x86_spec_ctrl_set_guest() and x86_spec_ctrl_restore_host() with an extra argument for the VIRT_SPEC_CTRL MSR. Hand in 0 from VMX and in SVM add a new virt_spec_ctrl member to the CPU data structure which is going to be used in later patches for the actual implementation. Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit b213ab46cde40368b793daac516be9218beaa750 Author: Thomas Gleixner Date: Wed May 9 21:53:09 2018 +0200 x86/speculation: Handle HT correctly on AMD commit 1f50ddb4f4189243c05926b842dc1a0332195f31 upstream The AMD64_LS_CFG MSR is a per core MSR on Family 17H CPUs. That means when hyperthreading is enabled the SSBD bit toggle needs to take both cores into account. Otherwise the following situation can happen: CPU0 CPU1 disable SSB disable SSB enable SSB <- Enables it for the Core, i.e. for CPU0 as well So after the SSB enable on CPU1 the task on CPU0 runs with SSB enabled again. On Intel the SSBD control is per core as well, but the synchronization logic is implemented behind the per thread SPEC_CTRL MSR. It works like this: CORE_SPEC_CTRL = THREAD0_SPEC_CTRL | THREAD1_SPEC_CTRL i.e. if one of the threads enables a mitigation then this affects both and the mitigation is only disabled in the core when both threads disabled it. Add the necessary synchronization logic for AMD family 17H. Unfortunately that requires a spinlock to serialize the access to the MSR, but the locks are only shared between siblings. Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 7f1efb5e74e3e1a01b73d3364d223f71044f5049 Author: Thomas Gleixner Date: Thu May 10 16:26:00 2018 +0200 x86/cpufeatures: Add FEATURE_ZEN commit d1035d971829dcf80e8686ccde26f94b0a069472 upstream Add a ZEN feature bit so family-dependent static_cpu_has() optimizations can be built for ZEN. Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit bbc0d1c335664660acc2c6e68901d350805a1ff1 Author: Thomas Gleixner Date: Thu May 10 20:21:36 2018 +0200 x86/cpufeatures: Disentangle SSBD enumeration commit 52817587e706686fcdb27f14c1b000c92f266c96 upstream The SSBD enumeration is similarly to the other bits magically shared between Intel and AMD though the mechanisms are different. Make X86_FEATURE_SSBD synthetic and set it depending on the vendor specific features or family dependent setup. Change the Intel bit to X86_FEATURE_SPEC_CTRL_SSBD to denote that SSBD is controlled via MSR_SPEC_CTRL and fix up the usage sites. Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 8e0836d1413b86ef6e85142c3902990815cf1cba Author: Thomas Gleixner Date: Thu May 10 19:13:18 2018 +0200 x86/cpufeatures: Disentangle MSR_SPEC_CTRL enumeration from IBRS commit 7eb8956a7fec3c1f0abc2a5517dada99ccc8a961 upstream The availability of the SPEC_CTRL MSR is enumerated by a CPUID bit on Intel and implied by IBRS or STIBP support on AMD. That's just confusing and in case an AMD CPU has IBRS not supported because the underlying problem has been fixed but has another bit valid in the SPEC_CTRL MSR, the thing falls apart. Add a synthetic feature bit X86_FEATURE_MSR_SPEC_CTRL to denote the availability on both Intel and AMD. While at it replace the boot_cpu_has() checks with static_cpu_has() where possible. This prevents late microcode loading from exposing SPEC_CTRL, but late loading is already very limited as it does not reevaluate the mitigation options and other bits and pieces. Having static_cpu_has() is the simplest and least fragile solution. Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit b1d1984f389865e655076ae18d4626b1a65ba82c Author: Borislav Petkov Date: Wed May 2 18:15:14 2018 +0200 x86/speculation: Use synthetic bits for IBRS/IBPB/STIBP commit e7c587da125291db39ddf1f49b18e5970adbac17 upstream Intel and AMD have different CPUID bits hence for those use synthetic bits which get set on the respective vendor's in init_speculation_control(). So that debacles like what the commit message of c65732e4f721 ("x86/cpu: Restore CPUID_8000_0008_EBX reload") talks about don't happen anymore. Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Reviewed-by: Konrad Rzeszutek Wilk Tested-by: Jörg Otte Cc: Linus Torvalds Cc: "Kirill A. Shutemov" Link: https://lkml.kernel.org/r/20180504161815.GG9257@pd.tnic Signed-off-by: Greg Kroah-Hartman commit b1a6028c23748afc3b970bf2a740a3ebc7424e12 Author: Thomas Gleixner Date: Fri May 11 15:21:01 2018 +0200 KVM: SVM: Move spec control call after restore of GS commit 15e6c22fd8e5a42c5ed6d487b7c9fe44c2517765 upstream svm_vcpu_run() invokes x86_spec_ctrl_restore_host() after VMEXIT, but before the host GS is restored. x86_spec_ctrl_restore_host() uses 'current' to determine the host SSBD state of the thread. 'current' is GS based, but host GS is not yet restored and the access causes a triple fault. Move the call after the host GS restore. Fixes: 885f82bfbc6f x86/process: Allow runtime control of Speculative Store Bypass Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Konrad Rzeszutek Wilk Acked-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit bd2059282934fc009d755d24527187df5fe448de Author: Jim Mattson Date: Sun May 13 17:33:57 2018 -0400 x86/cpu: Make alternative_msr_write work for 32-bit code commit 5f2b745f5e1304f438f9b2cd03ebc8120b6e0d3b upstream Cast val and (val >> 32) to (u32), so that they fit in a general-purpose register in both 32-bit and 64-bit code. [ tglx: Made it u32 instead of uintptr_t ] Fixes: c65732e4f721 ("x86/cpu: Restore CPUID_8000_0008_EBX reload") Signed-off-by: Jim Mattson Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Acked-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5a53a5fefb73c150d754907916188d0cf3fb36d8 Author: Konrad Rzeszutek Wilk Date: Fri May 11 16:50:35 2018 -0400 x86/bugs: Fix the parameters alignment and missing void commit ffed645e3be0e32f8e9ab068d257aee8d0fe8eec upstream Fixes: 7bb4d366c ("x86/bugs: Make cpu_show_common() static") Fixes: 24f7fc83b ("x86/bugs: Provide boot parameters for the spec_store_bypass_disable mitigation") Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit f69c4dd36766666077b96e30e7d0d1122642c00a Author: Jiri Kosina Date: Thu May 10 22:47:32 2018 +0200 x86/bugs: Make cpu_show_common() static commit 7bb4d366cba992904bffa4820d24e70a3de93e76 upstream cpu_show_common() is not used outside of arch/x86/kernel/cpu/bugs.c, so make it static. Signed-off-by: Jiri Kosina Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 4fbc01632e779977bbdcbb14877dcc80d7beeb0b Author: Jiri Kosina Date: Thu May 10 22:47:18 2018 +0200 x86/bugs: Fix __ssb_select_mitigation() return type commit d66d8ff3d21667b41eddbe86b35ab411e40d8c5f upstream __ssb_select_mitigation() returns one of the members of enum ssb_mitigation, not ssb_mitigation_cmd; fix the prototype to reflect that. Fixes: 24f7fc83b9204 ("x86/bugs: Provide boot parameters for the spec_store_bypass_disable mitigation") Signed-off-by: Jiri Kosina Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 8dc742f930ccbb6b41d538bb35b81693cd8bad43 Author: Borislav Petkov Date: Tue May 8 15:43:45 2018 +0200 Documentation/spec_ctrl: Do some minor cleanups commit dd0792699c4058e63c0715d9a7c2d40226fcdddc upstream Fix some typos, improve formulations, end sentences with a fullstop. Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 43c47eb2a274fa12029ac5485ae4360048a398af Author: Konrad Rzeszutek Wilk Date: Wed May 9 21:41:38 2018 +0200 proc: Use underscores for SSBD in 'status' commit e96f46ee8587607a828f783daa6eb5b44d25004d upstream The style for the 'status' file is CamelCase or this. _. Fixes: fae1fa0fc ("proc: Provide details on speculation flaw mitigations") Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 89ba80e61a395afc40a865d008931c576d20724d Author: Konrad Rzeszutek Wilk Date: Wed May 9 21:41:38 2018 +0200 x86/bugs: Rename _RDS to _SSBD commit 9f65fb29374ee37856dbad847b4e121aab72b510 upstream Intel collateral will reference the SSB mitigation bit in IA32_SPEC_CTL[2] as SSBD (Speculative Store Bypass Disable). Hence changing it. It is unclear yet what the MSR_IA32_ARCH_CAPABILITIES (0x10a) Bit(4) name is going to be. Following the rename it would be SSBD_NO but that rolls out to Speculative Store Bypass Disable No. Also fixed the missing space in X86_FEATURE_AMD_SSBD. [ tglx: Fixup x86_amd_rds_enable() and rds_tif_to_amd_ls_cfg() as well ] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 0f18f44ce076e48d25c1b03e15f3b588ba0f9df1 Author: Kees Cook Date: Thu May 3 14:37:54 2018 -0700 x86/speculation: Make "seccomp" the default mode for Speculative Store Bypass commit f21b53b20c754021935ea43364dbf53778eeba32 upstream Unless explicitly opted out of, anything running under seccomp will have SSB mitigations enabled. Choosing the "prctl" mode will disable this. [ tglx: Adjusted it to the new arch_seccomp_spec_mitigate() mechanism ] Signed-off-by: Kees Cook Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 61dfdc12ff35cd6f196a543271174ae611e36fb1 Author: Thomas Gleixner Date: Fri May 4 15:12:06 2018 +0200 seccomp: Move speculation migitation control to arch code commit 8bf37d8c067bb7eb8e7c381bdadf9bd89182b6bc upstream The migitation control is simpler to implement in architecture code as it avoids the extra function call to check the mode. Aside of that having an explicit seccomp enabled mode in the architecture mitigations would require even more workarounds. Move it into architecture code and provide a weak function in the seccomp code. Remove the 'which' argument as this allows the architecture to decide which mitigations are relevant for seccomp. Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 9939db75cd5b686ca43c4aa26e24d6b73ffa66e0 Author: Kees Cook Date: Thu May 3 14:56:12 2018 -0700 seccomp: Add filter flag to opt-out of SSB mitigation commit 00a02d0c502a06d15e07b857f8ff921e3e402675 upstream If a seccomp user is not interested in Speculative Store Bypass mitigation by default, it can set the new SECCOMP_FILTER_FLAG_SPEC_ALLOW flag when adding filters. Signed-off-by: Kees Cook Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit d829fcceb8f532966bfb07fb67cb968374fcbbd2 Author: Thomas Gleixner Date: Fri May 4 09:40:03 2018 +0200 seccomp: Use PR_SPEC_FORCE_DISABLE commit b849a812f7eb92e96d1c8239b06581b2cfd8b275 upstream Use PR_SPEC_FORCE_DISABLE in seccomp() because seccomp does not allow to widen restrictions. Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 20d036a2e223a5c4327bcf432ef995f59f51d1d1 Author: Thomas Gleixner Date: Thu May 3 22:09:15 2018 +0200 prctl: Add force disable speculation commit 356e4bfff2c5489e016fdb925adbf12a1e3950ee upstream For certain use cases it is desired to enforce mitigations so they cannot be undone afterwards. That's important for loader stubs which want to prevent a child from disabling the mitigation again. Will also be used for seccomp(). The extra state preserving of the prctl state for SSB is a preparatory step for EBPF dymanic speculation control. Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit c024722ffecd484fcb35ad61e822c214b6913196 Author: Kees Cook Date: Thu May 3 15:03:30 2018 -0700 x86/bugs: Make boot modes __ro_after_init commit f9544b2b076ca90d887c5ae5d74fab4c21bb7c13 upstream There's no reason for these to be changed after boot. Signed-off-by: Kees Cook Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 87895ae1e9b22a04441992921b79b6d32e22142a Author: Kees Cook Date: Tue May 1 15:07:31 2018 -0700 seccomp: Enable speculation flaw mitigations commit 5c3070890d06ff82eecb808d02d2ca39169533ef upstream When speculation flaw mitigations are opt-in (via prctl), using seccomp will automatically opt-in to these protections, since using seccomp indicates at least some level of sandboxing is desired. Signed-off-by: Kees Cook Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit dd88d569eeff59a03b897ba0168547a465091aca Author: Kees Cook Date: Tue May 1 15:31:45 2018 -0700 proc: Provide details on speculation flaw mitigations commit fae1fa0fc6cca8beee3ab8ed71d54f9a78fa3f64 upstream As done with seccomp and no_new_privs, also show speculation flaw mitigation state in /proc/$pid/status. Signed-off-by: Kees Cook Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 7d1254a1489c4ecc23a6afdfd1a17bdbb4cd186d Author: Kees Cook Date: Tue May 1 15:19:04 2018 -0700 nospec: Allow getting/setting on non-current task commit 7bbf1373e228840bb0295a2ca26d548ef37f448e upstream Adjust arch_prctl_get/set_spec_ctrl() to operate on tasks other than current. This is needed both for /proc/$pid/status queries and for seccomp (since thread-syncing can trigger seccomp in non-current threads). Signed-off-by: Kees Cook Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit d8553911627ab1d9789d08c9902f5e43194f99f7 Author: Thomas Gleixner Date: Sun Apr 29 15:26:40 2018 +0200 x86/speculation: Add prctl for Speculative Store Bypass mitigation commit a73ec77ee17ec556fe7f165d00314cb7c047b1ac upstream Add prctl based control for Speculative Store Bypass mitigation and make it the default mitigation for Intel and AMD. Andi Kleen provided the following rationale (slightly redacted): There are multiple levels of impact of Speculative Store Bypass: 1) JITed sandbox. It cannot invoke system calls, but can do PRIME+PROBE and may have call interfaces to other code 2) Native code process. No protection inside the process at this level. 3) Kernel. 4) Between processes. The prctl tries to protect against case (1) doing attacks. If the untrusted code can do random system calls then control is already lost in a much worse way. So there needs to be system call protection in some way (using a JIT not allowing them or seccomp). Or rather if the process can subvert its environment somehow to do the prctl it can already execute arbitrary code, which is much worse than SSB. To put it differently, the point of the prctl is to not allow JITed code to read data it shouldn't read from its JITed sandbox. If it already has escaped its sandbox then it can already read everything it wants in its address space, and do much worse. The ability to control Speculative Store Bypass allows to enable the protection selectively without affecting overall system performance. Based on an initial patch from Tim Chen. Completely rewritten. Signed-off-by: Thomas Gleixner Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 704609d396801c86bca6dcdb14676489dd623da5 Author: Thomas Gleixner Date: Sun Apr 29 15:21:42 2018 +0200 x86/process: Allow runtime control of Speculative Store Bypass commit 885f82bfbc6fefb6664ea27965c3ab9ac4194b8c upstream The Speculative Store Bypass vulnerability can be mitigated with the Reduced Data Speculation (RDS) feature. To allow finer grained control of this eventually expensive mitigation a per task mitigation control is required. Add a new TIF_RDS flag and put it into the group of TIF flags which are evaluated for mismatch in switch_to(). If these bits differ in the previous and the next task, then the slow path function __switch_to_xtra() is invoked. Implement the TIF_RDS dependent mitigation control in the slow path. If the prctl for controlling Speculative Store Bypass is disabled or no task uses the prctl then there is no overhead in the switch_to() fast path. Update the KVM related speculation control functions to take TID_RDS into account as well. Based on a patch from Tim Chen. Completely rewritten. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 33f6a06810cb3f3f0ba20914db334c7c4855ba80 Author: Thomas Gleixner Date: Sun Apr 29 15:20:11 2018 +0200 prctl: Add speculation control prctls commit b617cfc858161140d69cc0b5cc211996b557a1c7 upstream Add two new prctls to control aspects of speculation related vulnerabilites and their mitigations to provide finer grained control over performance impacting mitigations. PR_GET_SPECULATION_CTRL returns the state of the speculation misfeature which is selected with arg2 of prctl(2). The return value uses bit 0-2 with the following meaning: Bit Define Description 0 PR_SPEC_PRCTL Mitigation can be controlled per task by PR_SET_SPECULATION_CTRL 1 PR_SPEC_ENABLE The speculation feature is enabled, mitigation is disabled 2 PR_SPEC_DISABLE The speculation feature is disabled, mitigation is enabled If all bits are 0 the CPU is not affected by the speculation misfeature. If PR_SPEC_PRCTL is set, then the per task control of the mitigation is available. If not set, prctl(PR_SET_SPECULATION_CTRL) for the speculation misfeature will fail. PR_SET_SPECULATION_CTRL allows to control the speculation misfeature, which is selected by arg2 of prctl(2) per task. arg3 is used to hand in the control value, i.e. either PR_SPEC_ENABLE or PR_SPEC_DISABLE. The common return values are: EINVAL prctl is not implemented by the architecture or the unused prctl() arguments are not 0 ENODEV arg2 is selecting a not supported speculation misfeature PR_SET_SPECULATION_CTRL has these additional return values: ERANGE arg3 is incorrect, i.e. it's not either PR_SPEC_ENABLE or PR_SPEC_DISABLE ENXIO prctl control of the selected speculation misfeature is disabled The first supported controlable speculation misfeature is PR_SPEC_STORE_BYPASS. Add the define so this can be shared between architectures. Based on an initial patch from Tim Chen and mostly rewritten. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 81c3c2b5917af382a90d116a5ccd034fe5d32c2a Author: Thomas Gleixner Date: Sun Apr 29 15:01:37 2018 +0200 x86/speculation: Create spec-ctrl.h to avoid include hell commit 28a2775217b17208811fa43a9e96bd1fdf417b86 upstream Having everything in nospec-branch.h creates a hell of dependencies when adding the prctl based switching mechanism. Move everything which is not required in nospec-branch.h to spec-ctrl.h and fix up the includes in the relevant files. Signed-off-by: Thomas Gleixner Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 97224b3da69810155b44f173cc8959eea565a98d Author: Konrad Rzeszutek Wilk Date: Wed Apr 25 22:04:25 2018 -0400 x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest commit da39556f66f5cfe8f9c989206974f1cb16ca5d7c upstream Expose the CPUID.7.EDX[31] bit to the guest, and also guard against various combinations of SPEC_CTRL MSR values. The handling of the MSR (to take into account the host value of SPEC_CTRL Bit(2)) is taken care of in patch: KVM/SVM/VMX/x86/spectre_v2: Support the combination of guest and host IBRS Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 716bfae3b3f40de8c0a6ae83f199d96fd152b3cc Author: Konrad Rzeszutek Wilk Date: Wed Apr 25 22:04:24 2018 -0400 x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested commit 764f3c21588a059cd783c6ba0734d4db2d72822d upstream AMD does not need the Speculative Store Bypass mitigation to be enabled. The parameters for this are already available and can be done via MSR C001_1020. Each family uses a different bit in that MSR for this. [ tglx: Expose the bit mask via a variable and move the actual MSR fiddling into the bugs code as that's the right thing to do and also required to prepare for dynamic enable/disable ] Suggested-by: Borislav Petkov Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit fa2f1c65246d956106fa964cf0ed953162af88e5 Author: Konrad Rzeszutek Wilk Date: Wed Apr 25 22:04:23 2018 -0400 x86/bugs: Whitelist allowed SPEC_CTRL MSR values commit 1115a859f33276fe8afb31c60cf9d8e657872558 upstream Intel and AMD SPEC_CTRL (0x48) MSR semantics may differ in the future (or in fact use different MSRs for the same functionality). As such a run-time mechanism is required to whitelist the appropriate MSR values. [ tglx: Made the variable __ro_after_init ] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 128e69909f7c245765f75d7f350dd67eb8fe8a7b Author: Konrad Rzeszutek Wilk Date: Wed Apr 25 22:04:22 2018 -0400 x86/bugs/intel: Set proper CPU features and setup RDS commit 772439717dbf703b39990be58d8d4e3e4ad0598a upstream Intel CPUs expose methods to: - Detect whether RDS capability is available via CPUID.7.0.EDX[31], - The SPEC_CTRL MSR(0x48), bit 2 set to enable RDS. - MSR_IA32_ARCH_CAPABILITIES, Bit(4) no need to enable RRS. With that in mind if spec_store_bypass_disable=[auto,on] is selected set at boot-time the SPEC_CTRL MSR to enable RDS if the platform requires it. Note that this does not fix the KVM case where the SPEC_CTRL is exposed to guests which can muck with it, see patch titled : KVM/SVM/VMX/x86/spectre_v2: Support the combination of guest and host IBRS. And for the firmware (IBRS to be set), see patch titled: x86/spectre_v2: Read SPEC_CTRL MSR during boot and re-use reserved bits [ tglx: Distangled it from the intel implementation and kept the call order ] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 65f747a6b1089f13e80b0b2e0c4128e72d135a70 Author: Konrad Rzeszutek Wilk Date: Wed Apr 25 22:04:21 2018 -0400 x86/bugs: Provide boot parameters for the spec_store_bypass_disable mitigation commit 24f7fc83b9204d20f878c57cb77d261ae825e033 upstream Contemporary high performance processors use a common industry-wide optimization known as "Speculative Store Bypass" in which loads from addresses to which a recent store has occurred may (speculatively) see an older value. Intel refers to this feature as "Memory Disambiguation" which is part of their "Smart Memory Access" capability. Memory Disambiguation can expose a cache side-channel attack against such speculatively read values. An attacker can create exploit code that allows them to read memory outside of a sandbox environment (for example, malicious JavaScript in a web page), or to perform more complex attacks against code running within the same privilege level, e.g. via the stack. As a first step to mitigate against such attacks, provide two boot command line control knobs: nospec_store_bypass_disable spec_store_bypass_disable=[off,auto,on] By default affected x86 processors will power on with Speculative Store Bypass enabled. Hence the provided kernel parameters are written from the point of view of whether to enable a mitigation or not. The parameters are as follows: - auto - Kernel detects whether your CPU model contains an implementation of Speculative Store Bypass and picks the most appropriate mitigation. - on - disable Speculative Store Bypass - off - enable Speculative Store Bypass [ tglx: Reordered the checks so that the whole evaluation is not done when the CPU does not support RDS ] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 832b579e1e83f17e14a8c054ccc768eaf5e80269 Author: Konrad Rzeszutek Wilk Date: Sat Apr 28 22:34:17 2018 +0200 x86/cpufeatures: Add X86_FEATURE_RDS commit 0cc5fa00b0a88dad140b4e5c2cead9951ad36822 upstream Add the CPU feature bit CPUID.7.0.EDX[31] which indicates whether the CPU supports Reduced Data Speculation. [ tglx: Split it out from a later patch ] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c6dc89dd04e3adfb713c40c20817a8791a8deda6 Author: Konrad Rzeszutek Wilk Date: Wed Apr 25 22:04:20 2018 -0400 x86/bugs: Expose /sys/../spec_store_bypass commit c456442cd3a59eeb1d60293c26cbe2ff2c4e42cf upstream Add the sysfs file for the new vulerability. It does not do much except show the words 'Vulnerable' for recent x86 cores. Intel cores prior to family 6 are known not to be vulnerable, and so are some Atoms and some Xeon Phi. It assumes that older Cyrix, Centaur, etc. cores are immune. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 94ae9d26284369da199dfb2581fe0b7ea66f7733 Author: Konrad Rzeszutek Wilk Date: Wed Apr 25 22:04:19 2018 -0400 x86/bugs, KVM: Support the combination of guest and host IBRS commit 5cf687548705412da47c9cec342fd952d71ed3d5 upstream A guest may modify the SPEC_CTRL MSR from the value used by the kernel. Since the kernel doesn't use IBRS, this means a value of zero is what is needed in the host. But the 336996-Speculative-Execution-Side-Channel-Mitigations.pdf refers to the other bits as reserved so the kernel should respect the boot time SPEC_CTRL value and use that. This allows to deal with future extensions to the SPEC_CTRL interface if any at all. Note: This uses wrmsrl() instead of native_wrmsl(). I does not make any difference as paravirt will over-write the callq *0xfff.. with the wrmsrl assembler code. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7c9b4959cda48f22ecd6ceb88bda7f939f2016b3 Author: Konrad Rzeszutek Wilk Date: Wed Apr 25 22:04:18 2018 -0400 x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits commit 1b86883ccb8d5d9506529d42dbe1a5257cb30b18 upstream The 336996-Speculative-Execution-Side-Channel-Mitigations.pdf refers to all the other bits as reserved. The Intel SDM glossary defines reserved as implementation specific - aka unknown. As such at bootup this must be taken it into account and proper masking for the bits in use applied. A copy of this document is available at https://bugzilla.kernel.org/show_bug.cgi?id=199511 [ tglx: Made x86_spec_ctrl_base __ro_after_init ] Suggested-by: Jon Masters Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 3ce1634f6165ba638546bf83123f1e5c51b1afcd Author: Konrad Rzeszutek Wilk Date: Wed Apr 25 22:04:17 2018 -0400 x86/bugs: Concentrate bug reporting into a separate function commit d1059518b4789cabe34bb4b714d07e6089c82ca1 upstream Those SysFS functions have a similar preamble, as such make common code to handle them. Suggested-by: Borislav Petkov Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 69dc73805969ea919786c56d18e5a51fb8c128f2 Author: Konrad Rzeszutek Wilk Date: Wed Apr 25 22:04:16 2018 -0400 x86/bugs: Concentrate bug detection into a separate function commit 4a28bfe3267b68e22c663ac26185aa16c9b879ef upstream Combine the various logic which goes through all those x86_cpu_id matching structures in one function. Suggested-by: Borislav Petkov Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 8410540f5aaf06ab01197443371be89822971e58 Author: Linus Torvalds Date: Tue May 1 15:55:51 2018 +0200 x86/nospec: Simplify alternative_msr_write() commit 1aa7a5735a41418d8e01fa7c9565eb2657e2ea3f upstream The macro is not type safe and I did look for why that "g" constraint for the asm doesn't work: it's because the asm is more fundamentally wrong. It does movl %[val], %%eax but "val" isn't a 32-bit value, so then gcc will pass it in a register, and generate code like movl %rsi, %eax and gas will complain about a nonsensical 'mov' instruction (it's moving a 64-bit register to a 32-bit one). Passing it through memory will just hide the real bug - gcc still thinks the memory location is 64-bit, but the "movl" will only load the first 32 bits and it all happens to work because x86 is little-endian. Convert it to a type safe inline function with a little trick which hands the feature into the ALTERNATIVE macro. Signed-off-by: Linus Torvalds Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 671c9a69f426d55b95af0e12838bf07f0a164a89 Author: Liu Bo Date: Wed May 16 01:37:36 2018 +0800 btrfs: fix reading stale metadata blocks after degraded raid1 mounts commit 02a3307aa9c20b4f6626255b028f07f6cfa16feb upstream. If a btree block, aka. extent buffer, is not available in the extent buffer cache, it'll be read out from the disk instead, i.e. btrfs_search_slot() read_block_for_search() # hold parent and its lock, go to read child btrfs_release_path() read_tree_block() # read child Unfortunately, the parent lock got released before reading child, so commit 5bdd3536cbbe ("Btrfs: Fix block generation verification race") had used 0 as parent transid to read the child block. It forces read_tree_block() not to check if parent transid is different with the generation id of the child that it reads out from disk. A simple PoC is included in btrfs/124, 0. A two-disk raid1 btrfs, 1. Right after mkfs.btrfs, block A is allocated to be device tree's root. 2. Mount this filesystem and put it in use, after a while, device tree's root got COW but block A hasn't been allocated/overwritten yet. 3. Umount it and reload the btrfs module to remove both disks from the global @fs_devices list. 4. mount -odegraded dev1 and write some data, so now block A is allocated to be a leaf in checksum tree. Note that only dev1 has the latest metadata of this filesystem. 5. Umount it and mount it again normally (with both disks), since raid1 can pick up one disk by the writer task's pid, if btrfs_search_slot() needs to read block A, dev2 which does NOT have the latest metadata might be read for block A, then we got a stale block A. 6. As parent transid is not checked, block A is marked as uptodate and put into the extent buffer cache, so the future search won't bother to read disk again, which means it'll make changes on this stale one and make it dirty and flush it onto disk. To avoid the problem, parent transid needs to be passed to read_tree_block(). In order to get a valid parent transid, we need to hold the parent's lock until finishing reading child. This patch needs to be slightly adapted for stable kernels, the &first_key parameter added to read_tree_block() is from 4.16+ (581c1760415c4). The fix is to replace 0 by 'gen'. Fixes: 5bdd3536cbbe ("Btrfs: Fix block generation verification race") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Liu Bo Reviewed-by: Filipe Manana Reviewed-by: Qu Wenruo [ update changelog ] Signed-off-by: David Sterba Signed-off-by: Nikolay Borisov Signed-off-by: Greg Kroah-Hartman commit 7ea5cff55c45e14f8e33e4e143e99497278f6a8d Author: Nikolay Borisov Date: Fri Apr 27 12:21:53 2018 +0300 btrfs: Fix delalloc inodes invalidation during transaction abort commit fe816d0f1d4c31c4c31d42ca78a87660565fc800 upstream. When a transaction is aborted btrfs_cleanup_transaction is called to cleanup all the various in-flight bits and pieces which migth be active. One of those is delalloc inodes - inodes which have dirty pages which haven't been persisted yet. Currently the process of freeing such delalloc inodes in exceptional circumstances such as transaction abort boiled down to calling btrfs_invalidate_inodes whose sole job is to invalidate the dentries for all inodes related to a root. This is in fact wrong and insufficient since such delalloc inodes will likely have pending pages or ordered-extents and will be linked to the sb->s_inode_list. This means that unmounting a btrfs instance with an aborted transaction could potentially lead inodes/their pages visible to the system long after their superblock has been freed. This in turn leads to a "use-after-free" situation once page shrink is triggered. This situation could be simulated by running generic/019 which would cause such inodes to be left hanging, followed by generic/176 which causes memory pressure and page eviction which lead to touching the freed super block instance. This situation is additionally detected by the unmount code of VFS with the following message: "VFS: Busy inodes after unmount of Self-destruct in 5 seconds. Have a nice day..." Additionally btrfs hits WARN_ON(!RB_EMPTY_ROOT(&root->inode_tree)); in free_fs_root for the same reason. This patch aims to rectify the sitaution by doing the following: 1. Change btrfs_destroy_delalloc_inodes so that it calls invalidate_inode_pages2 for every inode on the delalloc list, this ensures that all the pages of the inode are released. This function boils down to calling btrfs_releasepage. During test I observed cases where inodes on the delalloc list were having an i_count of 0, so this necessitates using igrab to be sure we are working on a non-freed inode. 2. Since calling btrfs_releasepage might queue delayed iputs move the call out to btrfs_cleanup_transaction in btrfs_error_commit_super before calling run_delayed_iputs for the last time. This is necessary to ensure that delayed iputs are run. Note: this patch is tagged for 4.14 stable but the fix applies to older versions too but needs to be backported manually due to conflicts. CC: stable@vger.kernel.org # 4.14.x: 2b8773313494: btrfs: Split btrfs_del_delalloc_inode into 2 functions CC: stable@vger.kernel.org # 4.14.x Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba [ add comment to igrab ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 0d670384af3cf655cd3ddf3c7b48a239b449138f Author: Nikolay Borisov Date: Fri Apr 27 12:21:51 2018 +0300 btrfs: Split btrfs_del_delalloc_inode into 2 functions commit 2b8773313494ede83a26fb372466e634564002ed upstream. This is in preparation of fixing delalloc inodes leakage on transaction abort. Also export the new function. Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Reviewed-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 1d16f615bb7d1742e1616dcbdcc4c7d5d1e5a5a5 Author: Anand Jain Date: Thu May 17 15:16:51 2018 +0800 btrfs: fix crash when trying to resume balance without the resume flag commit 02ee654d3a04563c67bfe658a05384548b9bb105 upstream. We set the BTRFS_BALANCE_RESUME flag in the btrfs_recover_balance() only, which isn't called during the remount. So when resuming from the paused balance we hit the bug: kernel: kernel BUG at fs/btrfs/volumes.c:3890! :: kernel: balance_kthread+0x51/0x60 [btrfs] kernel: kthread+0x111/0x130 :: kernel: RIP: btrfs_balance+0x12e1/0x1570 [btrfs] RSP: ffffba7d0090bde8 Reproducer: On a mounted filesystem: btrfs balance start --full-balance /btrfs btrfs balance pause /btrfs mount -o remount,ro /dev/sdb /btrfs mount -o remount,rw /dev/sdb /btrfs To fix this set the BTRFS_BALANCE_RESUME flag in btrfs_resume_balance_async(). CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f9b02febeabf687bae3861d0af80fb61cfa94683 Author: Misono Tomohiro Date: Tue May 15 16:51:26 2018 +0900 btrfs: property: Set incompat flag if lzo/zstd compression is set commit 1a63c198ddb810c790101d693c7071cca703b3c7 upstream. Incompat flag of LZO/ZSTD compression should be set at: 1. mount time (-o compress/compress-force) 2. when defrag is done 3. when property is set Currently 3. is missing and this commit adds this. This could lead to a filesystem that uses ZSTD but is not marked as such. If a kernel without a ZSTD support encounteres a ZSTD compressed extent, it will handle that but this could be confusing to the user. Typically the filesystem is mounted with the ZSTD option, but the discrepancy can arise when a filesystem is never mounted with ZSTD and then the property on some file is set (and some new extents are written). A simple mount with -o compress=zstd will fix that up on an unpatched kernel. Same goes for LZO, but this has been around for a very long time (2.6.37) so it's unlikely that a pre-LZO kernel would be used. Fixes: 5c1aab1dd544 ("btrfs: Add zstd support") CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Tomohiro Misono Reviewed-by: Anand Jain Reviewed-by: David Sterba [ add user visible impact ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit de1f96cc4a30194c5869ca52f74733747558f13e Author: Robbie Ko Date: Mon May 14 10:51:34 2018 +0800 Btrfs: send, fix invalid access to commit roots due to concurrent snapshotting commit 6f2f0b394b54e2b159ef969a0b5274e9bbf82ff2 upstream. [BUG] btrfs incremental send BUG happens when creating a snapshot of snapshot that is being used by send. [REASON] The problem can happen if while we are doing a send one of the snapshots used (parent or send) is snapshotted, because snapshoting implies COWing the root of the source subvolume/snapshot. 1. When doing an incremental send, the send process will get the commit roots from the parent and send snapshots, and add references to them through extent_buffer_get(). 2. When a snapshot/subvolume is snapshotted, its root node is COWed (transaction.c:create_pending_snapshot()). 3. COWing releases the space used by the node immediately, through: __btrfs_cow_block() --btrfs_free_tree_block() ----btrfs_add_free_space(bytenr of node) 4. Because send doesn't hold a transaction open, it's possible that the transaction used to create the snapshot commits, switches the commit root and the old space used by the previous root node gets assigned to some other node allocation. Allocation of a new node will use the existing extent buffer found in memory, which we previously got a reference through extent_buffer_get(), and allow the extent buffer's content (pages) to be modified: btrfs_alloc_tree_block --btrfs_reserve_extent ----find_free_extent (get bytenr of old node) --btrfs_init_new_buffer (use bytenr of old node) ----btrfs_find_create_tree_block ------alloc_extent_buffer --------find_extent_buffer (get old node) 5. So send can access invalid memory content and have unpredictable behaviour. [FIX] So we fix the problem by copying the commit roots of the send and parent snapshots and use those copies. CallTrace looks like this: ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:1861! invalid opcode: 0000 [#1] SMP CPU: 6 PID: 24235 Comm: btrfs Tainted: P O 3.10.105 #23721 ffff88046652d680 ti: ffff88041b720000 task.ti: ffff88041b720000 RIP: 0010:[] read_node_slot+0x108/0x110 [btrfs] RSP: 0018:ffff88041b723b68 EFLAGS: 00010246 RAX: ffff88043ca6b000 RBX: ffff88041b723c50 RCX: ffff880000000000 RDX: 000000000000004c RSI: ffff880314b133f8 RDI: ffff880458b24000 RBP: 0000000000000000 R08: 0000000000000001 R09: ffff88041b723c66 R10: 0000000000000001 R11: 0000000000001000 R12: ffff8803f3e48890 R13: ffff8803f3e48880 R14: ffff880466351800 R15: 0000000000000001 FS: 00007f8c321dc8c0(0000) GS:ffff88047fcc0000(0000) CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 R2: 00007efd1006d000 CR3: 0000000213a24000 CR4: 00000000003407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: ffff88041b723c50 ffff8803f3e48880 ffff8803f3e48890 ffff8803f3e48880 ffff880466351800 0000000000000001 ffffffffa08dd9d7 ffff88041b723c50 ffff8803f3e48880 ffff88041b723c66 ffffffffa08dde85 a9ff88042d2c4400 Call Trace: [] ? tree_move_down.isra.33+0x27/0x50 [btrfs] [] ? tree_advance+0xb5/0xc0 [btrfs] [] ? btrfs_compare_trees+0x2d4/0x760 [btrfs] [] ? finish_inode_if_needed+0x870/0x870 [btrfs] [] ? btrfs_ioctl_send+0xeda/0x1050 [btrfs] [] ? btrfs_ioctl+0x1e3d/0x33f0 [btrfs] [] ? handle_pte_fault+0x373/0x990 [] ? atomic_notifier_call_chain+0x16/0x20 [] ? set_task_cpu+0xb6/0x1d0 [] ? handle_mm_fault+0x143/0x2a0 [] ? __do_page_fault+0x1d0/0x500 [] ? check_preempt_curr+0x57/0x90 [] ? do_vfs_ioctl+0x4aa/0x990 [] ? do_fork+0x113/0x3b0 [] ? trace_hardirqs_off_thunk+0x3a/0x6c [] ? SyS_ioctl+0x88/0xa0 [] ? system_call_fastpath+0x16/0x1b ---[ end trace 29576629ee80b2e1 ]--- Fixes: 7069830a9e38 ("Btrfs: add btrfs_compare_trees function") CC: stable@vger.kernel.org # 3.6+ Signed-off-by: Robbie Ko Reviewed-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 59bbb5ca4d95c2a6ab6ae69ed077f022e2678e9c Author: Filipe Manana Date: Fri May 11 16:42:42 2018 +0100 Btrfs: fix xattr loss after power failure commit 9a8fca62aacc1599fea8e813d01e1955513e4fad upstream. If a file has xattrs, we fsync it, to ensure we clear the flags BTRFS_INODE_NEEDS_FULL_SYNC and BTRFS_INODE_COPY_EVERYTHING from its inode, the current transaction commits and then we fsync it (without either of those bits being set in its inode), we end up not logging all its xattrs. This results in deleting all xattrs when replying the log after a power failure. Trivial reproducer $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ touch /mnt/foobar $ setfattr -n user.xa -v qwerty /mnt/foobar $ xfs_io -c "fsync" /mnt/foobar $ sync $ xfs_io -c "pwrite -S 0xab 0 64K" /mnt/foobar $ xfs_io -c "fsync" /mnt/foobar $ mount /dev/sdb /mnt $ getfattr --absolute-names --dump /mnt/foobar $ So fix this by making sure all xattrs are logged if we log a file's inode item and neither the flags BTRFS_INODE_NEEDS_FULL_SYNC nor BTRFS_INODE_COPY_EVERYTHING were set in the inode. Fixes: 36283bf777d9 ("Btrfs: fix fsync xattr loss in the fast fsync path") Cc: # 4.2+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit ca477b42aeaa8fcbd109bdc09f68e62bd9c9a432 Author: Masami Hiramatsu Date: Sun May 13 05:04:29 2018 +0100 ARM: 8772/1: kprobes: Prohibit kprobes on get_user functions commit 0d73c3f8e7f6ee2aab1bb350f60c180f5ae21a2c upstream. Since do_undefinstr() uses get_user to get the undefined instruction, it can be called before kprobes processes recursive check. This can cause an infinit recursive exception. Prohibit probing on get_user functions. Fixes: 24ba613c9d6c ("ARM kprobes: core code") Signed-off-by: Masami Hiramatsu Cc: stable@vger.kernel.org Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit bd4aeb75dab5ac3658ea981922fa1dc16708c823 Author: Masami Hiramatsu Date: Sun May 13 05:04:10 2018 +0100 ARM: 8770/1: kprobes: Prohibit probing on optimized_callback commit 70948c05fdde0aac32f9667856a88725c192fa40 upstream. Prohibit probing on optimized_callback() because it is called from kprobes itself. If we put a kprobes on it, that will cause a recursive call loop. Mark it NOKPROBE_SYMBOL. Fixes: 0dc016dbd820 ("ARM: kprobes: enable OPTPROBES for ARM 32") Signed-off-by: Masami Hiramatsu Cc: stable@vger.kernel.org Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 14b4cfb5ab54a0a59d0c797751f6a58191404597 Author: Masami Hiramatsu Date: Sun May 13 05:03:54 2018 +0100 ARM: 8769/1: kprobes: Fix to use get_kprobe_ctlblk after irq-disabed commit 69af7e23a6870df2ea6fa79ca16493d59b3eebeb upstream. Since get_kprobe_ctlblk() uses smp_processor_id() to access per-cpu variable, it hits smp_processor_id sanity check as below. [ 7.006928] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 7.007859] caller is debug_smp_processor_id+0x20/0x24 [ 7.008438] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc1-00192-g4eb17253e4b5 #1 [ 7.008890] Hardware name: Generic DT based system [ 7.009917] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 7.010473] [] (show_stack) from [] (dump_stack+0x84/0x98) [ 7.010990] [] (dump_stack) from [] (check_preemption_disabled+0x138/0x13c) [ 7.011592] [] (check_preemption_disabled) from [] (debug_smp_processor_id+0x20/0x24) [ 7.012214] [] (debug_smp_processor_id) from [] (optimized_callback+0x2c/0xe4) [ 7.013077] [] (optimized_callback) from [] (0xbf0021b0) To fix this issue, call get_kprobe_ctlblk() right after irq-disabled since that disables preemption. Fixes: 0dc016dbd820 ("ARM: kprobes: enable OPTPROBES for ARM 32") Signed-off-by: Masami Hiramatsu Cc: stable@vger.kernel.org Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 6986750cb57c1805a5049f3e7e1b50527395a153 Author: Dexuan Cui Date: Tue May 15 19:52:50 2018 +0000 tick/broadcast: Use for_each_cpu() specially on UP kernels commit 5596fe34495cf0f645f417eb928ef224df3e3cb4 upstream. for_each_cpu() unintuitively reports CPU0 as set independent of the actual cpumask content on UP kernels. This causes an unexpected PIT interrupt storm on a UP kernel running in an SMP virtual machine on Hyper-V, and as a result, the virtual machine can suffer from a strange random delay of 1~20 minutes during boot-up, and sometimes it can hang forever. Protect if by checking whether the cpumask is empty before entering the for_each_cpu() loop. [ tglx: Use !IS_ENABLED(CONFIG_SMP) instead of #ifdeffery ] Signed-off-by: Dexuan Cui Signed-off-by: Thomas Gleixner Cc: Josh Poulson Cc: "Michael Kelley (EOSG)" Cc: Peter Zijlstra Cc: Frederic Weisbecker Cc: stable@vger.kernel.org Cc: Rakib Mullick Cc: Jork Loeser Cc: Greg Kroah-Hartman Cc: Andrew Morton Cc: KY Srinivasan Cc: Linus Torvalds Cc: Alexey Dobriyan Cc: Dmitry Vyukov Link: https://lkml.kernel.org/r/KL1P15301MB000678289FE55BA365B3279ABF990@KL1P15301MB0006.APCP153.PROD.OUTLOOK.COM Link: https://lkml.kernel.org/r/KL1P15301MB0006FA63BC22BEB64902EAA0BF930@KL1P15301MB0006.APCP153.PROD.OUTLOOK.COM Signed-off-by: Greg Kroah-Hartman commit a697b90ef09e9f4f38a2c4053c0a6c4d69b5776c Author: Dmitry Safonov Date: Fri May 18 00:35:10 2018 +0100 x86/mm: Drop TS_COMPAT on 64-bit exec() syscall commit acf46020012ccbca1172e9c7aeab399c950d9212 upstream. The x86 mmap() code selects the mmap base for an allocation depending on the bitness of the syscall. For 64bit sycalls it select mm->mmap_base and for 32bit mm->mmap_compat_base. exec() calls mmap() which in turn uses in_compat_syscall() to check whether the mapping is for a 32bit or a 64bit task. The decision is made on the following criteria: ia32 child->thread.status & TS_COMPAT x32 child->pt_regs.orig_ax & __X32_SYSCALL_BIT ia64 !ia32 && !x32 __set_personality_x32() was dropping TS_COMPAT flag, but set_personality_64bit() has kept compat syscall flag making in_compat_syscall() return true during the first exec() syscall. Which in result has user-visible effects, mentioned by Alexey: 1) It breaks ASAN $ gcc -fsanitize=address wrap.c -o wrap-asan $ ./wrap32 ./wrap-asan true ==1217==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. ==1217==ASan shadow was supposed to be located in the [0x00007fff7000-0x10007fff7fff] range. ==1217==Process memory map follows: 0x000000400000-0x000000401000 /home/izbyshev/test/gcc/asan-exec-from-32bit/wrap-asan 0x000000600000-0x000000601000 /home/izbyshev/test/gcc/asan-exec-from-32bit/wrap-asan 0x000000601000-0x000000602000 /home/izbyshev/test/gcc/asan-exec-from-32bit/wrap-asan 0x0000f7dbd000-0x0000f7de2000 /lib64/ld-2.27.so 0x0000f7fe2000-0x0000f7fe3000 /lib64/ld-2.27.so 0x0000f7fe3000-0x0000f7fe4000 /lib64/ld-2.27.so 0x0000f7fe4000-0x0000f7fe5000 0x7fed9abff000-0x7fed9af54000 0x7fed9af54000-0x7fed9af6b000 /lib64/libgcc_s.so.1 [snip] 2) It doesn't seem to be great for security if an attacker always knows that ld.so is going to be mapped into the first 4GB in this case (the same thing happens for PIEs as well). The testcase: $ cat wrap.c int main(int argc, char *argv[]) { execvp(argv[1], &argv[1]); return 127; } $ gcc wrap.c -o wrap $ LD_SHOW_AUXV=1 ./wrap ./wrap true |& grep AT_BASE AT_BASE: 0x7f63b8309000 AT_BASE: 0x7faec143c000 AT_BASE: 0x7fbdb25fa000 $ gcc -m32 wrap.c -o wrap32 $ LD_SHOW_AUXV=1 ./wrap32 ./wrap true |& grep AT_BASE AT_BASE: 0xf7eff000 AT_BASE: 0xf7cee000 AT_BASE: 0x7f8b9774e000 Fixes: 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap()") Fixes: ada26481dfe6 ("x86/mm: Make in_compat_syscall() work during exec") Reported-by: Alexey Izbyshev Bisected-by: Alexander Monakov Investigated-by: Andy Lutomirski Signed-off-by: Dmitry Safonov Signed-off-by: Thomas Gleixner Reviewed-by: Cyrill Gorcunov Cc: Borislav Petkov Cc: Alexander Monakov Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: stable@vger.kernel.org Cc: linux-mm@kvack.org Cc: Andy Lutomirski Cc: "H. Peter Anvin" Cc: Cyrill Gorcunov Cc: "Kirill A. Shutemov" Link: https://lkml.kernel.org/r/20180517233510.24996-1-dima@arista.com Signed-off-by: Greg Kroah-Hartman commit 5f3ca3928e08fc0c0a7199dcd80fb3788e0da884 Author: Masami Hiramatsu Date: Sun May 13 05:04:16 2018 +0100 ARM: 8771/1: kprobes: Prohibit kprobes on do_undefinstr commit eb0146daefdde65665b7f076fbff7b49dade95b9 upstream. Prohibit kprobes on do_undefinstr because kprobes on arm is implemented by undefined instruction. This means if we probe do_undefinstr(), it can cause infinit recursive exception. Fixes: 24ba613c9d6c ("ARM kprobes: core code") Signed-off-by: Masami Hiramatsu Cc: stable@vger.kernel.org Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit e5cefe3570a0903a36fccbb036ee1fa5e7e3b167 Author: Ard Biesheuvel Date: Fri May 4 07:59:58 2018 +0200 efi: Avoid potential crashes, fix the 'struct efi_pci_io_protocol_32' definition for mixed mode commit 0b3225ab9407f557a8e20f23f37aa7236c10a9b1 upstream. Mixed mode allows a kernel built for x86_64 to interact with 32-bit EFI firmware, but requires us to define all struct definitions carefully when it comes to pointer sizes. 'struct efi_pci_io_protocol_32' currently uses a 'void *' for the 'romimage' field, which will be interpreted as a 64-bit field on such kernels, potentially resulting in bogus memory references and subsequent crashes. Tested-by: Hans de Goede Signed-off-by: Ard Biesheuvel Cc: Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180504060003.19618-13-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 83a39c0e4adb49e11ae1c3c8f9dcc53f3cc4d548 Author: Dave Hansen Date: Wed May 9 10:13:58 2018 -0700 x86/pkeys: Do not special case protection key 0 commit 2fa9d1cfaf0e02f8abef0757002bff12dfcfa4e6 upstream. mm_pkey_is_allocated() treats pkey 0 as unallocated. That is inconsistent with the manpages, and also inconsistent with mm->context.pkey_allocation_map. Stop special casing it and only disallow values that are actually bad (< 0). The end-user visible effect of this is that you can now use mprotect_pkey() to set pkey=0. This is a bit nicer than what Ram proposed[1] because it is simpler and removes special-casing for pkey 0. On the other hand, it does allow applications to pkey_free() pkey-0, but that's just a silly thing to do, so we are not going to protect against it. The scenario that could happen is similar to what happens if you free any other pkey that is in use: it might get reallocated later and used to protect some other data. The most likely scenario is that pkey-0 comes back from pkey_alloc(), an access-disable or write-disable bit is set in PKRU for it, and the next stack access will SIGSEGV. It's not horribly different from if you mprotect()'d your stack or heap to be unreadable or unwritable, which is generally very foolish, but also not explicitly prevented by the kernel. 1. http://lkml.kernel.org/r/1522112702-27853-1-git-send-email-linuxram@us.ibm.com Signed-off-by: Dave Hansen Cc: Andrew Morton p Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Fixes: 58ab9a088dda ("x86/pkeys: Check against max pkey to avoid overflows") Link: http://lkml.kernel.org/r/20180509171358.47FD785E@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 359b8ff3281cacb63e52945fcfa33b29006bf5f4 Author: Dave Hansen Date: Wed May 9 10:13:51 2018 -0700 x86/pkeys: Override pkey when moving away from PROT_EXEC commit 0a0b152083cfc44ec1bb599b57b7aab41327f998 upstream. I got a bug report that the following code (roughly) was causing a SIGSEGV: mprotect(ptr, size, PROT_EXEC); mprotect(ptr, size, PROT_NONE); mprotect(ptr, size, PROT_READ); *ptr = 100; The problem is hit when the mprotect(PROT_EXEC) is implicitly assigned a protection key to the VMA, and made that key ACCESS_DENY|WRITE_DENY. The PROT_NONE mprotect() failed to remove the protection key, and the PROT_NONE-> PROT_READ left the PTE usable, but the pkey still in place and left the memory inaccessible. To fix this, we ensure that we always "override" the pkee at mprotect() if the VMA does not have execute-only permissions, but the VMA has the execute-only pkey. We had a check for PROT_READ/WRITE, but it did not work for PROT_NONE. This entirely removes the PROT_* checks, which ensures that PROT_NONE now works. Reported-by: Shakeel Butt Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Fixes: 62b5f7d013f ("mm/core, x86/mm/pkeys: Add execute-only protection keys support") Link: http://lkml.kernel.org/r/20180509171351.084C5A71@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit a6565fdd90cbe63e60bf8edc447992bf47f4791c Author: Martin Schwidefsky Date: Tue Apr 24 11:18:49 2018 +0200 s390: remove indirect branch from do_softirq_own_stack commit 9f18fff63cfd6f559daa1eaae60640372c65f84b upstream. The inline assembly to call __do_softirq on the irq stack uses an indirect branch. This can be replaced with a normal relative branch. Cc: stable@vger.kernel.org # 4.16 Fixes: f19fbd5ed6 ("s390: introduce execute-trampolines for branches") Reviewed-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit ce2e68b3c2604e4d06d972358ef139a38cdf8740 Author: Julian Wiedmann Date: Wed May 2 08:28:34 2018 +0200 s390/qdio: don't release memory in qdio_setup_irq() commit 2e68adcd2fb21b7188ba449f0fab3bee2910e500 upstream. Calling qdio_release_memory() on error is just plain wrong. It frees the main qdio_irq struct, when following code still uses it. Also, no other error path in qdio_establish() does this. So trust callers to clean up via qdio_free() if some step of the QDIO initialization fails. Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") Cc: #v2.6.27+ Signed-off-by: Julian Wiedmann Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 56130d9322326202d66d9ab4c148aa8b5f7abb50 Author: Hendrik Brueckner Date: Thu May 3 15:56:15 2018 +0200 s390/cpum_sf: ensure sample frequency of perf event attributes is non-zero commit 4bbaf2584b86b0772413edeac22ff448f36351b1 upstream. Correct a trinity finding for the perf_event_open() system call with a perf event attribute structure that uses a frequency but has the sampling frequency set to zero. This causes a FP divide exception during the sample rate initialization for the hardware sampling facility. Fixes: 8c069ff4bd606 ("s390/perf: add support for the CPU-Measurement Sampling Facility") Cc: stable@vger.kernel.org # 3.14+ Reviewed-by: Heiko Carstens Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit c568bdf37b6ecf37aa5823f8845c3ecf07f19ab3 Author: Julian Wiedmann Date: Wed May 2 08:48:43 2018 +0200 s390/qdio: fix access to uninitialized qdio_q fields commit e521813468f786271a87e78e8644243bead48fad upstream. Ever since CQ/QAOB support was added, calling qdio_free() straight after qdio_alloc() results in qdio_release_memory() accessing uninitialized memory (ie. q->u.out.use_cq and q->u.out.aobs). Followed by a kmem_cache_free() on the random AOB addresses. For older kernels that don't have 6e30c549f6ca, the same applies if qdio_establish() fails in the DEV_STATE_ONLINE check. While initializing q->u.out.use_cq would be enough to fix this particular bug, the more future-proof change is to just zero-alloc the whole struct. Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks") Cc: #v3.2+ Signed-off-by: Julian Wiedmann Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit e2266ea100ea54556c0524a7763a844f7c4eca17 Author: Michel Thierry Date: Mon May 14 09:54:45 2018 -0700 drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk commit b579f924a90f42fa561afd8201514fc216b71949 upstream. Factor in clear values wherever required while updating destination min/max. References: HSDES#1604444184 Signed-off-by: Michel Thierry Cc: mesa-dev@lists.freedesktop.org Cc: Mika Kuoppala Cc: Oscar Mateo Reviewed-by: Mika Kuoppala Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20180510200708.18097-1-michel.thierry@intel.com Cc: stable@vger.kernel.org Cc: Joonas Lahtinen Link: https://patchwork.freedesktop.org/patch/msgid/20180514165445.9198-1-michel.thierry@intel.com (backported from commit 0c79f9cb77eae28d48a4f9fc1b3341aacbbd260c) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit fc170bda228368f9e0b18d822cb7556dbbe60f7c Author: Pavel Tatashin Date: Fri May 18 16:09:13 2018 -0700 mm: don't allow deferred pages with NEED_PER_CPU_KM commit ab1e8d8960b68f54af42b6484b5950bd13a4054b upstream. It is unsafe to do virtual to physical translations before mm_init() is called if struct page is needed in order to determine the memory section number (see SECTION_IN_PAGE_FLAGS). This is because only in mm_init() we initialize struct pages for all the allocated memory when deferred struct pages are used. My recent fix in commit c9e97a1997 ("mm: initialize pages on demand during boot") exposed this problem, because it greatly reduced number of pages that are initialized before mm_init(), but the problem existed even before my fix, as Fengguang Wu found. Below is a more detailed explanation of the problem. We initialize struct pages in four places: 1. Early in boot a small set of struct pages is initialized to fill the first section, and lower zones. 2. During mm_init() we initialize "struct pages" for all the memory that is allocated, i.e reserved in memblock. 3. Using on-demand logic when pages are allocated after mm_init call (when memblock is finished) 4. After smp_init() when the rest free deferred pages are initialized. The problem occurs if we try to do va to phys translation of a memory between steps 1 and 2. Because we have not yet initialized struct pages for all the reserved pages, it is inherently unsafe to do va to phys if the translation itself requires access of "struct page" as in case of this combination: CONFIG_SPARSE && !CONFIG_SPARSE_VMEMMAP The following path exposes the problem: start_kernel() trap_init() setup_cpu_entry_areas() setup_cpu_entry_area(cpu) get_cpu_gdt_paddr(cpu) per_cpu_ptr_to_phys(addr) pcpu_addr_to_page(addr) virt_to_page(addr) pfn_to_page(__pa(addr) >> PAGE_SHIFT) We disable this path by not allowing NEED_PER_CPU_KM with deferred struct pages feature. The problems are discussed in these threads: http://lkml.kernel.org/r/20180418135300.inazvpxjxowogyge@wfg-t540p.sh.intel.com http://lkml.kernel.org/r/20180419013128.iurzouiqxvcnpbvz@wfg-t540p.sh.intel.com http://lkml.kernel.org/r/20180426202619.2768-1-pasha.tatashin@oracle.com Link: http://lkml.kernel.org/r/20180515175124.1770-1-pasha.tatashin@oracle.com Fixes: 3a80a7fa7989 ("mm: meminit: initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set") Signed-off-by: Pavel Tatashin Acked-by: Michal Hocko Reviewed-by: Andrew Morton Cc: Steven Sistare Cc: Daniel Jordan Cc: Mel Gorman Cc: Fengguang Wu Cc: Dennis Zhou Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 572e2385ae35f56cdc06ce37d0a117e8487f9845 Author: Ross Zwisler Date: Fri May 18 16:09:06 2018 -0700 radix tree: fix multi-order iteration race commit 9f418224e8114156d995b98fa4e0f4fd21f685fe upstream. Fix a race in the multi-order iteration code which causes the kernel to hit a GP fault. This was first seen with a production v4.15 based kernel (4.15.6-300.fc27.x86_64) utilizing a DAX workload which used order 9 PMD DAX entries. The race has to do with how we tear down multi-order sibling entries when we are removing an item from the tree. Remember for example that an order 2 entry looks like this: struct radix_tree_node.slots[] = [entry][sibling][sibling][sibling] where 'entry' is in some slot in the struct radix_tree_node, and the three slots following 'entry' contain sibling pointers which point back to 'entry.' When we delete 'entry' from the tree, we call : radix_tree_delete() radix_tree_delete_item() __radix_tree_delete() replace_slot() replace_slot() first removes the siblings in order from the first to the last, then at then replaces 'entry' with NULL. This means that for a brief period of time we end up with one or more of the siblings removed, so: struct radix_tree_node.slots[] = [entry][NULL][sibling][sibling] This causes an issue if you have a reader iterating over the slots in the tree via radix_tree_for_each_slot() while only under rcu_read_lock()/rcu_read_unlock() protection. This is a common case in mm/filemap.c. The issue is that when __radix_tree_next_slot() => skip_siblings() tries to skip over the sibling entries in the slots, it currently does so with an exact match on the slot directly preceding our current slot. Normally this works: V preceding slot struct radix_tree_node.slots[] = [entry][sibling][sibling][sibling] ^ current slot This lets you find the first sibling, and you skip them all in order. But in the case where one of the siblings is NULL, that slot is skipped and then our sibling detection is interrupted: V preceding slot struct radix_tree_node.slots[] = [entry][NULL][sibling][sibling] ^ current slot This means that the sibling pointers aren't recognized since they point all the way back to 'entry', so we think that they are normal internal radix tree pointers. This causes us to think we need to walk down to a struct radix_tree_node starting at the address of 'entry'. In a real running kernel this will crash the thread with a GP fault when you try and dereference the slots in your broken node starting at 'entry'. We fix this race by fixing the way that skip_siblings() detects sibling nodes. Instead of testing against the preceding slot we instead look for siblings via is_sibling_entry() which compares against the position of the struct radix_tree_node.slots[] array. This ensures that sibling entries are properly identified, even if they are no longer contiguous with the 'entry' they point to. Link: http://lkml.kernel.org/r/20180503192430.7582-6-ross.zwisler@linux.intel.com Fixes: 148deab223b2 ("radix-tree: improve multiorder iterators") Signed-off-by: Ross Zwisler Reported-by: CR, Sapthagirish Reviewed-by: Jan Kara Cc: Matthew Wilcox Cc: Christoph Hellwig Cc: Dan Williams Cc: Dave Chinner Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f6c0f020ee5bf3c44e3659b5eba346e1edb8cf8c Author: Matthew Wilcox Date: Fri May 18 16:08:44 2018 -0700 lib/test_bitmap.c: fix bitmap optimisation tests to report errors correctly commit 1e3054b98c5415d5cb5f8824fc33b548ae5644c3 upstream. I had neglected to increment the error counter when the tests failed, which made the tests noisy when they fail, but not actually return an error code. Link: http://lkml.kernel.org/r/20180509114328.9887-1-mpe@ellerman.id.au Fixes: 3cc78125a081 ("lib/test_bitmap.c: add optimisation tests") Signed-off-by: Matthew Wilcox Signed-off-by: Michael Ellerman Reported-by: Michael Ellerman Tested-by: Michael Ellerman Reviewed-by: Kees Cook Cc: Yury Norov Cc: Andy Shevchenko Cc: Geert Uytterhoeven Cc: [4.13+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5b86f020a789d09398689c16a3cbc2f287aa8cd6 Author: Haneen Mohammed Date: Fri May 11 07:15:42 2018 +0300 drm: Match sysfs name in link removal to link creation commit 7f6df440b8623c441c42d070bf592e2d2c1fa9bb upstream. This patch matches the sysfs name used in the unlinking with the linking function. Otherwise, remove_compat_control_link() fails to remove sysfs created by create_compat_control_link() in drm_dev_register(). Fixes: 6449b088dd51 ("drm: Add fake controlD* symlinks for backwards compat") Cc: Dave Airlie Cc: Alex Deucher Cc: Emil Velikov Cc: David Herrmann Cc: Greg Kroah-Hartman Cc: Daniel Vetter Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: David Airlie Cc: dri-devel@lists.freedesktop.org Cc: # v4.10+ Signed-off-by: Haneen Mohammed [seanpaul added Fixes and Cc tags] Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20180511041542.GA4253@haneen-vb Signed-off-by: Greg Kroah-Hartman commit 094595ce570121ecd03011c25eb30716caf845d3 Author: Nicholas Piggin Date: Tue May 15 01:59:47 2018 +1000 powerpc/powernv: Fix NVRAM sleep in invalid context when crashing commit c1d2a31397ec51f0370f6bd17b19b39152c263cb upstream. Similarly to opal_event_shutdown, opal_nvram_write can be called in the crash path with irqs disabled. Special case the delay to avoid sleeping in invalid context. Fixes: 3b8070335f75 ("powerpc/powernv: Fix OPAL NVRAM driver OPAL_BUSY loops") Cc: stable@vger.kernel.org # v3.2 Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit f4f05f62d3d19fc9c541a9186e511584ff9000b2 Author: Alexander Monakov Date: Sat Apr 28 16:56:06 2018 +0300 i2c: designware: fix poll-after-enable regression commit 06cb616b1bca7080824acfedb3d4c898e7a64836 upstream. Not all revisions of DW I2C controller implement the enable status register. On platforms where that's the case (e.g. BG2CD and SPEAr ARM SoCs), waiting for enable will time out as reading the unimplemented register yields zero. It was observed that reading the IC_ENABLE_STATUS register once suffices to avoid getting it stuck on Bay Trail hardware, so replace polling with one dummy read of the register. Fixes: fba4adbbf670 ("i2c: designware: must wait for enable") Signed-off-by: Alexander Monakov Tested-by: Ben Gardner Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit f9882808e355376a524c53bf2e66af12c775eb5b Author: Subash Abhinov Kasiviswanathan Date: Thu Mar 22 21:12:39 2018 -0600 netfilter: nf_socket: Fix out of bounds access in nf_sk_lookup_slow_v{4,6} commit 32c1733f0dd4bd11d6e65512bf4dc337c0452c8e upstream. skb_header_pointer will copy data into a buffer if data is non linear, otherwise it will return a pointer in the linear section of the data. nf_sk_lookup_slow_v{4,6} always copies data of size udphdr but later accesses memory within the size of tcphdr (th->doff) in case of TCP packets. This causes a crash when running with KASAN with the following call stack - BUG: KASAN: stack-out-of-bounds in xt_socket_lookup_slow_v4+0x524/0x718 net/netfilter/xt_socket.c:178 Read of size 2 at addr ffffffe3d417a87c by task syz-executor/28971 CPU: 2 PID: 28971 Comm: syz-executor Tainted: G B W O 4.9.65+ #1 Call trace: [] dump_backtrace+0x0/0x428 arch/arm64/kernel/traps.c:76 [] show_stack+0x28/0x38 arch/arm64/kernel/traps.c:226 [] __dump_stack lib/dump_stack.c:15 [inline] [] dump_stack+0xd4/0x124 lib/dump_stack.c:51 [] print_address_description+0x68/0x258 mm/kasan/report.c:248 [] kasan_report_error mm/kasan/report.c:347 [inline] [] kasan_report.part.2+0x228/0x2f0 mm/kasan/report.c:371 [] kasan_report+0x5c/0x70 mm/kasan/report.c:372 [] check_memory_region_inline mm/kasan/kasan.c:308 [inline] [] __asan_load2+0x84/0x98 mm/kasan/kasan.c:739 [] __tcp_hdrlen include/linux/tcp.h:35 [inline] [] xt_socket_lookup_slow_v4+0x524/0x718 net/netfilter/xt_socket.c:178 Fix this by copying data into appropriate size headers based on protocol. Fixes: a583636a83ea ("inet: refactor inet[6]_lookup functions to take skb") Signed-off-by: Tejaswi Tanikella Signed-off-by: Subash Abhinov Kasiviswanathan Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit d233f8d5bdd39ef13112147d8659bc2f5b9f6b8f Author: Florian Westphal Date: Tue Apr 10 09:30:27 2018 +0200 netfilter: nf_tables: can't fail after linking rule into active rule list commit 569ccae68b38654f04b6842b034aa33857f605fe upstream. rules in nftables a free'd using kfree, but protected by rcu, i.e. we must wait for a grace period to elapse. Normal removal patch does this, but nf_tables_newrule() doesn't obey this rule during error handling. It calls nft_trans_rule_add() *after* linking rule, and, if that fails to allocate memory, it unlinks the rule and then kfree() it -- this is unsafe. Switch order -- first add rule to transaction list, THEN link it to public list. Note: nft_trans_rule_add() uses GFP_KERNEL; it will not fail so this is not a problem in practice (spotted only during code review). Fixes: 0628b123c96d12 ("netfilter: nfnetlink: add batch support and use it from nf_tables") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 321bc88ec098845ec93d047858a010d41be26ed9 Author: Florian Westphal Date: Tue Apr 10 09:00:24 2018 +0200 netfilter: nf_tables: free set name in error path commit 2f6adf481527c8ab8033c601f55bfb5b3712b2ac upstream. set->name must be free'd here in case ops->init fails. Fixes: 387454901bd6 ("netfilter: nf_tables: Allow set names of up to 255 chars") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit bca7faea5410d50d2a3be4b11688f02a2fb2ee95 Author: Jann Horn Date: Wed Apr 4 21:03:21 2018 +0200 tee: shm: fix use-after-free via temporarily dropped reference commit bb765d1c331f62b59049d35607ed2e365802bef9 upstream. Bump the file's refcount before moving the reference into the fd table, not afterwards. The old code could drop the file's refcount to zero for a short moment before calling get_file() via get_dma_buf(). This code can only be triggered on ARM systems that use Linaro's OP-TEE. Fixes: 967c9cca2cc5 ("tee: generic TEE subsystem") Signed-off-by: Jann Horn Signed-off-by: Jens Wiklander Signed-off-by: Greg Kroah-Hartman commit 9a19a93bddb383548a04afaf40cec847de6296f8 Author: Steven Rostedt (VMware) Date: Wed May 9 14:36:09 2018 -0400 tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all} commit 45dd9b0666a162f8e4be76096716670cf1741f0e upstream. Doing an audit of trace events, I discovered two trace events in the xen subsystem that use a hack to create zero data size trace events. This is not what trace events are for. Trace events add memory footprint overhead, and if all you need to do is see if a function is hit or not, simply make that function noinline and use function tracer filtering. Worse yet, the hack used was: __array(char, x, 0) Which creates a static string of zero in length. There's assumptions about such constructs in ftrace that this is a dynamic string that is nul terminated. This is not the case with these tracepoints and can cause problems in various parts of ftrace. Nuke the trace events! Link: http://lkml.kernel.org/r/20180509144605.5a220327@gandalf.local.home Cc: stable@vger.kernel.org Fixes: 95a7d76897c1e ("xen/mmu: Use Xen specific TLB flush instead of the generic one.") Reviewed-by: Juergen Gross Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit d2dee2253be8d2f401f23015fc5e8226772ba479 Author: Halil Pasic Date: Tue Apr 24 13:26:56 2018 +0200 vfio: ccw: fix cleanup if cp_prefetch fails commit d66a7355717ec903d455277a550d930ba13df4a8 upstream. If the translation of a channel program fails, we may end up attempting to clean up (free, unpin) stuff that never got translated (and allocated, pinned) in the first place. By adjusting the lengths of the chains accordingly (so the element that failed, and all subsequent elements are excluded) cleanup activities based on false assumptions can be avoided. Let's make sure cp_free works properly after cp_prefetch returns with an error by setting ch_len of a ccw chain to the number of the translated CCWs on that chain. Cc: stable@vger.kernel.org #v4.12+ Acked-by: Pierre Morel Reviewed-by: Dong Jia Shi Signed-off-by: Halil Pasic Signed-off-by: Dong Jia Shi Message-Id: <20180423110113.59385-2-bjsdjshi@linux.vnet.ibm.com> [CH: fixed typos] Signed-off-by: Cornelia Huck Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 92ce74164efa1e2b8b2232a1c7b562126188beb0 Author: Benjamin Herrenschmidt Date: Wed Jan 10 17:10:12 2018 +1100 powerpc: Don't preempt_disable() in show_cpuinfo() commit 349524bc0da698ec77f2057cf4a4948eb6349265 upstream. This causes warnings from cpufreq mutex code. This is also rather unnecessary and ineffective. If we really want to prevent concurrent unplug, we could take the unplug read lock but I don't see this being critical. Fixes: cd77b5ce208c ("powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo") Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Michael Ellerman Acked-by: Michal Suchanek Signed-off-by: Greg Kroah-Hartman commit 27ea98a4c50c7aff5cfa132c15d6c68764b493fa Author: Andre Przywara Date: Fri May 11 15:20:14 2018 +0100 KVM: arm/arm64: VGIC/ITS: protect kvm_read_guest() calls with SRCU lock commit bf308242ab98b5d1648c3663e753556bef9bec01 upstream. kvm_read_guest() will eventually look up in kvm_memslots(), which requires either to hold the kvm->slots_lock or to be inside a kvm->srcu critical section. In contrast to x86 and s390 we don't take the SRCU lock on every guest exit, so we have to do it individually for each kvm_read_guest() call. Provide a wrapper which does that and use that everywhere. Note that ending the SRCU critical section before returning from the kvm_read_guest() wrapper is safe, because the data has been *copied*, so we don't need to rely on valid references to the memslot anymore. Cc: Stable # 4.8+ Reported-by: Jan Glauber Signed-off-by: Andre Przywara Acked-by: Christoffer Dall Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b6f6d8bfe779294e58f424bff08eab9914570d9b Author: Andre Przywara Date: Fri May 11 15:20:15 2018 +0100 KVM: arm/arm64: VGIC/ITS save/restore: protect kvm_read_guest() calls commit 711702b57cc3c50b84bd648de0f1ca0a378805be upstream. kvm_read_guest() will eventually look up in kvm_memslots(), which requires either to hold the kvm->slots_lock or to be inside a kvm->srcu critical section. In contrast to x86 and s390 we don't take the SRCU lock on every guest exit, so we have to do it individually for each kvm_read_guest() call. Use the newly introduced wrapper for that. Cc: Stable # 4.12+ Reported-by: Jan Glauber Signed-off-by: Andre Przywara Acked-by: Christoffer Dall Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b7f0fc1f06155e55ad7c0b3e245a6fd39ca0b6e3 Author: Kamal Dasu Date: Thu Apr 26 14:48:01 2018 -0400 spi: bcm-qspi: Always read and set BSPI_MAST_N_BOOT_CTRL commit 602805fb618b018b7a41fbb3f93c1992b078b1ae upstream. Always confirm the BSPI_MAST_N_BOOT_CTRL bit when enabling or disabling BSPI transfers. Fixes: 4e3b2d236fe00 ("spi: bcm-qspi: Add BSPI spi-nor flash controller driver") Signed-off-by: Kamal Dasu Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d18c3d2304de3c099f147ece9f757767e2eaeef1 Author: Kamal Dasu Date: Thu Apr 26 14:48:00 2018 -0400 spi: bcm-qspi: Avoid setting MSPI_CDRAM_PCS for spi-nor master commit 5eb9a07a4ae1008b67d8bcd47bddb3dae97456b7 upstream. Added fix for probing of spi-nor device non-zero chip selects. Set MSPI_CDRAM_PCS (peripheral chip select) with spi master for MSPI controller and not for MSPI/BSPI spi-nor master controller. Ensure setting of cs bit in chip select register on chip select change. Fixes: fa236a7ef24048 ("spi: bcm-qspi: Add Broadcom MSPI driver") Signed-off-by: Kamal Dasu Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 45804b0e3cb3f654383db94cc46af9ee7ed3bf08 Author: Andy Shevchenko Date: Thu Apr 19 19:53:32 2018 +0300 spi: pxa2xx: Allow 64-bit DMA commit efc4a13724b852ddaa3358402a8dec024ffbcb17 upstream. Currently the 32-bit device address only is supported for DMA. However, starting from Intel Sunrisepoint PCH the DMA address of the device FIFO can be 64-bit. Change the respective variable to be compatible with DMA engine expectations, i.e. to phys_addr_t. Fixes: 34cadd9c1bcb ("spi: pxa2xx: Add support for Intel Sunrisepoint") Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 50c0e85887bff4b9dda38789f8cf29cd41ef4507 Author: Wenwen Wang Date: Sat May 5 13:38:03 2018 -0500 ALSA: control: fix a redundant-copy issue commit 3f12888dfae2a48741c4caa9214885b3aaf350f9 upstream. In snd_ctl_elem_add_compat(), the fields of the struct 'data' need to be copied from the corresponding fields of the struct 'data32' in userspace. This is achieved by invoking copy_from_user() and get_user() functions. The problem here is that the 'type' field is copied twice. One is by copy_from_user() and one is by get_user(). Given that the 'type' field is not used between the two copies, the second copy is *completely* redundant and should be removed for better performance and cleanup. Also, these two copies can cause inconsistent data: as the struct 'data32' resides in userspace and a malicious userspace process can race to change the 'type' field between the two copies to cause inconsistent data. Depending on how the data is used in the future, such an inconsistency may cause potential security risks. For above reasons, we should take out the second copy. Signed-off-by: Wenwen Wang Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6283fcc9b93ac1f264416f63962730a9f5056af0 Author: Hans de Goede Date: Tue May 8 09:27:46 2018 +0200 ALSA: hda: Add Lenovo C50 All in one to the power_save blacklist commit c8beccc19b92f5172994c0732db689c08f4f98e5 upstream. Power-saving is causing loud plops on the Lenovo C50 All in one, add it to the blacklist. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1572975 Signed-off-by: Hans de Goede Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 13fe9058ed09d5f89c28afdf971614f0c70dc9d3 Author: Federico Cuello Date: Wed May 9 00:13:38 2018 +0200 ALSA: usb: mixer: volume quirk for CM102-A+/102S+ commit 21493316a3c4598f308d5a9fa31cc74639c4caff upstream. Currently it's not possible to set volume lower than 26% (it just mutes). Also fixes this warning: Warning! Unlikely big volume range (=9472), cval->res is probably wrong. [13] FU [PCM Playback Volume] ch = 2, val = -9473/-1/1 , and volume works fine for full range. Signed-off-by: Federico Cuello Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e842726eccf347212a9568470d78be268c513aad Author: Shuah Khan (Samsung OSG) Date: Tue May 15 17:57:23 2018 -0600 usbip: usbip_host: fix bad unlock balance during stub_probe() commit c171654caa875919be3c533d3518da8be5be966e upstream. stub_probe() calls put_busid_priv() in an error path when device isn't found in the busid_table. Fix it by making put_busid_priv() safe to be called with null struct bus_id_priv pointer. This problem happens when "usbip bind" is run without loading usbip_host driver and then running modprobe. The first failed bind attempt unbinds the device from the original driver and when usbip_host is modprobed, stub_probe() runs and doesn't find the device in its busid table and calls put_busid_priv(0 with null bus_id_priv pointer. usbip-host 3-10.2: 3-10.2 is not in match_busid table... skip! [ 367.359679] ===================================== [ 367.359681] WARNING: bad unlock balance detected! [ 367.359683] 4.17.0-rc4+ #5 Not tainted [ 367.359685] ------------------------------------- [ 367.359688] modprobe/2768 is trying to release lock ( [ 367.359689] ================================================================== [ 367.359696] BUG: KASAN: null-ptr-deref in print_unlock_imbalance_bug+0x99/0x110 [ 367.359699] Read of size 8 at addr 0000000000000058 by task modprobe/2768 [ 367.359705] CPU: 4 PID: 2768 Comm: modprobe Not tainted 4.17.0-rc4+ #5 Fixes: 22076557b07c ("usbip: usbip_host: fix NULL-ptr deref and use-after-free errors") in usb-linus Signed-off-by: Shuah Khan (Samsung OSG) Cc: stable Signed-off-by: Greg Kroah-Hartman commit ec0c93951ecb3ab9463c9a0d0a79c69e4bcb2b2a Author: Shuah Khan (Samsung OSG) Date: Mon May 14 20:49:58 2018 -0600 usbip: usbip_host: fix NULL-ptr deref and use-after-free errors commit 22076557b07c12086eeb16b8ce2b0b735f7a27e7 upstream. usbip_host updates device status without holding lock from stub probe, disconnect and rebind code paths. When multiple requests to import a device are received, these unprotected code paths step all over each other and drive fails with NULL-ptr deref and use-after-free errors. The driver uses a table lock to protect the busid array for adding and deleting busids to the table. However, the probe, disconnect and rebind paths get the busid table entry and update the status without holding the busid table lock. Add a new finer grain lock to protect the busid entry. This new lock will be held to search and update the busid entry fields from get_busid_idx(), add_match_busid() and del_match_busid(). match_busid_show() does the same to access the busid entry fields. get_busid_priv() changed to return the pointer to the busid entry holding the busid lock. stub_probe(), stub_disconnect() and stub_device_rebind() call put_busid_priv() to release the busid lock before returning. This changes fixes the unprotected code paths eliminating the race conditions in updating the busid entries. Reported-by: Jakub Jirasek Signed-off-by: Shuah Khan (Samsung OSG) Cc: stable Signed-off-by: Greg Kroah-Hartman commit 5cd4dd77782e9882e0a158344fe48223c24f5c95 Author: Shuah Khan (Samsung OSG) Date: Mon Apr 30 16:17:20 2018 -0600 usbip: usbip_host: run rebind from exit when module is removed commit 7510df3f29d44685bab7b1918b61a8ccd57126a9 upstream. After removing usbip_host module, devices it releases are left without a driver. For example, when a keyboard or a mass storage device are bound to usbip_host when it is removed, these devices are no longer bound to any driver. Fix it to run device_attach() from the module exit routine to restore the devices to their original drivers. This includes cleanup changes and moving device_attach() code to a common routine to be called from rebind_store() and usbip_host_exit(). Signed-off-by: Shuah Khan (Samsung OSG) Cc: stable Signed-off-by: Greg Kroah-Hartman commit cf3bcc3231ade09dd2733ca7d0f34d90ee7fe8fd Author: Shuah Khan (Samsung OSG) Date: Mon Apr 30 16:17:19 2018 -0600 usbip: usbip_host: delete device from busid_table after rebind commit 1e180f167d4e413afccbbb4a421b48b2de832549 upstream. Device is left in the busid_table after unbind and rebind. Rebind initiates usb bus scan and the original driver claims the device. After rescan the device should be deleted from the busid_table as it no longer belongs to usbip_host. Fix it to delete the device after device_attach() succeeds. Signed-off-by: Shuah Khan (Samsung OSG) Cc: stable Signed-off-by: Greg Kroah-Hartman commit a3d5f6ecba9923a669a5991b8dbd3398c59bf892 Author: Shuah Khan Date: Wed Apr 11 18:13:30 2018 -0600 usbip: usbip_host: refine probe and disconnect debug msgs to be useful commit 28b68acc4a88dcf91fd1dcf2577371dc9bf574cc upstream. Refine probe and disconnect debug msgs to be useful and say what is in progress. Signed-off-by: Shuah Khan Cc: stable Signed-off-by: Greg Kroah-Hartman