commit ee336b33e40b5eb44f152cda91612313789f9404 Author: Greg Kroah-Hartman Date: Thu Oct 29 10:12:22 2020 +0100 Linux 5.9.2 Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20201027135450.497324313@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit aa623e924021ce4e9f78bc667d8b4f6ed08143cb Author: Lorenzo Colitti Date: Tue Aug 25 14:55:05 2020 +0900 usb: gadget: f_ncm: allow using NCM in SuperSpeed Plus gadgets. [ Upstream commit 7974ecd7d3c0f42a98566f281e44ea8573a2ad88 ] Currently, enabling f_ncm at SuperSpeed Plus speeds results in an oops in config_ep_by_speed because ncm_set_alt passes in NULL ssp_descriptors. Fix this by re-using the SuperSpeed descriptors. This is safe because usb_assign_descriptors calls usb_copy_descriptors. Tested: enabled f_ncm on a dwc3 gadget and 10Gbps link, ran iperf Reviewed-by: Maciej Żenczykowski Signed-off-by: Lorenzo Colitti Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit dfeb33e55edf9e3e8ab4e33ece7977c105fe4239 Author: Christian Eggers Date: Tue Jul 28 11:29:59 2020 +0200 eeprom: at25: set minimum read/write access stride to 1 commit 284f52ac1c6cfa1b2e5c11b84653dd90e4e91de7 upstream. SPI eeproms are addressed by byte. Signed-off-by: Christian Eggers Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200728092959.24600-1-ceggers@arri.de Signed-off-by: Greg Kroah-Hartman commit c9c31dcdb02a7b65329c98a402111b2db822b402 Author: Peter Chen Date: Tue Sep 1 10:35:49 2020 +0800 usb: cdns3: gadget: free interrupt after gadget has deleted commit 98df91f8840cf750a0bc7c4c5d6b6085bac945b3 upstream. The interrupt may occur during the gadget deletion, it fixes the below oops. [ 2394.974604] configfs-gadget gadget: suspend [ 2395.042578] configfs-gadget 5b130000.usb: unregistering UDC driver [g1] [ 2395.382562] irq 229: nobody cared (try booting with the "irqpoll" option) [ 2395.389362] CPU: 0 PID: 301 Comm: kworker/u12:6 Not tainted 5.8.0-rc3-next-20200703-00060-g2f13b83cbf30-dirty #456 [ 2395.399712] Hardware name: Freescale i.MX8QM MEK (DT) [ 2395.404782] Workqueue: 2-0051 tcpm_state_machine_work [ 2395.409832] Call trace: [ 2395.412289] dump_backtrace+0x0/0x1d0 [ 2395.415950] show_stack+0x1c/0x28 [ 2395.419271] dump_stack+0xbc/0x118 [ 2395.422678] __report_bad_irq+0x50/0xe0 [ 2395.426513] note_interrupt+0x2cc/0x38c [ 2395.430355] handle_irq_event_percpu+0x88/0x90 [ 2395.434800] handle_irq_event+0x4c/0xe8 [ 2395.438640] handle_fasteoi_irq+0xbc/0x168 [ 2395.442740] generic_handle_irq+0x34/0x48 [ 2395.446752] __handle_domain_irq+0x68/0xc0 [ 2395.450846] gic_handle_irq+0x64/0x150 [ 2395.454596] el1_irq+0xb8/0x180 [ 2395.457733] __do_softirq+0xac/0x3b8 [ 2395.461310] irq_exit+0xc0/0xe0 [ 2395.464448] __handle_domain_irq+0x6c/0xc0 [ 2395.468540] gic_handle_irq+0x64/0x150 [ 2395.472295] el1_irq+0xb8/0x180 [ 2395.475436] _raw_spin_unlock_irqrestore+0x14/0x48 [ 2395.480232] usb_gadget_disconnect+0x120/0x140 [ 2395.484678] usb_gadget_remove_driver+0xb4/0xd0 [ 2395.489208] usb_del_gadget+0x6c/0xc8 [ 2395.492872] cdns3_gadget_exit+0x5c/0x120 [ 2395.496882] cdns3_role_stop+0x60/0x90 [ 2395.500634] cdns3_role_set+0x64/0xd8 [ 2395.504301] usb_role_switch_set_role.part.0+0x3c/0x90 [ 2395.509444] usb_role_switch_set_role+0x20/0x30 [ 2395.513978] tcpm_mux_set+0x60/0xf8 [ 2395.517470] tcpm_reset_port+0xa4/0xf0 [ 2395.521222] tcpm_detach.part.0+0x44/0x50 [ 2395.525227] tcpm_state_machine_work+0x8b0/0x2360 [ 2395.529932] process_one_work+0x1c8/0x470 [ 2395.533939] worker_thread+0x50/0x420 [ 2395.537603] kthread+0x148/0x168 [ 2395.540830] ret_from_fork+0x10/0x18 [ 2395.544399] handlers: [ 2395.546671] [<000000008dea28da>] cdns3_wakeup_irq [ 2395.551375] [<000000009fee5c61>] cdns3_drd_irq threaded [<000000005148eaec>] cdns3_drd_thread_irq [ 2395.560255] Disabling IRQ #229 [ 2395.563454] configfs-gadget gadget: unbind function 'Mass Storage Function'/000000000132f835 [ 2395.563657] configfs-gadget gadget: unbind [ 2395.563917] udc 5b130000.usb: releasing '5b130000.usb' Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: Acked-by: Roger Quadros Signed-off-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit dc9bb43e69e2d17d78910bddb422481c9824afb1 Author: Oliver Neukum Date: Mon Sep 28 23:17:55 2020 +0900 USB: cdc-wdm: Make wdm_flush() interruptible and add wdm_fsync(). commit 37d2a36394d954413a495da61da1b2a51ecd28ab upstream. syzbot is reporting hung task at wdm_flush() [1], for there is a circular dependency that wdm_flush() from flip_close() for /dev/cdc-wdm0 forever waits for /dev/raw-gadget to be closed while close() for /dev/raw-gadget cannot be called unless close() for /dev/cdc-wdm0 completes. Tetsuo Handa considered that such circular dependency is an usage error [2] which corresponds to an unresponding broken hardware [3]. But Alan Stern responded that we should be prepared for such hardware [4]. Therefore, this patch changes wdm_flush() to use wait_event_interruptible_timeout() which gives up after 30 seconds, for hardware that remains silent must be ignored. The 30 seconds are coming out of thin air. Changing wait_event() to wait_event_interruptible_timeout() makes error reporting from close() syscall less reliable. To compensate it, this patch also implements wdm_fsync() which does not use timeout. Those who want to be very sure that data has gone out to the device are now advised to call fsync(), with a caveat that fsync() can return -EINVAL when running on older kernels which do not implement wdm_fsync(). This patch also fixes three more problems (listed below) found during exhaustive discussion and testing. Since multiple threads can concurrently call wdm_write()/wdm_flush(), we need to use wake_up_all() whenever clearing WDM_IN_USE in order to make sure that all waiters are woken up. Also, error reporting needs to use fetch-and-clear approach in order not to report same error for multiple times. Since wdm_flush() checks WDM_DISCONNECTING, wdm_write() should as well check WDM_DISCONNECTING. In wdm_flush(), since locks are not held, it is not safe to dereference desc->intf after checking that WDM_DISCONNECTING is not set [5]. Thus, remove dev_err() from wdm_flush(). [1] https://syzkaller.appspot.com/bug?id=e7b761593b23eb50855b9ea31e3be5472b711186 [2] https://lkml.kernel.org/r/27b7545e-8f41-10b8-7c02-e35a08eb1611@i-love.sakura.ne.jp [3] https://lkml.kernel.org/r/79ba410f-e0ef-2465-b94f-6b9a4a82adf5@i-love.sakura.ne.jp [4] https://lkml.kernel.org/r/20200530011040.GB12419@rowland.harvard.edu [5] https://lkml.kernel.org/r/c85331fc-874c-6e46-a77f-0ef1dc075308@i-love.sakura.ne.jp Reported-by: syzbot Cc: stable Co-developed-by: Tetsuo Handa Signed-off-by: Tetsuo Handa Signed-off-by: Oliver Neukum Cc: Alan Stern Link: https://lore.kernel.org/r/20200928141755.3476-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman commit b36b283154ba08befd07c15c271b294a8ca44f50 Author: Vincent Mailhol Date: Sat Oct 3 00:41:51 2020 +0900 usb: cdc-acm: add quirk to blacklist ETAS ES58X devices commit a4f88430af896bf34ec25a7a5f0e053fb3d928e0 upstream. The ES58X devices has a CDC ACM interface (used for debug purpose). During probing, the device is thus recognized as USB Modem (CDC ACM), preventing the etas-es58x module to load: usbcore: registered new interface driver etas_es58x usb 1-1.1: new full-speed USB device number 14 using xhci_hcd usb 1-1.1: New USB device found, idVendor=108c, idProduct=0159, bcdDevice= 1.00 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.1: Product: ES581.4 usb 1-1.1: Manufacturer: ETAS GmbH usb 1-1.1: SerialNumber: 2204355 cdc_acm 1-1.1:1.0: No union descriptor, testing for castrated device cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device Thus, these have been added to the ignore list in drivers/usb/class/cdc-acm.c N.B. Future firmware release of the ES58X will remove the CDC-ACM interface. `lsusb -v` of the three devices variant (ES581.4, ES582.1 and ES584.1): Bus 001 Device 011: ID 108c:0159 Robert Bosch GmbH ES581.4 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x108c Robert Bosch GmbH idProduct 0x0159 bcdDevice 1.00 iManufacturer 1 ETAS GmbH iProduct 2 ES581.4 iSerial 3 2204355 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0035 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 5 Bus Powered Configuration bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 iInterface 4 ACM Control Interface CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x01 call management bDataInterface 0 CDC ACM: bmCapabilities 0x06 sends break line coding and serial state Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) Bus 001 Device 012: ID 108c:0168 Robert Bosch GmbH ES582 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x108c Robert Bosch GmbH idProduct 0x0168 bcdDevice 1.00 iManufacturer 1 ETAS GmbH iProduct 2 ES582 iSerial 3 0108933 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0043 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 16 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Bus 001 Device 013: ID 108c:0169 Robert Bosch GmbH ES584.1 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x108c Robert Bosch GmbH idProduct 0x0169 bcdDevice 1.00 iManufacturer 1 ETAS GmbH iProduct 2 ES584.1 iSerial 3 0100320 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0043 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 16 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Signed-off-by: Vincent Mailhol Cc: stable Link: https://lore.kernel.org/r/20201002154219.4887-8-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman commit 9d1cd4e8919cd31da4570e28bc5c888f437e97eb Author: Chunfeng Yun Date: Mon Sep 14 14:17:30 2020 +0800 usb: gadget: bcm63xx_udc: fix up the error of undeclared usb_debug_root commit 5b35dd1a5a666329192a9616ec21098591259058 upstream. Fix up the build error caused by undeclared usb_debug_root Cc: stable Fixes: a66ada4f241c ("usb: gadget: bcm63xx_udc: create debugfs directory under usb root") Reported-by: kernel test robot Signed-off-by: Chunfeng Yun Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 1072de467c1452ade5cf23e928bae09dc06b7a45 Author: Peng Fan Date: Tue Sep 29 17:55:09 2020 +0800 tty: serial: fsl_lpuart: fix lpuart32_poll_get_char commit 29788ab1d2bf26c130de8f44f9553ee78a27e8d5 upstream. The watermark is set to 1, so we need to input two chars to trigger RDRF using the original logic. With the new logic, we could always get the char when there is data in FIFO. Suggested-by: Fugang Duan Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20200929095509.21680-1-peng.fan@nxp.com Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit fd6df793d1c67f9c29eb708a8805f73a9151ed94 Author: Peng Fan Date: Tue Sep 29 17:19:20 2020 +0800 tty: serial: lpuart: fix lpuart32_write usage commit 9ea40db477c024dcb87321b7f32bd6ea12130ac2 upstream. The 2nd and 3rd parameter were wrongly used, and cause kernel abort when doing kgdb debug. Fixes: 1da17d7cf8e2 ("tty: serial: fsl_lpuart: Use appropriate lpuart32_* I/O funcs") Cc: stable Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20200929091920.22612-1-peng.fan@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 52e318de92f5ddc9d39431c868d1e8f1a91357f2 Author: Julian Wiedmann Date: Thu Aug 27 10:17:02 2020 +0200 s390/qeth: don't let HW override the configured port role [ Upstream commit a04f0ecacdb0639d416614619225a39de3927e22 ] The only time that our Bridgeport role should change is when we change the configuration ourselves. In which case we also adjust our internal state tracking, no need to do it again when we receive the corresponding event. Removing the locked section helps a subsequent patch that needs to flush the workqueue while under sbp_lock. It would be nice to raise a warning here in case HW does weird things after all, but this could end up generating false-positives when we change the configuration ourselves. Suggested-by: Alexandra Winter Signed-off-by: Julian Wiedmann Reviewed-by: Alexandra Winter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b0a20475d574cb5b2d56455ee2770cb8a1b0daf2 Author: Valentin Vidic Date: Sun Oct 18 20:42:55 2020 +0200 net: korina: cast KSEG0 address to pointer in kfree [ Upstream commit 3bd57b90554b4bb82dce638e0668ef9dc95d3e96 ] Fixes gcc warning: passing argument 1 of 'kfree' makes pointer from integer without a cast Fixes: 3af5f0f5c74e ("net: korina: fix kfree of rx/tx descriptor array") Reported-by: kernel test robot Signed-off-by: Valentin Vidic Link: https://lore.kernel.org/r/20201018184255.28989-1-vvidic@valentin-vidic.from.hr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 48da6737d4d1bc5f8cf945ab56cd6e37e3cd8803 Author: Zekun Shen Date: Tue Jun 23 18:11:05 2020 -0400 ath10k: check idx validity in __ath10k_htt_rx_ring_fill_n() [ Upstream commit bad60b8d1a7194df38fd7fe4b22f3f4dcf775099 ] The idx in __ath10k_htt_rx_ring_fill_n function lives in consistent dma region writable by the device. Malfunctional or malicious device could manipulate such idx to have a OOB write. Either by htt->rx_ring.netbufs_ring[idx] = skb; or by ath10k_htt_set_paddrs_ring(htt, paddr, idx); The idx can also be negative as it's signed, giving a large memory space to write to. It's possibly exploitable by corruptting a legit pointer with a skb pointer. And then fill skb with payload as rougue object. Part of the log here. Sometimes it appears as UAF when writing to a freed memory by chance. [ 15.594376] BUG: unable to handle page fault for address: ffff887f5c1804f0 [ 15.595483] #PF: supervisor write access in kernel mode [ 15.596250] #PF: error_code(0x0002) - not-present page [ 15.597013] PGD 0 P4D 0 [ 15.597395] Oops: 0002 [#1] SMP KASAN PTI [ 15.597967] CPU: 0 PID: 82 Comm: kworker/u2:2 Not tainted 5.6.0 #69 [ 15.598843] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 15.600438] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] [ 15.601389] RIP: 0010:__ath10k_htt_rx_ring_fill_n (linux/drivers/net/wireless/ath/ath10k/htt_rx.c:173) ath10k_core Signed-off-by: Zekun Shen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200623221105.3486-1-bruceshenzk@gmail.com Signed-off-by: Sasha Levin commit 03d75ead8ed9f2e55122a4958115525359733779 Author: Navid Emamdoost Date: Sun Jun 14 01:36:19 2020 -0500 drm/panfrost: perfcnt: fix ref count leak in panfrost_perfcnt_enable_locked [ Upstream commit 9df0e0c1889677175037445d5ad1654d54176369 ] in panfrost_perfcnt_enable_locked, pm_runtime_get_sync is called which increments the counter even in case of failure, leading to incorrect ref count. In case of failure, decrement the ref count before returning. Acked-by: Alyssa Rosenzweig Signed-off-by: Navid Emamdoost Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20200614063619.44944-1-navid.emamdoost@gmail.com Signed-off-by: Sasha Levin commit 568cc5f8e7b380a34c463fd4cacb12fb159231d7 Author: Alvin Lee Date: Wed Jul 29 23:08:59 2020 -0400 drm/amd/display: Disconnect pipe separetely when disable pipe split [ Upstream commit 81b437f57e35a6caa3a4304e6fff0eba0a9f3266 ] [Why] When changing pixel formats for HDR (e.g. ARGB -> FP16) there are configurations that change from 2 pipes to 1 pipe. In these cases, it seems that disconnecting MPCC and doing a surface update at the same time(after unlocking) causes some registers to be updated slightly faster than others after unlocking (e.g. if the pixel format is updated to FP16 before the new surface address is programmed, we get corruption on the screen because the pixel formats aren't matching). We separate disconnecting MPCC from the rest of the pipe programming sequence to prevent this. [How] Move MPCC disconnect into separate operation than the rest of the pipe programming. Signed-off-by: Alvin Lee Reviewed-by: Aric Cyr Acked-by: Qingqing Zhuo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ce8a7f51a662d03e91828a6fceefe1d659f83c50 Author: Tian Tao Date: Wed Aug 12 15:42:59 2020 +0800 drm/hisilicon: Code refactoring for hibmc_drv_de [ Upstream commit 13b0d4a9ae0c2d650993c48be797992eaf621332 ] The memory used to be allocated with devres helpers and released automatically. In rare circumstances, the memory's release could have happened before the DRM device got released, which would have caused memory corruption of some kind. Now we're embedding the data structures in struct hibmc_drm_private. The whole release problem has been resolved, because struct hibmc_drm_private is allocated with drmm_kzalloc and always released with the DRM device. Signed-off-by: Tian Tao Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/1597218179-3938-3-git-send-email-tiantao6@hisilicon.com Signed-off-by: Sasha Levin commit 5c4a56534d608071f477713a4f320e6d098eed20 Author: Serge Semin Date: Fri Jul 31 23:08:23 2020 +0300 dmaengine: dw: Activate FIFO-mode for memory peripherals only [ Upstream commit 6d9459d04081c796fc67c2bb771f4e4ebb5744c4 ] CFGx.FIFO_MODE field controls a DMA-controller "FIFO readiness" criterion. In other words it determines when to start pushing data out of a DW DMAC channel FIFO to a destination peripheral or from a source peripheral to the DW DMAC channel FIFO. Currently FIFO-mode is set to one for all DW DMAC channels. It means they are tuned to flush data out of FIFO (to a memory peripheral or by accepting the burst transaction requests) when FIFO is at least half-full (except at the end of the block transfer, when FIFO-flush mode is activated) and are configured to get data to the FIFO when it's at least half-empty. Such configuration is a good choice when there is no slave device involved in the DMA transfers. In that case the number of bursts per block is less than when CFGx.FIFO_MODE = 0 and, hence, the bus utilization will improve. But the latency of DMA transfers may increase when CFGx.FIFO_MODE = 1, since DW DMAC will wait for the channel FIFO contents to be either half-full or half-empty depending on having the destination or the source transfers. Such latencies might be dangerous in case if the DMA transfers are expected to be performed from/to a slave device. Since normally peripheral devices keep data in internal FIFOs, any latency at some critical moment may cause one being overflown and consequently losing data. This especially concerns a case when either a peripheral device is relatively fast or the DW DMAC engine is relatively slow with respect to the incoming data pace. In order to solve problems, which might be caused by the latencies described above, let's enable the FIFO half-full/half-empty "FIFO readiness" criterion only for DMA transfers with no slave device involved. Thanks to the commit 99ba8b9b0d97 ("dmaengine: dw: Initialize channel before each transfer") we can freely do that in the generic dw_dma_initialize_chan() method. Signed-off-by: Serge Semin Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200731200826.9292-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1288ad64db90330a35a90e2d7f5eae5324a5deff Author: Serge Semin Date: Fri Jul 31 23:08:26 2020 +0300 dmaengine: dw: Add DMA-channels mask cell support [ Upstream commit e8ee6c8cb61b676f1a2d6b942329e98224bd8ee9 ] DW DMA IP-core provides a way to synthesize the DMA controller with channels having different parameters like maximum burst-length, multi-block support, maximum data width, etc. Those parameters both explicitly and implicitly affect the channels performance. Since DMA slave devices might be very demanding to the DMA performance, let's provide a functionality for the slaves to be assigned with DW DMA channels, which performance according to the platform engineer fulfill their requirements. After this patch is applied it can be done by passing the mask of suitable DMA-channels either directly in the dw_dma_slave structure instance or as a fifth cell of the DMA DT-property. If mask is zero or not provided, then there is no limitation on the channels allocation. For instance Baikal-T1 SoC is equipped with a DW DMAC engine, which first two channels are synthesized with max burst length of 16, while the rest of the channels have been created with max-burst-len=4. It would seem that the first two channels must be faster than the others and should be more preferable for the time-critical DMA slave devices. In practice it turned out that the situation is quite the opposite. The channels with max-burst-len=4 demonstrated a better performance than the channels with max-burst-len=16 even when they both had been initialized with the same settings. The performance drop of the first two DMA-channels made them unsuitable for the DW APB SSI slave device. No matter what settings they are configured with, full-duplex SPI transfers occasionally experience the Rx FIFO overflow. It means that the DMA-engine doesn't keep up with incoming data pace even though the SPI-bus is enabled with speed of 25MHz while the DW DMA controller is clocked with 50MHz signal. There is no such problem has been noticed for the channels synthesized with max-burst-len=4. Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20200731200826.9292-6-Sergey.Semin@baikalelectronics.ru Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 382c36e8fbdced7985c5c98cc20052c95071ae96 Author: Qingqing Zhuo Date: Thu Jul 30 15:35:41 2020 -0400 drm/amd/display: Screen corruption on dual displays (DP+USB-C) [ Upstream commit ce271b40a91f781af3dee985c39e841ac5148766 ] [why] Current pipe merge and split logic only supports cases where new dc_state is allocated and relies on dc->current_state to gather information from previous dc_state. Calls to validate_bandwidth on UPDATE_TYPE_MED would cause an issue because there is no new dc_state allocated, and data in dc->current_state would be overwritten during pipe merge. [how] Only allow validate_bandwidth when new dc_state space is created. Signed-off-by: Qingqing Zhuo Reviewed-by: Nicholas Kazlauskas Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 18f5fe2158ebfcee63261f382d784b85d66da0e5 Author: Can Guo Date: Sun Aug 9 05:15:48 2020 -0700 scsi: ufs: ufs-qcom: Fix race conditions caused by ufs_qcom_testbus_config() [ Upstream commit 89dd87acd40a44de8ff3358138aedf8f73f4efc6 ] If ufs_qcom_dump_dbg_regs() calls ufs_qcom_testbus_config() from ufshcd_suspend/resume and/or clk gate/ungate context, pm_runtime_get_sync() and ufshcd_hold() will cause a race condition. Fix this by removing the unnecessary calls of pm_runtime_get_sync() and ufshcd_hold(). Link: https://lore.kernel.org/r/1596975355-39813-3-git-send-email-cang@codeaurora.org Reviewed-by: Hongwu Su Reviewed-by: Avri Altman Reviewed-by: Bean Huo Reviewed-by: Asutosh Das Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e90b8a94ccd2a8890214da5371f883ef4e5f2ff9 Author: Bard Liao Date: Mon Aug 17 23:29:16 2020 +0800 soundwire: intel: reinitialize IP+DSP in .prepare(), but only when resuming [ Upstream commit a5a0239c27fe1125826c5cad4dec9cd1fd960d4a ] The .prepare() callback is invoked for normal streaming, underflows or during the system resume transition. In the latter case, the context for the ALH PDIs is lost, and the DSP is not initialized properly either, but the bus parameters don't need to be recomputed. Conversely, when doing a regular .prepare() during an underflow, the ALH/SHIM registers shall not be changed as the hardware cannot be reprogrammed after the DMA started (hardware spec requirement). This patch adds storage of PDI and hw_params in the DAI dma context, and the difference between the types of .prepare() usages is handled via a simple boolean, updated when suspending, and tested for in the .prepare() case. Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200817152923.3259-6-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4c033fff5af93b07348ae865bd5318ab1ad480b1 Author: Eli Billauer Date: Fri Jul 31 08:46:50 2020 +0300 usb: core: Solve race condition in anchor cleanup functions [ Upstream commit fbc299437c06648afcc7891e6e2e6638dd48d4df ] usb_kill_anchored_urbs() is commonly used to cancel all URBs on an anchor just before releasing resources which the URBs rely on. By doing so, users of this function rely on that no completer callbacks will take place from any URB on the anchor after it returns. However if this function is called in parallel with __usb_hcd_giveback_urb processing a URB on the anchor, the latter may call the completer callback after usb_kill_anchored_urbs() returns. This can lead to a kernel panic due to use after release of memory in interrupt context. The race condition is that __usb_hcd_giveback_urb() first unanchors the URB and then makes the completer callback. Such URB is hence invisible to usb_kill_anchored_urbs(), allowing it to return before the completer has been called, since the anchor's urb_list is empty. Even worse, if the racing completer callback resubmits the URB, it may remain in the system long after usb_kill_anchored_urbs() returns. Hence list_empty(&anchor->urb_list), which is used in the existing while-loop, doesn't reliably ensure that all URBs of the anchor are gone. A similar problem exists with usb_poison_anchored_urbs() and usb_scuttle_anchored_urbs(). This patch adds an external do-while loop, which ensures that all URBs are indeed handled before these three functions return. This change has no effect at all unless the race condition occurs, in which case the loop will busy-wait until the racing completer callback has finished. This is a rare condition, so the CPU waste of this spinning is negligible. The additional do-while loop relies on usb_anchor_check_wakeup(), which returns true iff the anchor list is empty, and there is no __usb_hcd_giveback_urb() in the system that is in the middle of the unanchor-before-complete phase. The @suspend_wakeups member of struct usb_anchor is used for this purpose, which was introduced to solve another problem which the same race condition causes, in commit 6ec4147e7bdb ("usb-anchor: Delay usb_wait_anchor_empty_timeout wake up till completion is done"). The surely_empty variable is necessary, because usb_anchor_check_wakeup() must be called with the lock held to prevent races. However the spinlock must be released and reacquired if the outer loop spins with an empty URB list while waiting for the unanchor-before-complete passage to finish: The completer callback may very well attempt to take the very same lock. To summarize, using usb_anchor_check_wakeup() means that the patched functions can return only when the anchor's list is empty, and there is no invisible URB being processed. Since the inner while loop finishes on the empty list condition, the new do-while loop will terminate as well, except for when the said race condition occurs. Signed-off-by: Eli Billauer Acked-by: Oliver Neukum Acked-by: Alan Stern Link: https://lore.kernel.org/r/20200731054650.30644-1-eli.billauer@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0487abb574219cb0f30e7af148beb7a5446172a7 Author: Wang Yufen Date: Mon Jul 20 17:36:05 2020 +0800 brcm80211: fix possible memleak in brcmf_proto_msgbuf_attach [ Upstream commit 6c151410d5b57e6bb0d91a735ac511459539a7bf ] When brcmf_proto_msgbuf_attach fail and msgbuf->txflow_wq != NULL, we should destroy the workqueue. Reported-by: Hulk Robot Signed-off-by: Wang Yufen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1595237765-66238-1-git-send-email-wangyufen@huawei.com Signed-off-by: Sasha Levin commit 4da1851efdcbaffdfc46182b39bc6fd2d313d6de Author: Kevin Barnett Date: Fri Jul 31 16:01:33 2020 -0500 scsi: smartpqi: Avoid crashing kernel for controller issues [ Upstream commit 9e68cccc8ef7206f0bccd590378d0dca8f9b4f57 ] Eliminate kernel panics when getting invalid responses from controller. Take controller offline instead of causing kernel panics. Link: https://lore.kernel.org/r/159622929306.30579.16523318707596752828.stgit@brunhilda Reviewed-by: Scott Teel Reviewed-by: Scott Benesh Reviewed-by: Prasad Munirathnam Reviewed-by: Martin Wilck Signed-off-by: Kevin Barnett Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8ef4a483222a7cde448cdf5107ae26996399d9f0 Author: Sathyanarayana Nujella Date: Fri Aug 21 14:55:59 2020 -0500 ASoC: Intel: sof_rt5682: override quirk data for tgl_max98373_rt5682 [ Upstream commit 3e1734b64ce786c54dc98adcfe67941e6011d735 ] A Chrome System based on tgl_max98373_rt5682 has different SSP interface configurations. Using DMI data of this variant DUT, override quirk data. Reviewed-by: Guennadi Liakhovetski Signed-off-by: Sathyanarayana Nujella Signed-off-by: Mac Chiang Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200821195603.215535-13-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit afa8510b66a46d0e650ed3efa6b6cd61cd19690a Author: Sathyanarayana Nujella Date: Fri Aug 21 14:56:00 2020 -0500 ASoC: SOF: Add topology filename override based on dmi data match [ Upstream commit 5253a73d567dcd75e62834ff5f502ea9470e5722 ] Add topology filename override based on system DMI data matching, typically to account for a different hardware layout. In ACPI based systems, the tplg_filename is pre-defined in an ACPI machine table. When a DMI quirk is detected, the sof_pdata->tplg_filename is not set with the hard-coded ACPI value, and instead is set with the DMI-specific filename. Reviewed-by: Guennadi Liakhovetski Signed-off-by: Sathyanarayana Nujella Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200821195603.215535-14-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2790292909db02c90c086f24f768e23bee8d9c8d Author: Connor McAdams Date: Tue Aug 25 16:10:29 2020 -0400 ALSA: hda/ca0132 - Add new quirk ID for SoundBlaster AE-7. [ Upstream commit 620f08eea6d6961b789af3fa3ea86725c8c93ece ] Add a new PCI subsystem ID for the SoundBlaster AE-7 card. Signed-off-by: Connor McAdams Link: https://lore.kernel.org/r/20200825201040.30339-11-conmanx360@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bff89d18bff103313b8fe98c71e1307b4188ae0e Author: Connor McAdams Date: Tue Aug 25 16:10:37 2020 -0400 ALSA: hda/ca0132 - Add AE-7 microphone selection commands. [ Upstream commit ed93f9750c6c2ed371347d0aac3dcd31cb9cf256 ] Add AE-7 quirk data for setting of microphone. The AE-7 has no front panel connector, so only rear-mic/line-in have new commands. Signed-off-by: Connor McAdams Link: https://lore.kernel.org/r/20200825201040.30339-19-conmanx360@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit dd014731f03c170387276d3449247af53a8cfbbb Author: Tetsuo Handa Date: Fri Aug 21 17:27:19 2020 +0900 mwifiex: don't call del_timer_sync() on uninitialized timer [ Upstream commit 621a3a8b1c0ecf16e1e5667ea5756a76a082b738 ] syzbot is reporting that del_timer_sync() is called from mwifiex_usb_cleanup_tx_aggr() from mwifiex_unregister_dev() without checking timer_setup() from mwifiex_usb_tx_init() was called [1]. Ganapathi Bhat proposed a possibly cleaner fix, but it seems that that fix was forgotten [2]. "grep -FrB1 'del_timer' drivers/ | grep -FA1 '.function)'" says that currently there are 28 locations which call del_timer[_sync]() only if that timer's function field was initialized (because timer_setup() sets that timer's function field). Therefore, let's use same approach here. [1] https://syzkaller.appspot.com/bug?id=26525f643f454dd7be0078423e3cdb0d57744959 [2] https://lkml.kernel.org/r/CA+ASDXMHt2gq9Hy+iP_BYkWXsSreWdp3_bAfMkNcuqJ3K+-jbQ@mail.gmail.com Reported-by: syzbot Cc: Ganapathi Bhat Cc: Brian Norris Signed-off-by: Tetsuo Handa Reviewed-by: Brian Norris Acked-by: Ganapathi Bhat Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200821082720.7716-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Sasha Levin commit a5375f501ba5d02897cd726ec704c0a7123ebb8e Author: Julian Wiedmann Date: Thu Aug 27 10:17:05 2020 +0200 s390/qeth: strictly order bridge address events [ Upstream commit 9d6a569a4cbab5a8b4c959d4e312daeecb7c9f09 ] The current code for bridge address events has two shortcomings in its control sequence: 1. after disabling address events via PNSO, we don't flush the remaining events from the event_wq. So if the feature is re-enabled fast enough, stale events could leak over. 2. PNSO and the events' arrival via the READ ccw device are unordered. So even if we flushed the workqueue, it's difficult to say whether the READ device might produce more events onto the workqueue afterwards. Fix this by 1. explicitly fencing off the events when we no longer care, in the READ device's event handler. This ensures that once we flush the workqueue, it doesn't get additional address events. 2. Flush the workqueue after disabling the events & fencing them off. As the code that triggers the flush will typically hold the sbp_lock, we need to rework the worker code to avoid a deadlock here in case of a 'notifications-stopped' event. In case of lock contention, requeue such an event with a delay. We'll eventually aquire the lock, or spot that the feature has been disabled and the event can thus be discarded. This leaves the theoretical race that a stale event could arrive _after_ we re-enabled ourselves to receive events again. Such an event would be impossible to distinguish from a 'good' event, nothing we can do about it. Signed-off-by: Julian Wiedmann Reviewed-by: Alexandra Winter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 73f0142fbe68e73425b3d9be5b80f82472afda69 Author: Jan Kara Date: Wed Mar 4 14:01:44 2020 +0100 reiserfs: Fix memory leak in reiserfs_parse_options() [ Upstream commit e9d4709fcc26353df12070566970f080e651f0c9 ] When a usrjquota or grpjquota mount option is used multiple times, we will leak memory allocated for the file name. Make sure the last setting is used and all the previous ones are properly freed. Reported-by: syzbot+c9e294bbe0333a6b7640@syzkaller.appspotmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 25c144118260d9b889907d4721b268ed3eca1e83 Author: Peilin Ye Date: Tue Aug 11 03:46:40 2020 -0400 ipvs: Fix uninit-value in do_ip_vs_set_ctl() [ Upstream commit c5a8a8498eed1c164afc94f50a939c1a10abf8ad ] do_ip_vs_set_ctl() is referencing uninitialized stack value when `len` is zero. Fix it. Reported-by: syzbot+23b5f9e7caf61d9a3898@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=46ebfb92a8a812621a001ef04d90dfa459520fe2 Suggested-by: Julian Anastasov Signed-off-by: Peilin Ye Acked-by: Julian Anastasov Reviewed-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 142043fa059f95a4ba4f8bb6ffbcacdc9bb903fb Author: Dinghao Liu Date: Sun Aug 23 15:44:21 2020 +0800 Bluetooth: btusb: Fix memleak in btusb_mtk_submit_wmt_recv_urb [ Upstream commit d33fe77bdf75806d785dabf90d21d962122e5296 ] When kmalloc() on buf fails, urb should be freed just like when kmalloc() on dr fails. Signed-off-by: Dinghao Liu Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 81f61a566097160cdb95b44a35c6729103e2c3e9 Author: Tong Zhang Date: Fri Aug 21 12:19:40 2020 -0400 tty: ipwireless: fix error handling [ Upstream commit db332356222d9429731ab9395c89cca403828460 ] ipwireless_send_packet() can only return 0 on success and -ENOMEM on error, the caller should check non zero for error condition Signed-off-by: Tong Zhang Acked-by: David Sterba Link: https://lore.kernel.org/r/20200821161942.36589-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6820b718faefdd44c5bdd441b079a821c824ebf1 Author: George Kennedy Date: Tue Jul 7 15:26:03 2020 -0400 fbmem: add margin check to fb_check_caps() [ Upstream commit a49145acfb975d921464b84fe00279f99827d816 ] A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting or yres setting in struct fb_var_screeninfo will result in a KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as the margins are being cleared. The margins are cleared in chunks and if the xres setting or yres setting is a value of zero upto the chunk size, the failure will occur. Add a margin check to validate xres and yres settings. Signed-off-by: George Kennedy Reported-by: syzbot+e5fd3e65515b48c02a30@syzkaller.appspotmail.com Reviewed-by: Dan Carpenter Cc: Dhaval Giani Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/1594149963-13801-1-git-send-email-george.kennedy@oracle.com Signed-off-by: Sasha Levin commit e8245e1af881dfdf9dc031e0adec804a6465bbda Author: Nilesh Javali Date: Tue Sep 8 02:56:52 2020 -0700 scsi: qedi: Fix list_del corruption while removing active I/O [ Upstream commit 28b35d17f9f8573d4646dd8df08917a4076a6b63 ] While aborting the I/O, the firmware cleanup task timed out and driver deleted the I/O from active command list. Some time later the firmware sent the cleanup task response and driver again deleted the I/O from active command list causing firmware to send completion for non-existent I/O and list_del corruption of active command list. Add fix to check if I/O is present before deleting it from the active command list to ensure firmware sends valid I/O completion and protect against list_del corruption. Link: https://lore.kernel.org/r/20200908095657.26821-4-mrangankar@marvell.com Signed-off-by: Nilesh Javali Signed-off-by: Manish Rangankar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 70adb2c8b884932315b364fb8eac5b8e7cb38e50 Author: Nilesh Javali Date: Tue Sep 8 02:56:53 2020 -0700 scsi: qedi: Protect active command list to avoid list corruption [ Upstream commit c0650e28448d606c84f76c34333dba30f61de993 ] Protect active command list for non-I/O commands like login response, logout response, text response, and recovery cleanup of active list to avoid list corruption. Link: https://lore.kernel.org/r/20200908095657.26821-5-mrangankar@marvell.com Signed-off-by: Nilesh Javali Signed-off-by: Manish Rangankar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0813e5e2b4683ab9fa88a696d37fb69e6b85882b Author: Nilesh Javali Date: Tue Sep 8 02:56:55 2020 -0700 scsi: qedi: Mark all connections for recovery on link down event [ Upstream commit 4118879be3755b38171063dfd4a57611d4b20a83 ] For short time cable pulls, the in-flight I/O to the firmware is never cleaned up, resulting in the behaviour of stale I/O completion causing list_del corruption and soft lockup of the system. On link down event, mark all the connections for recovery, causing cleanup of all the in-flight I/O immediately. Link: https://lore.kernel.org/r/20200908095657.26821-7-mrangankar@marvell.com Signed-off-by: Nilesh Javali Signed-off-by: Manish Rangankar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6209476c6c001bcd72dc8f1873b129eab7ea24e7 Author: Saurav Kashyap Date: Mon Sep 7 05:14:40 2020 -0700 scsi: qedf: Return SUCCESS if stale rport is encountered [ Upstream commit 10aff62fab263ad7661780816551420cea956ebb ] If SUCCESS is not returned, error handling will escalate. Return SUCCESS similar to other conditions in this function. Link: https://lore.kernel.org/r/20200907121443.5150-6-jhasan@marvell.com Signed-off-by: Saurav Kashyap Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 20326c303664f8d3c98a3fd00f878e2d41e38309 Author: Hans de Goede Date: Tue Sep 1 09:56:42 2020 +0200 HID: ite: Add USB id match for Acer One S1003 keyboard dock [ Upstream commit 5bf2f2f331ad812c9b7eea6e14a3ea328acbffc0 ] The Acer One S1003 2-in-1 keyboard dock uses a Synaptics S910xx touchpad which is connected to an ITE 8910 USB keyboard controller chip. This keyboard has the same quirk for its rfkill / airplane mode hotkey as other keyboards with ITE keyboard chips, it only sends a single release event when pressed and released, it never sends a press event. This commit adds this keyboards USB id to the hid-ite id-table, fixing the rfkill key not working on this keyboard. Note that like for the Acer Aspire Switch 10 (SW5-012) the id-table entry matches on the HID_GROUP_GENERIC generic group so that hid-ite only binds to the keyboard interface and the mouse/touchpad interface is left untouched so that hid-multitouch can bind to it. Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit d138346630b815328329a494f4e9a528fac5c7f7 Author: Doug Horn Date: Wed Sep 2 14:08:25 2020 -0700 Fix use after free in get_capset_info callback. [ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ] If a response to virtio_gpu_cmd_get_capset_info takes longer than five seconds to return, the callback will access freed kernel memory in vg->capsets. Signed-off-by: Doug Horn Link: http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 19dad72714e9c92b477ee5c54e307f2150b411f1 Author: Chris Chiu Date: Sun Sep 6 12:04:24 2020 +0800 rtl8xxxu: prevent potential memory leak [ Upstream commit 86279456a4d47782398d3cb8193f78f672e36cac ] Free the skb if usb_submit_urb fails on rx_urb. And free the urb no matter usb_submit_urb succeeds or not in rtl8xxxu_submit_int_urb. Signed-off-by: Chris Chiu Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200906040424.22022-1-chiu@endlessm.com Signed-off-by: Sasha Levin commit 6999dbacbada200c7da1aef55989bb6bc4547ab2 Author: Keita Suzuki Date: Tue Sep 8 12:17:41 2020 +0000 brcmsmac: fix memory leak in wlc_phy_attach_lcnphy [ Upstream commit f4443293d741d1776b86ed1dd8c4e4285d0775fc ] When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy, the allocated pi->u.pi_lcnphy is leaked, since struct brcms_phy will be freed in the caller function. Fix this by calling wlc_phy_detach_lcnphy in the error handler of wlc_phy_txpwr_srom_read_lcnphy before returning. Signed-off-by: Keita Suzuki Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200908121743.23108-1-keitasuzuki.park@sslab.ics.keio.ac.jp Signed-off-by: Sasha Levin commit 7c71624fe89aecf63a2e78491d55288fdf9529eb Author: Pierre-Louis Bossart Date: Tue Aug 18 06:23:40 2020 +0800 soundwire: cadence: fix race condition between suspend and Slave device alerts [ Upstream commit d2068da5c85697b5880483dd7beaba98e0b62e02 ] In system suspend stress cases, the SOF CI reports timeouts. The root cause is that an alert is generated while the system suspends. The interrupt handling generates transactions on the bus that will never be handled because the interrupts are disabled in parallel. As a result, the transaction never completes and times out on resume. This error doesn't seem too problematic since it happens in a work queue, and the system recovers without issues. Nevertheless, this race condition should not happen. When doing a system suspend, or when disabling interrupts, we should make sure the current transaction can complete, and prevent new work from being queued. BugLink: https://github.com/thesofproject/linux/issues/2344 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Rander Wang Signed-off-by: Bard Liao Acked-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20200817222340.18042-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c91282cb79d819a2589d0c692bc715afcc810ed7 Author: Yonghong Song Date: Wed Sep 9 10:15:42 2020 -0700 selftests/bpf: Fix test_sysctl_loop{1, 2} failure due to clang change [ Upstream commit 7fb5eefd76394cfefb380724a87ca40b47d44405 ] Andrii reported that with latest clang, when building selftests, we have error likes: error: progs/test_sysctl_loop1.c:23:16: in function sysctl_tcp_mem i32 (%struct.bpf_sysctl*): Looks like the BPF stack limit of 512 bytes is exceeded. Please move large on stack variables into BPF per-cpu array map. The error is triggered by the following LLVM patch: https://reviews.llvm.org/D87134 For example, the following code is from test_sysctl_loop1.c: static __always_inline int is_tcp_mem(struct bpf_sysctl *ctx) { volatile char tcp_mem_name[] = "net/ipv4/tcp_mem/very_very_very_very_long_pointless_string"; ... } Without the above LLVM patch, the compiler did optimization to load the string (59 bytes long) with 7 64bit loads, 1 8bit load and 1 16bit load, occupying 64 byte stack size. With the above LLVM patch, the compiler only uses 8bit loads, but subregister is 32bit. So stack requirements become 4 * 59 = 236 bytes. Together with other stuff on the stack, total stack size exceeds 512 bytes, hence compiler complains and quits. To fix the issue, removing "volatile" key word or changing "volatile" to "const"/"static const" does not work, the string is put in .rodata.str1.1 section, which libbpf did not process it and errors out with libbpf: elf: skipping unrecognized data section(6) .rodata.str1.1 libbpf: prog 'sysctl_tcp_mem': bad map relo against '.L__const.is_tcp_mem.tcp_mem_name' in section '.rodata.str1.1' Defining the string const as global variable can fix the issue as it puts the string constant in '.rodata' section which is recognized by libbpf. In the future, when libbpf can process '.rodata.str*.*' properly, the global definition can be changed back to local definition. Defining tcp_mem_name as a global, however, triggered a verifier failure. ./test_progs -n 7/21 libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: invalid stack off=0 size=1 verification time 6975 usec stack depth 160+64 processed 889 insns (limit 1000000) max_states_per_insn 4 total_states 14 peak_states 14 mark_read 10 libbpf: -- END LOG -- libbpf: failed to load program 'sysctl_tcp_mem' libbpf: failed to load object 'test_sysctl_loop2.o' test_bpf_verif_scale:FAIL:114 #7/21 test_sysctl_loop2.o:FAIL This actually exposed a bpf program bug. In test_sysctl_loop{1,2}, we have code like const char tcp_mem_name[] = "<...long string...>"; ... char name[64]; ... for (i = 0; i < sizeof(tcp_mem_name); ++i) if (name[i] != tcp_mem_name[i]) return 0; In the above code, if sizeof(tcp_mem_name) > 64, name[i] access may be out of bound. The sizeof(tcp_mem_name) is 59 for test_sysctl_loop1.c and 79 for test_sysctl_loop2.c. Without promotion-to-global change, old compiler generates code where the overflowed stack access is actually filled with valid value, so hiding the bpf program bug. With promotion-to-global change, the code is different, more specifically, the previous loading constants to stack is gone, and "name" occupies stack[-64:0] and overflow access triggers a verifier error. To fix the issue, adjust "name" buffer size properly. Reported-by: Andrii Nakryiko Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200909171542.3673449-1-yhs@fb.com Signed-off-by: Sasha Levin commit 5ca811003c97e840264953c2f29f0aa4ad73d3a1 Author: Daniel Wagner Date: Tue Sep 8 10:15:13 2020 +0200 scsi: qla2xxx: Warn if done() or free() are called on an already freed srb [ Upstream commit c0014f94218ea3a312f6235febea0d626c5f2154 ] Emit a warning when ->done or ->free are called on an already freed srb. There is a hidden use-after-free bug in the driver which corrupts the srb memory pool which originates from the cleanup callbacks. An extensive search didn't bring any lights on the real problem. The initial fix was to set both pointers to NULL and try to catch invalid accesses. But instead the memory corruption was gone and the driver didn't crash. Since not all calling places check for NULL pointer, add explicitly default handlers. With this we workaround the memory corruption and add a debug help. Link: https://lore.kernel.org/r/20200908081516.8561-2-dwagner@suse.de Reviewed-by: Martin Wilck Reviewed-by: Arun Easi Signed-off-by: Daniel Wagner Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1226b71dc8ca45bfe62b3a545ff4497668a2fe33 Author: Jing Xiangfeng Date: Mon Sep 7 16:39:49 2020 +0800 scsi: ibmvfc: Fix error return in ibmvfc_probe() [ Upstream commit 5e48a084f4e824e1b624d3fd7ddcf53d2ba69e53 ] Fix to return error code PTR_ERR() from the error handling case instead of 0. Link: https://lore.kernel.org/r/20200907083949.154251-1-jingxiangfeng@huawei.com Acked-by: Tyrel Datwyler Signed-off-by: Jing Xiangfeng Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 47a3691f519681223e5efa5a6c367a0a7bb5c589 Author: Qian Cai Date: Thu Sep 10 08:26:15 2020 -0700 iomap: fix WARN_ON_ONCE() from unprivileged users [ Upstream commit a805c111650cdba6ee880f528abdd03c1af82089 ] It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by unprivileged users which would taint the kernel, or worse - panic if panic_on_warn or panic_on_taint is set. Hence, just convert it to pr_warn_ratelimited() to let users know their workloads are racing. Thank Dave Chinner for the initial analysis of the racing reproducers. Signed-off-by: Qian Cai Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit f6e89eeacdb15f93a675f92a5df0724cc43f07b5 Author: Daniel Vetter Date: Mon Sep 7 10:22:25 2020 +0200 drm/xlnx: Use devm_drm_dev_alloc [ Upstream commit 075342ea3d93044d68f821cf91c1a1a7d2fa569e ] Gets rid of drmm_add_final_kfree, which I want to unexport so that it stops confusion people about this transitional state of rolling drm managed memory out. This also fixes the missing drm_dev_put in the error path of the probe code. v2: Drop the misplaced drm_dev_put from zynqmp_dpsub_drm_init (all other paths leaked on error, this should have been in zynqmp_dpsub_probe), now that subsumed by the auto-cleanup of devm_drm_dev_alloc. Reviewed-by: Hyun Kwon Signed-off-by: Daniel Vetter Cc: Hyun Kwon Cc: Laurent Pinchart Cc: Michal Simek Cc: linux-arm-kernel@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20200907082225.150837-1-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin commit 9301245ca7473ac9811a9e03b5f415ca5810b098 Author: Zhenzhong Duan Date: Sat Sep 12 18:25:58 2020 +0800 drm/msm/a6xx: fix a potential overflow issue [ Upstream commit 08d3ab4b46339bc6f97e83b54a3fb4f8bf8f4cd9 ] It's allocating an array of a6xx_gpu_state_obj structure rathor than its pointers. This patch fix it. Signed-off-by: Zhenzhong Duan Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 7ce67ced325a945055933942d601e50cf4980013 Author: Abhishek Pandit-Subedi Date: Fri Sep 11 15:33:18 2020 -0700 Bluetooth: Only mark socket zapped after unlocking [ Upstream commit 20ae4089d0afeb24e9ceb026b996bfa55c983cc2 ] Since l2cap_sock_teardown_cb doesn't acquire the channel lock before setting the socket as zapped, it could potentially race with l2cap_sock_release which frees the socket. Thus, wait until the cleanup is complete before marking the socket as zapped. This race was reproduced on a JBL GO speaker after the remote device rejected L2CAP connection due to resource unavailability. Here is a dmesg log with debug logs from a repro of this bug: [ 3465.424086] Bluetooth: hci_core.c:hci_acldata_packet() hci0 len 16 handle 0x0003 flags 0x0002 [ 3465.424090] Bluetooth: hci_conn.c:hci_conn_enter_active_mode() hcon 00000000cfedd07d mode 0 [ 3465.424094] Bluetooth: l2cap_core.c:l2cap_recv_acldata() conn 000000007eae8952 len 16 flags 0x2 [ 3465.424098] Bluetooth: l2cap_core.c:l2cap_recv_frame() len 12, cid 0x0001 [ 3465.424102] Bluetooth: l2cap_core.c:l2cap_raw_recv() conn 000000007eae8952 [ 3465.424175] Bluetooth: l2cap_core.c:l2cap_sig_channel() code 0x03 len 8 id 0x0c [ 3465.424180] Bluetooth: l2cap_core.c:l2cap_connect_create_rsp() dcid 0x0045 scid 0x0000 result 0x02 status 0x00 [ 3465.424189] Bluetooth: l2cap_core.c:l2cap_chan_put() chan 000000006acf9bff orig refcnt 4 [ 3465.424196] Bluetooth: l2cap_core.c:l2cap_chan_del() chan 000000006acf9bff, conn 000000007eae8952, err 111, state BT_CONNECT [ 3465.424203] Bluetooth: l2cap_sock.c:l2cap_sock_teardown_cb() chan 000000006acf9bff state BT_CONNECT [ 3465.424221] Bluetooth: l2cap_core.c:l2cap_chan_put() chan 000000006acf9bff orig refcnt 3 [ 3465.424226] Bluetooth: hci_core.h:hci_conn_drop() hcon 00000000cfedd07d orig refcnt 6 [ 3465.424234] BUG: spinlock bad magic on CPU#2, kworker/u17:0/159 [ 3465.425626] Bluetooth: hci_sock.c:hci_sock_sendmsg() sock 000000002bb0cb64 sk 00000000a7964053 [ 3465.430330] lock: 0xffffff804410aac0, .magic: 00000000, .owner: /-1, .owner_cpu: 0 [ 3465.430332] Causing a watchdog bite! Signed-off-by: Abhishek Pandit-Subedi Reported-by: Balakrishna Godavarthi Reviewed-by: Manish Mandlik Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit da0e332c9fb1830af12d40b6f11e99eaaa0e32a4 Author: Jia Yang Date: Tue Jul 14 10:32:36 2020 +0200 drm: fix double free for gbo in drm_gem_vram_init and drm_gem_vram_create [ Upstream commit da62cb7230f0871c30dc9789071f63229158d261 ] I got a use-after-free report when doing some fuzz test: If ttm_bo_init() fails, the "gbo" and "gbo->bo.base" will be freed by ttm_buffer_object_destroy() in ttm_bo_init(). But then drm_gem_vram_create() and drm_gem_vram_init() will free "gbo" and "gbo->bo.base" again. BUG: KMSAN: use-after-free in drm_vma_offset_remove+0xb3/0x150 CPU: 0 PID: 24282 Comm: syz-executor.1 Tainted: G B W 5.7.0-rc4-msan #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack dump_stack+0x1c9/0x220 kmsan_report+0xf7/0x1e0 __msan_warning+0x58/0xa0 drm_vma_offset_remove+0xb3/0x150 drm_gem_free_mmap_offset drm_gem_object_release+0x159/0x180 drm_gem_vram_init drm_gem_vram_create+0x7c5/0x990 drm_gem_vram_fill_create_dumb drm_gem_vram_driver_dumb_create+0x238/0x590 drm_mode_create_dumb drm_mode_create_dumb_ioctl+0x41d/0x450 drm_ioctl_kernel+0x5a4/0x710 drm_ioctl+0xc6f/0x1240 vfs_ioctl ksys_ioctl __do_sys_ioctl __se_sys_ioctl+0x2e9/0x410 __x64_sys_ioctl+0x4a/0x70 do_syscall_64+0xb8/0x160 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4689b9 Code: fd e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f368fa4dc98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000000076bf00 RCX: 00000000004689b9 RDX: 0000000020000240 RSI: 00000000c02064b2 RDI: 0000000000000003 RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00000000004d17e0 R14: 00007f368fa4e6d4 R15: 000000000076bf0c Uninit was created at: kmsan_save_stack_with_flags kmsan_internal_poison_shadow+0x66/0xd0 kmsan_slab_free+0x6e/0xb0 slab_free_freelist_hook slab_free kfree+0x571/0x30a0 drm_gem_vram_destroy ttm_buffer_object_destroy+0xc8/0x130 ttm_bo_release kref_put ttm_bo_put+0x117d/0x23e0 ttm_bo_init_reserved+0x11c0/0x11d0 ttm_bo_init+0x289/0x3f0 drm_gem_vram_init drm_gem_vram_create+0x775/0x990 drm_gem_vram_fill_create_dumb drm_gem_vram_driver_dumb_create+0x238/0x590 drm_mode_create_dumb drm_mode_create_dumb_ioctl+0x41d/0x450 drm_ioctl_kernel+0x5a4/0x710 drm_ioctl+0xc6f/0x1240 vfs_ioctl ksys_ioctl __do_sys_ioctl __se_sys_ioctl+0x2e9/0x410 __x64_sys_ioctl+0x4a/0x70 do_syscall_64+0xb8/0x160 entry_SYSCALL_64_after_hwframe+0x44/0xa9 If ttm_bo_init() fails, the "gbo" will be freed by ttm_buffer_object_destroy() in ttm_bo_init(). But then drm_gem_vram_create() and drm_gem_vram_init() will free "gbo" again. Reported-by: Hulk Robot Reported-by: butt3rflyh4ck Signed-off-by: Jia Yang Signed-off-by: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20200714083238.28479-2-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 604a39e15ad25ab4d885f1e1325f54c713fe114c Author: Hamish Martin Date: Fri Sep 11 09:25:11 2020 +1200 usb: ohci: Default to per-port over-current protection [ Upstream commit b77d2a0a223bc139ee8904991b2922d215d02636 ] Some integrated OHCI controller hubs do not expose all ports of the hub to pins on the SoC. In some cases the unconnected ports generate spurious over-current events. For example the Broadcom 56060/Ranger 2 SoC contains a nominally 3 port hub but only the first port is wired. Default behaviour for ohci-platform driver is to use global over-current protection mode (AKA "ganged"). This leads to the spurious over-current events affecting all ports in the hub. We now alter the default to use per-port over-current protection. This patch results in the following configuration changes depending on quirks: - For quirk OHCI_QUIRK_SUPERIO no changes. These systems remain set up for ganged power switching and no over-current protection. - For quirk OHCI_QUIRK_AMD756 or OHCI_QUIRK_HUB_POWER power switching remains at none, while over-current protection is now guaranteed to be set to per-port rather than the previous behaviour where it was either none or global over-current protection depending on the value at function entry. Suggested-by: Alan Stern Acked-by: Alan Stern Signed-off-by: Hamish Martin Link: https://lore.kernel.org/r/20200910212512.16670-1-hamish.martin@alliedtelesis.co.nz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 220704134810f4647e7ba802dbac44d02fc9a7ad Author: Darrick J. Wong Date: Wed Sep 9 14:21:06 2020 -0700 xfs: make sure the rt allocator doesn't run off the end [ Upstream commit 2a6ca4baed620303d414934aa1b7b0a8e7bab05f ] There's an overflow bug in the realtime allocator. If the rt volume is large enough to handle a single allocation request that is larger than the maximum bmap extent length and the rt bitmap ends exactly on a bitmap block boundary, it's possible that the near allocator will try to check the freeness of a range that extends past the end of the bitmap. This fails with a corruption error and shuts down the fs. Therefore, constrain maxlen so that the range scan cannot run off the end of the rt bitmap. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 1024e6934253883b26841e2aed04f4962ce575f9 Author: Viresh Kumar Date: Mon Aug 31 11:22:37 2020 +0530 opp: Prevent memory leak in dev_pm_opp_attach_genpd() [ Upstream commit cb60e9602cce1593eb1e9cdc8ee562815078a354 ] If dev_pm_opp_attach_genpd() is called multiple times (once for each CPU sharing the table), then it would result in unwanted behavior like memory leak, attaching the domain multiple times, etc. Handle that by checking and returning earlier if the domains are already attached. Now that dev_pm_opp_detach_genpd() can get called multiple times as well, we need to protect that too. Note that the virtual device pointers aren't returned in this case, as they may become unavailable to some callers during the middle of the operation. Reported-by: Stephan Gerhold Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 27e52f1c32f90b9114e03851f402e72df9419441 Author: Eric Biggers Date: Sun Jun 28 00:00:57 2020 -0700 reiserfs: only call unlock_new_inode() if I_NEW [ Upstream commit 8859bf2b1278d064a139e3031451524a49a56bd0 ] unlock_new_inode() is only meant to be called after a new inode has already been inserted into the hash table. But reiserfs_new_inode() can call it even before it has inserted the inode, triggering the WARNING in unlock_new_inode(). Fix this by only calling unlock_new_inode() if the inode has the I_NEW flag set, indicating that it's in the table. This addresses the syzbot report "WARNING in unlock_new_inode" (https://syzkaller.appspot.com/bug?extid=187510916eb6a14598f7). Link: https://lore.kernel.org/r/20200628070057.820213-1-ebiggers@kernel.org Reported-by: syzbot+187510916eb6a14598f7@syzkaller.appspotmail.com Signed-off-by: Eric Biggers Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit b2e203d14f9a1cb21d55ad17295395d1edba4d06 Author: Keita Suzuki Date: Wed Sep 9 07:18:51 2020 +0000 misc: rtsx: Fix memory leak in rtsx_pci_probe [ Upstream commit bc28369c6189009b66d9619dd9f09bd8c684bb98 ] When mfd_add_devices() fail, pcr->slots should also be freed. However, the current implementation does not free the member, leading to a memory leak. Fix this by adding a new goto label that frees pcr->slots. Signed-off-by: Keita Suzuki Link: https://lore.kernel.org/r/20200909071853.4053-1-keitasuzuki.park@sslab.ics.keio.ac.jp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4e57482e8440fac7137832629109730ea4b267aa Author: Thomas Tai Date: Thu Sep 17 18:43:03 2020 +0200 dma-direct: Fix potential NULL pointer dereference [ Upstream commit f959dcd6ddfd29235030e8026471ac1b022ad2b0 ] When booting the kernel v5.9-rc4 on a VM, the kernel would panic when printing a warning message in swiotlb_map(). The dev->dma_mask must not be a NULL pointer when calling the dma mapping layer. A NULL pointer check can potentially avoid the panic. Signed-off-by: Thomas Tai Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 48464c17bd642ee0b52c02a1ce22108b7345087b Author: Maciej Fijalkowski Date: Wed Sep 16 23:10:07 2020 +0200 bpf: Limit caller's stack depth 256 for subprogs with tailcalls [ Upstream commit 7f6e4312e15a5c370e84eaa685879b6bdcc717e4 ] Protect against potential stack overflow that might happen when bpf2bpf calls get combined with tailcalls. Limit the caller's stack depth for such case down to 256 so that the worst case scenario would result in 8k stack size (32 which is tailcall limit * 256 = 8k). Suggested-by: Alexei Starovoitov Signed-off-by: Maciej Fijalkowski Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 62c4333990af5c0679d5aba6147cc20055f3e8ea Author: Neil Armstrong Date: Wed Sep 16 17:01:45 2020 +0200 drm/panfrost: add support for vendor quirk [ Upstream commit 91e89097b86f566636ea5a7329c79d5521be46d2 ] The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM, G12A/SM1 & G12B SoCs needs a quirk in the PWR registers after each reset. This adds a callback in the device compatible struct of permit this. Signed-off-by: Neil Armstrong [Steven: Fix typo in commit log] Reviewed-by: Steven Price Reviewed-by: Alyssa Rosenzweig Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-2-narmstrong@baylibre.com Signed-off-by: Sasha Levin commit d7170b30872133deb3591edfd2e58b3757af1dfa Author: Neil Armstrong Date: Wed Sep 16 17:01:46 2020 +0200 drm/panfrost: add amlogic reset quirk callback [ Upstream commit 110003002291525bb209f47e6dbf121a63249a97 ] The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM, G12A/SM1 & G12B SoCs needs a quirk in the PWR registers at the GPU reset time. Since the Amlogic's integration of the GPU cores with the SoC is not publicly documented we do not know what does these values, but they permit having a fully functional GPU running with Panfrost. Signed-off-by: Neil Armstrong [Steven: Fix typo in commit log] Reviewed-by: Steven Price Reviewed-by: Alyssa Rosenzweig Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-3-narmstrong@baylibre.com Signed-off-by: Sasha Levin commit d51054452691f2ae4fcd05126d8defea14890734 Author: Neil Armstrong Date: Wed Sep 16 17:01:47 2020 +0200 drm/panfrost: add Amlogic GPU integration quirks [ Upstream commit afcd0c7d3d4c22afc8befcfc906db6ce3058d3ee ] This adds the required GPU quirks, including the quirk in the PWR registers at the GPU reset time and the IOMMU quirk for shareability issues observed on G52 in Amlogic G12B SoCs. Signed-off-by: Neil Armstrong Reviewed-by: Steven Price Reviewed-by: Alyssa Rosenzweig Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-4-narmstrong@baylibre.com Signed-off-by: Sasha Levin commit 2d72d5ce63c92f56b9f978e8befb5838144176b9 Author: Brooke Basile Date: Fri Sep 11 03:14:27 2020 -0400 ath9k: hif_usb: fix race condition between usb_get_urb() and usb_kill_anchored_urbs() [ Upstream commit 03fb92a432ea5abe5909bca1455b7e44a9380480 ] Calls to usb_kill_anchored_urbs() after usb_kill_urb() on multiprocessor systems create a race condition in which usb_kill_anchored_urbs() deallocates the URB before the completer callback is called in usb_kill_urb(), resulting in a use-after-free. To fix this, add proper lock protection to usb_kill_urb() calls that can possibly run concurrently with usb_kill_anchored_urbs(). Reported-by: syzbot+89bd486af9427a9fc605@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=cabffad18eb74197f84871802fd2c5117b61febf Signed-off-by: Brooke Basile Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200911071427.32354-1-brookebasile@gmail.com Signed-off-by: Sasha Levin commit ce4d9051eff34b85c3c35e8a5b88d1154ae4055f Author: Mikael Wikström Date: Tue Sep 22 11:48:10 2020 +0200 HID: multitouch: Lenovo X1 Tablet Gen3 trackpoint and buttons [ Upstream commit 140958da9ab53a7df9e9ccc7678ea64655279ac1 ] One more device that needs 40d5bb87 to resolve regression for the trackpoint and three mouse buttons on the type cover of the Lenovo X1 Tablet Gen3. It is probably also needed for the Lenovo X1 Tablet Gen2 with PID 0x60a3 Signed-off-by: Mikael Wikström Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 3555defb1f5272fd1bf750017be3e442e28ffe0e Author: Joakim Zhang Date: Tue Sep 22 16:44:19 2020 +0200 can: flexcan: flexcan_chip_stop(): add error handling and propagate error value [ Upstream commit 9ad02c7f4f279504bdd38ab706fdc97d5f2b2a9c ] This patch implements error handling and propagates the error value of flexcan_chip_stop(). This function will be called from flexcan_suspend() in an upcoming patch in some SoCs which support LPSR mode. Add a new function flexcan_chip_stop_disable_on_error() that tries to disable the chip even in case of errors. Signed-off-by: Joakim Zhang [mkl: introduce flexcan_chip_stop_disable_on_error() and use it in flexcan_close()] Signed-off-by: Marc Kleine-Budde Link: https://lore.kernel.org/r/20200922144429.2613631-11-mkl@pengutronix.de Signed-off-by: Sasha Levin commit eb46fbcde26dc5b51c878fbe3789bbb158dceed6 Author: Oded Gabbay Date: Sat Aug 29 11:24:03 2020 +0300 habanalabs: cast to u64 before shift > 31 bits [ Upstream commit f763946aefe67b3ea58696b75a930ba1ed886a83 ] When shifting a boolean variable by more than 31 bits and putting the result into a u64 variable, we need to cast the boolean into unsigned 64 bits to prevent possible overflow. Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 411df177e50625af701b57972719b9a7f1eadb91 Author: Mauro Carvalho Chehab Date: Tue Sep 8 11:58:23 2020 +0200 usb: dwc3: simple: add support for Hikey 970 [ Upstream commit b68d9251561f33661e53dd618f1cafe7ec9ec3c2 ] This binding driver is needed for Hikey 970 to work, as otherwise a Serror is produced: [ 1.837458] SError Interrupt on CPU0, code 0xbf000002 -- SError [ 1.837462] CPU: 0 PID: 74 Comm: kworker/0:1 Not tainted 5.8.0+ #205 [ 1.837463] Hardware name: HiKey970 (DT) [ 1.837465] Workqueue: events deferred_probe_work_func [ 1.837467] pstate: 20000005 (nzCv daif -PAN -UAO BTYPE=--) [ 1.837468] pc : _raw_spin_unlock_irqrestore+0x18/0x50 [ 1.837469] lr : regmap_unlock_spinlock+0x14/0x20 [ 1.837470] sp : ffff8000124dba60 [ 1.837471] x29: ffff8000124dba60 x28: 0000000000000000 [ 1.837474] x27: ffff0001b7e854c8 x26: ffff80001204ea18 [ 1.837476] x25: 0000000000000005 x24: ffff800011f918f8 [ 1.837479] x23: ffff800011fbb588 x22: ffff0001b7e40e00 [ 1.837481] x21: 0000000000000100 x20: 0000000000000000 [ 1.837483] x19: ffff0001b767ec00 x18: 00000000ff10c000 [ 1.837485] x17: 0000000000000002 x16: 0000b0740fdb9950 [ 1.837488] x15: ffff8000116c1198 x14: ffffffffffffffff [ 1.837490] x13: 0000000000000030 x12: 0101010101010101 [ 1.837493] x11: 0000000000000020 x10: ffff0001bf17d130 [ 1.837495] x9 : 0000000000000000 x8 : ffff0001b6938080 [ 1.837497] x7 : 0000000000000000 x6 : 000000000000003f [ 1.837500] x5 : 0000000000000000 x4 : 0000000000000000 [ 1.837502] x3 : ffff80001096a880 x2 : 0000000000000000 [ 1.837505] x1 : ffff0001b7e40e00 x0 : 0000000100000001 [ 1.837507] Kernel panic - not syncing: Asynchronous SError Interrupt [ 1.837509] CPU: 0 PID: 74 Comm: kworker/0:1 Not tainted 5.8.0+ #205 [ 1.837510] Hardware name: HiKey970 (DT) [ 1.837511] Workqueue: events deferred_probe_work_func [ 1.837513] Call trace: [ 1.837514] dump_backtrace+0x0/0x1e0 [ 1.837515] show_stack+0x18/0x24 [ 1.837516] dump_stack+0xc0/0x11c [ 1.837517] panic+0x15c/0x324 [ 1.837518] nmi_panic+0x8c/0x90 [ 1.837519] arm64_serror_panic+0x78/0x84 [ 1.837520] do_serror+0x158/0x15c [ 1.837521] el1_error+0x84/0x100 [ 1.837522] _raw_spin_unlock_irqrestore+0x18/0x50 [ 1.837523] regmap_write+0x58/0x80 [ 1.837524] hi3660_reset_deassert+0x28/0x34 [ 1.837526] reset_control_deassert+0x50/0x260 [ 1.837527] reset_control_deassert+0xf4/0x260 [ 1.837528] dwc3_probe+0x5dc/0xe6c [ 1.837529] platform_drv_probe+0x54/0xb0 [ 1.837530] really_probe+0xe0/0x490 [ 1.837531] driver_probe_device+0xf4/0x160 [ 1.837532] __device_attach_driver+0x8c/0x114 [ 1.837533] bus_for_each_drv+0x78/0xcc [ 1.837534] __device_attach+0x108/0x1a0 [ 1.837535] device_initial_probe+0x14/0x20 [ 1.837537] bus_probe_device+0x98/0xa0 [ 1.837538] deferred_probe_work_func+0x88/0xe0 [ 1.837539] process_one_work+0x1cc/0x350 [ 1.837540] worker_thread+0x2c0/0x470 [ 1.837541] kthread+0x154/0x160 [ 1.837542] ret_from_fork+0x10/0x30 [ 1.837569] SMP: stopping secondary CPUs [ 1.837570] Kernel Offset: 0x1d0000 from 0xffff800010000000 [ 1.837571] PHYS_OFFSET: 0x0 [ 1.837572] CPU features: 0x240002,20882004 [ 1.837573] Memory Limit: none Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 6a8ca120abb15f8ff159d2f16461bfa2e9400937 Author: Felix Fietkau Date: Fri Aug 7 20:57:46 2020 +0200 mt76: mt7915: do not do any work in napi poll after calling napi_complete_done() [ Upstream commit 38b04398c532e9bb9aa90fc07846ad0b0845fe94 ] Fixes a race condition where multiple tx cleanup or sta poll tasks could run in parallel. Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 326808282791f0ff11c3bba85913f17622019db1 Author: Johan Hovold Date: Mon Sep 21 15:59:49 2020 +0200 USB: cdc-acm: handle broken union descriptors [ Upstream commit 960c7339de27c6d6fec13b54880501c3576bb08d ] Handle broken union functional descriptors where the master-interface doesn't exist or where its class is of neither Communication or Data type (as required by the specification) by falling back to "combined-interface" probing. Note that this still allows for handling union descriptors with switched interfaces. This specifically makes the Whistler radio scanners TRX series devices work with the driver without adding further quirks to the device-id table. Reported-by: Daniel Caujolle-Bert Tested-by: Daniel Caujolle-Bert Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20200921135951.24045-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0a359512257ffabb43c7c713c20f2c287ae1ca17 Author: Tzu-En Huang Date: Fri Sep 25 14:12:15 2020 +0800 rtw88: increse the size of rx buffer size [ Upstream commit ee755732b7a16af018daa77d9562d2493fb7092f ] The vht capability of MAX_MPDU_LENGTH is 11454 in rtw88; however, the rx buffer size for each packet is 8192. When receiving packets that are larger than rx buffer size, it will leads to rx buffer ring overflow. Signed-off-by: Tzu-En Huang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200925061219.23754-2-tehuang@realtek.com Signed-off-by: Sasha Levin commit fc9db7fbbf6238ef22e684c29894a4d76911943e Author: Jan Kara Date: Fri Sep 25 12:14:03 2020 +0200 udf: Avoid accessing uninitialized data on failed inode read [ Upstream commit 044e2e26f214e5ab26af85faffd8d1e4ec066931 ] When we fail to read inode, some data accessed in udf_evict_inode() may be uninitialized. Move the accesses to !is_bad_inode() branch. Reported-by: syzbot+91f02b28f9bb5f5f1341@syzkaller.appspotmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 310594d44c3d66c0472054ec4017243c2d4f8339 Author: Jan Kara Date: Fri Sep 25 14:53:08 2020 +0200 udf: Limit sparing table size [ Upstream commit 44ac6b829c4e173fdf6df18e6dd86aecf9a3dc99 ] Although UDF standard allows it, we don't support sparing table larger than a single block. Check it during mount so that we don't try to access memory beyond end of buffer. Reported-by: syzbot+9991561e714f597095da@syzkaller.appspotmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit dcef4a11ad7d7a9c2c907a002415751fa2ed1cd0 Author: Kai-Heng Feng Date: Tue Sep 29 00:55:08 2020 +0800 rtw88: pci: Power cycle device during shutdown [ Upstream commit 44492e70adc8086c42d3745d21d591657a427f04 ] There are reports that 8822CE fails to work rtw88 with "failed to read DBI register" error. Also I have a system with 8723DE which freezes the whole system when the rtw88 is probing the device. According to [1], platform firmware may not properly power manage the device during shutdown. I did some expirements and putting the device to D3 can workaround the issue. So let's power cycle the device by putting the device to D3 at shutdown to prevent the issue from happening. [1] https://bugzilla.kernel.org/show_bug.cgi?id=206411#c9 BugLink: https://bugs.launchpad.net/bugs/1872984 Signed-off-by: Kai-Heng Feng Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200928165508.20775-1-kai.heng.feng@canonical.com Signed-off-by: Sasha Levin commit 5f845e5d18d151230476cf90aa46449f69ba2ef1 Author: Zqiang Date: Fri Jun 5 11:05:33 2020 +0800 usb: gadget: function: printer: fix use-after-free in __lock_acquire [ Upstream commit e8d5f92b8d30bb4ade76494490c3c065e12411b1 ] Fix this by increase object reference count. BUG: KASAN: use-after-free in __lock_acquire+0x3fd4/0x4180 kernel/locking/lockdep.c:3831 Read of size 8 at addr ffff8880683b0018 by task syz-executor.0/3377 CPU: 1 PID: 3377 Comm: syz-executor.0 Not tainted 5.6.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374 __kasan_report+0x131/0x1b0 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:641 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 __lock_acquire+0x3fd4/0x4180 kernel/locking/lockdep.c:3831 lock_acquire+0x127/0x350 kernel/locking/lockdep.c:4488 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 printer_ioctl+0x4a/0x110 drivers/usb/gadget/function/f_printer.c:723 vfs_ioctl fs/ioctl.c:47 [inline] ksys_ioctl+0xfb/0x130 fs/ioctl.c:763 __do_sys_ioctl fs/ioctl.c:772 [inline] __se_sys_ioctl fs/ioctl.c:770 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:770 do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4531a9 Code: ed 60 fc ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 bb 60 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fd14ad72c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000000073bfa8 RCX: 00000000004531a9 RDX: fffffffffffffff9 RSI: 000000000000009e RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004bbd61 R13: 00000000004d0a98 R14: 00007fd14ad736d4 R15: 00000000ffffffff Allocated by task 2393: save_stack+0x21/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc.constprop.3+0xa7/0xd0 mm/kasan/common.c:515 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 kmem_cache_alloc_trace+0xfa/0x2d0 mm/slub.c:2813 kmalloc include/linux/slab.h:555 [inline] kzalloc include/linux/slab.h:669 [inline] gprinter_alloc+0xa1/0x870 drivers/usb/gadget/function/f_printer.c:1416 usb_get_function+0x58/0xc0 drivers/usb/gadget/functions.c:61 config_usb_cfg_link+0x1ed/0x3e0 drivers/usb/gadget/configfs.c:444 configfs_symlink+0x527/0x11d0 fs/configfs/symlink.c:202 vfs_symlink+0x33d/0x5b0 fs/namei.c:4201 do_symlinkat+0x11b/0x1d0 fs/namei.c:4228 __do_sys_symlinkat fs/namei.c:4242 [inline] __se_sys_symlinkat fs/namei.c:4239 [inline] __x64_sys_symlinkat+0x73/0xb0 fs/namei.c:4239 do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 3368: save_stack+0x21/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:337 [inline] __kasan_slab_free+0x135/0x190 mm/kasan/common.c:476 kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 slab_free_hook mm/slub.c:1444 [inline] slab_free_freelist_hook mm/slub.c:1477 [inline] slab_free mm/slub.c:3034 [inline] kfree+0xf7/0x410 mm/slub.c:3995 gprinter_free+0x49/0xd0 drivers/usb/gadget/function/f_printer.c:1353 usb_put_function+0x38/0x50 drivers/usb/gadget/functions.c:87 config_usb_cfg_unlink+0x2db/0x3b0 drivers/usb/gadget/configfs.c:485 configfs_unlink+0x3b9/0x7f0 fs/configfs/symlink.c:250 vfs_unlink+0x287/0x570 fs/namei.c:4073 do_unlinkat+0x4f9/0x620 fs/namei.c:4137 __do_sys_unlink fs/namei.c:4184 [inline] __se_sys_unlink fs/namei.c:4182 [inline] __x64_sys_unlink+0x42/0x50 fs/namei.c:4182 do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8880683b0000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 24 bytes inside of 1024-byte region [ffff8880683b0000, ffff8880683b0400) The buggy address belongs to the page: page:ffffea0001a0ec00 refcount:1 mapcount:0 mapping:ffff88806c00e300 index:0xffff8880683b1800 compound_mapcount: 0 flags: 0x100000000010200(slab|head) raw: 0100000000010200 0000000000000000 0000000600000001 ffff88806c00e300 raw: ffff8880683b1800 000000008010000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Reported-by: Kyungtae Kim Signed-off-by: Zqiang Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit f815885d31d4d495a11d1250d4969831d6afc7a5 Author: Yu Chen Date: Tue Sep 8 09:20:56 2020 +0200 usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc [ Upstream commit f580170f135af14e287560d94045624d4242d712 ] SPLIT_BOUNDARY_DISABLE should be set for DesignWare USB3 DRD Core of Hisilicon Kirin Soc when dwc3 core act as host. [mchehab: dropped a dev_dbg() as only traces are now allowwed on this driver] Signed-off-by: Yu Chen Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 3ad452709d4bf1587db01fb4aa298d31c82250e3 Author: Sherry Sun Date: Tue Sep 29 17:11:05 2020 +0800 misc: vop: add round_up(x,4) for vring_size to avoid kernel panic [ Upstream commit cc1a2679865a94b83804822996eed010a50a7c1d ] Since struct _mic_vring_info and vring are allocated together and follow vring, if the vring_size() is not four bytes aligned, which will cause the start address of struct _mic_vring_info is not four byte aligned. For example, when vring entries is 128, the vring_size() will be 5126 bytes. The _mic_vring_info struct layout in ddr looks like: 0x90002400: 00000000 00390000 EE010000 0000C0FF Here 0x39 is the avail_idx member, and 0xC0FFEE01 is the magic member. When EP use ioread32(magic) to reads the magic in RC's share memory, it will cause kernel panic on ARM64 platform due to the cross-byte io read. Here read magic in user space use le32toh(vr0->info->magic) will meet the same issue. So add round_up(x,4) for vring_size, then the struct _mic_vring_info will store in this way: 0x90002400: 00000000 00000000 00000039 C0FFEE01 Which will avoid kernel panic when read magic in struct _mic_vring_info. Signed-off-by: Sherry Sun Signed-off-by: Joakim Zhang Link: https://lore.kernel.org/r/20200929091106.24624-4-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6f36edecd429e1eab6c23733324241fedbbb1e51 Author: Sherry Sun Date: Tue Sep 29 17:11:06 2020 +0800 mic: vop: copy data to kernel space then write to io memory [ Upstream commit 675f0ad4046946e80412896436164d172cd92238 ] Read and write io memory should address align on ARCH ARM. Change to use memcpy_toio to avoid kernel panic caused by the address un-align issue. Signed-off-by: Sherry Sun Signed-off-by: Joakim Zhang Link: https://lore.kernel.org/r/20200929091106.24624-5-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 40cd98e3f849139a696b519b92284f0b8d0fb111 Author: Roman Bolshakov Date: Tue Sep 29 15:59:57 2020 +0300 scsi: target: core: Add CONTROL field for trace events [ Upstream commit 7010645ba7256992818b518163f46bd4cdf8002a ] trace-cmd report doesn't show events from target subsystem because scsi_command_size() leaks through event format string: [target:target_sequencer_start] function scsi_command_size not defined [target:target_cmd_complete] function scsi_command_size not defined Addition of scsi_command_size() to plugin_scsi.c in trace-cmd doesn't help because an expression is used inside TP_printk(). trace-cmd event parser doesn't understand minus sign inside [ ]: Error: expected ']' but read '-' Rather than duplicating kernel code in plugin_scsi.c, provide a dedicated field for CONTROL byte. Link: https://lore.kernel.org/r/20200929125957.83069-1-r.bolshakov@yadro.com Reviewed-by: Mike Christie Signed-off-by: Roman Bolshakov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit eed3b45a4c87a6e7c4e8f87aee02735e7211ea18 Author: Jing Xiangfeng Date: Thu Sep 10 20:38:48 2020 +0800 scsi: mvumi: Fix error return in mvumi_io_attach() [ Upstream commit 055f15ab2cb4a5cbc4c0a775ef3d0066e0fa9b34 ] Return PTR_ERR() from the error handling case instead of 0. Link: https://lore.kernel.org/r/20200910123848.93649-1-jingxiangfeng@huawei.com Signed-off-by: Jing Xiangfeng Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1f93897dd7801388a6cbcc82011c150f88a18988 Author: Christoph Hellwig Date: Fri Sep 25 18:14:47 2020 +0200 PM: hibernate: remove the bogus call to get_gendisk() in software_resume() [ Upstream commit 428805c0c5e76ef643b1fbc893edfb636b3d8aef ] get_gendisk grabs a reference on the disk and file operation, so this code will leak both of them while having absolutely no use for the gendisk itself. This effectively reverts commit 2df83fa4bce421f ("PM / Hibernate: Use get_gendisk to verify partition if resume_file is integer format") Signed-off-by: Christoph Hellwig Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 3799cc62513a58f314ebdde8efe2c9fbfedfd4ff Author: Song Liu Date: Mon Oct 5 09:58:38 2020 -0700 bpf: Use raw_spin_trylock() for pcpu_freelist_push/pop in NMI [ Upstream commit 39d8f0d1026a990604770a658708f5845f7dbec0 ] Recent improvements in LOCKDEP highlighted a potential A-A deadlock with pcpu_freelist in NMI: ./tools/testing/selftests/bpf/test_progs -t stacktrace_build_id_nmi [ 18.984807] ================================ [ 18.984807] WARNING: inconsistent lock state [ 18.984808] 5.9.0-rc6-01771-g1466de1330e1 #2967 Not tainted [ 18.984809] -------------------------------- [ 18.984809] inconsistent {INITIAL USE} -> {IN-NMI} usage. [ 18.984810] test_progs/1990 [HC2[2]:SC0[0]:HE0:SE1] takes: [ 18.984810] ffffe8ffffc219c0 (&head->lock){....}-{2:2}, at: __pcpu_freelist_pop+0xe3/0x180 [ 18.984813] {INITIAL USE} state was registered at: [ 18.984814] lock_acquire+0x175/0x7c0 [ 18.984814] _raw_spin_lock+0x2c/0x40 [ 18.984815] __pcpu_freelist_pop+0xe3/0x180 [ 18.984815] pcpu_freelist_pop+0x31/0x40 [ 18.984816] htab_map_alloc+0xbbf/0xf40 [ 18.984816] __do_sys_bpf+0x5aa/0x3ed0 [ 18.984817] do_syscall_64+0x2d/0x40 [ 18.984818] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 18.984818] irq event stamp: 12 [...] [ 18.984822] other info that might help us debug this: [ 18.984823] Possible unsafe locking scenario: [ 18.984823] [ 18.984824] CPU0 [ 18.984824] ---- [ 18.984824] lock(&head->lock); [ 18.984826] [ 18.984826] lock(&head->lock); [ 18.984827] [ 18.984828] *** DEADLOCK *** [ 18.984828] [ 18.984829] 2 locks held by test_progs/1990: [...] [ 18.984838] [ 18.984838] dump_stack+0x9a/0xd0 [ 18.984839] lock_acquire+0x5c9/0x7c0 [ 18.984839] ? lock_release+0x6f0/0x6f0 [ 18.984840] ? __pcpu_freelist_pop+0xe3/0x180 [ 18.984840] _raw_spin_lock+0x2c/0x40 [ 18.984841] ? __pcpu_freelist_pop+0xe3/0x180 [ 18.984841] __pcpu_freelist_pop+0xe3/0x180 [ 18.984842] pcpu_freelist_pop+0x17/0x40 [ 18.984842] ? lock_release+0x6f0/0x6f0 [ 18.984843] __bpf_get_stackid+0x534/0xaf0 [ 18.984843] bpf_prog_1fd9e30e1438d3c5_oncpu+0x73/0x350 [ 18.984844] bpf_overflow_handler+0x12f/0x3f0 This is because pcpu_freelist_head.lock is accessed in both NMI and non-NMI context. Fix this issue by using raw_spin_trylock() in NMI. Since NMI interrupts non-NMI context, when NMI context tries to lock the raw_spinlock, non-NMI context of the same CPU may already have locked a lock and is blocked from unlocking the lock. For a system with N CPUs, there could be N NMIs at the same time, and they may block N non-NMI raw_spinlocks. This is tricky for pcpu_freelist_push(), where unlike _pop(), failing _push() means leaking memory. This issue is more likely to trigger in non-SMP system. Fix this issue with an extra list, pcpu_freelist.extralist. The extralist is primarily used to take _push() when raw_spin_trylock() failed on all the per CPU lists. It should be empty most of the time. The following table summarizes the behavior of pcpu_freelist in NMI and non-NMI: non-NMI pop(): use _lock(); check per CPU lists first; if all per CPU lists are empty, check extralist; if extralist is empty, return NULL. non-NMI push(): use _lock(); only push to per CPU lists. NMI pop(): use _trylock(); check per CPU lists first; if all per CPU lists are locked or empty, check extralist; if extralist is locked or empty, return NULL. NMI push(): use _trylock(); check per CPU lists first; if all per CPU lists are locked; try push to extralist; if extralist is also locked, keep trying on per CPU lists. Reported-by: Alexei Starovoitov Signed-off-by: Song Liu Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20201005165838.3735218-1-songliubraving@fb.com Signed-off-by: Sasha Levin commit 400e22b00d06db1a9d410835511220726697b741 Author: Hangbin Liu Date: Tue Oct 6 10:13:43 2020 +0800 libbpf: Close map fd if init map slots failed [ Upstream commit a0f2b7acb4b1d29127ff99c714233b973afd1411 ] Previously we forgot to close the map fd if bpf_map_update_elem() failed during map slot init, which will leak map fd. Let's move map slot initialization to new function init_map_slots() to simplify the code. And close the map fd if init slot failed. Reported-by: Andrii Nakryiko Signed-off-by: Hangbin Liu Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20201006021345.3817033-2-liuhangbin@gmail.com Signed-off-by: Sasha Levin commit 5d6f53b24cacb39580630147d45968bceca38816 Author: Jérôme Pouiller Date: Wed Oct 7 12:19:37 2020 +0200 staging: wfx: fix handling of MMIC error [ Upstream commit 8d350c14ee5eb62ecd40b0991248bfbce511954d ] As expected, when the device detect a MMIC error, it returns a specific status. However, it also strip IV from the frame (don't ask me why). So, with the current code, mac80211 detects a corrupted frame and it drops it before it handle the MMIC error. The expected behavior would be to detect MMIC error then to renegotiate the EAP session. So, this patch correctly informs mac80211 that IV is not available. So, mac80211 correctly takes into account the MMIC error. Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20201007101943.749898-2-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c2481f8fe441156355b534fa2523646d1b8e599c Author: Thomas Pedersen Date: Mon Oct 5 09:45:21 2020 -0700 mac80211: handle lack of sband->bitrates in rates [ Upstream commit 8b783d104e7f40684333d2ec155fac39219beb2f ] Even though a driver or mac80211 shouldn't produce a legacy bitrate if sband->bitrates doesn't exist, don't crash if that is the case either. This fixes a kernel panic if station dump is run before last_rate can be updated with a data frame when sband->bitrates is missing (eg. in S1G bands). Signed-off-by: Thomas Pedersen Link: https://lore.kernel.org/r/20201005164522.18069-1-thomas@adapt-ip.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 79e39a265e91dc5db109eb78c7510920e4e62d6a Author: Cong Wang Date: Mon Oct 12 16:17:21 2020 -0700 ip_gre: set dev->hard_header_len and dev->needed_headroom properly [ Upstream commit fdafed459998e2be0e877e6189b24cb7a0183224 ] GRE tunnel has its own header_ops, ipgre_header_ops, and sets it conditionally. When it is set, it assumes the outer IP header is already created before ipgre_xmit(). This is not true when we send packets through a raw packet socket, where L2 headers are supposed to be constructed by user. Packet socket calls dev_validate_header() to validate the header. But GRE tunnel does not set dev->hard_header_len, so that check can be simply bypassed, therefore uninit memory could be passed down to ipgre_xmit(). Similar for dev->needed_headroom. dev->hard_header_len is supposed to be the length of the header created by dev->header_ops->create(), so it should be used whenever header_ops is set, and dev->needed_headroom should be used when it is not set. Reported-and-tested-by: syzbot+4a2c52677a8a1aa283cb@syzkaller.appspotmail.com Cc: William Tu Acked-by: Willem de Bruijn Signed-off-by: Cong Wang Acked-by: Xie He Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 709ea7f285aa32d7e8eda94df7c6fa1ae7dc9a7d Author: Rustam Kovhaev Date: Tue Oct 13 16:48:17 2020 -0700 ntfs: add check for mft record size in superblock [ Upstream commit 4f8c94022f0bc3babd0a124c0a7dcdd7547bd94e ] Number of bytes allocated for mft record should be equal to the mft record size stored in ntfs superblock as reported by syzbot, userspace might trigger out-of-bounds read by dereferencing ctx->attr in ntfs_attr_find() Reported-by: syzbot+aed06913f36eff9b544e@syzkaller.appspotmail.com Signed-off-by: Rustam Kovhaev Signed-off-by: Andrew Morton Tested-by: syzbot+aed06913f36eff9b544e@syzkaller.appspotmail.com Acked-by: Anton Altaparmakov Link: https://syzkaller.appspot.com/bug?extid=aed06913f36eff9b544e Link: https://lkml.kernel.org/r/20200824022804.226242-1-rkovhaev@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ee02c932d21a3beaff688c6e5eb9ab238131f2fc Author: Dinghao Liu Date: Sun Jun 28 07:55:23 2020 +0200 media: venus: core: Fix runtime PM imbalance in venus_probe [ Upstream commit bbe516e976fce538db96bd2b7287df942faa14a3 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. For other error paths after this call, things are the same. Fix this by adding pm_runtime_put_noidle() after 'err_runtime_disable' label. But in this case, the error path after pm_runtime_put_sync() will decrease PM usage counter twice. Thus add an extra pm_runtime_get_noresume() in this path to balance PM counter. Signed-off-by: Dinghao Liu Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 190e3a143abc08e2163a80c3d01ad04305c8f955 Author: Rajendra Nayak Date: Wed Jul 29 09:16:42 2020 +0200 media: venus: core: Fix error handling in probe [ Upstream commit 98cd831088c64aa8fe7e1d2a8bb94b6faba0462b ] Post a successful pm_ops->core_get, an error in probe should exit by doing a pm_ops->core_put which seems to be missing. So fix it. Signed-off-by: Rajendra Nayak Reviewed-by: Bjorn Andersson Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1285eef9d69764ba59429241ae03035b078aef27 Author: Alexander Aring Date: Thu Aug 27 15:02:51 2020 -0400 fs: dlm: fix configfs memory leak [ Upstream commit 3d2825c8c6105b0f36f3ff72760799fa2e71420e ] This patch fixes the following memory detected by kmemleak and umount gfs2 filesystem which removed the last lockspace: unreferenced object 0xffff9264f482f600 (size 192): comm "dlm_controld", pid 325, jiffies 4294690276 (age 48.136s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 6e 6f 64 65 73 00 00 00 ........nodes... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000060481d7>] make_space+0x41/0x130 [<000000008d905d46>] configfs_mkdir+0x1a2/0x5f0 [<00000000729502cf>] vfs_mkdir+0x155/0x210 [<000000000369bcf1>] do_mkdirat+0x6d/0x110 [<00000000cc478a33>] do_syscall_64+0x33/0x40 [<00000000ce9ccf01>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 The patch just remembers the "nodes" entry pointer in space as I think it's created as subdirectory when parent "spaces" is created. In function drop_space() we will lost the pointer reference to nds because configfs_remove_default_groups(). However as this subdirectory is always available when "spaces" exists it will just be freed when "spaces" will be freed. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 1dd1cbcaa7241c3ee079f7f5c202210c9399070c Author: Peter Zijlstra Date: Tue Aug 18 15:57:36 2020 +0200 notifier: Fix broken error handling pattern [ Upstream commit 70d932985757fbe978024db313001218e9f8fe5c ] The current notifiers have the following error handling pattern all over the place: int err, nr; err = __foo_notifier_call_chain(&chain, val_up, v, -1, &nr); if (err & NOTIFIER_STOP_MASK) __foo_notifier_call_chain(&chain, val_down, v, nr-1, NULL) And aside from the endless repetition thereof, it is broken. Consider blocking notifiers; both calls take and drop the rwsem, this means that the notifier list can change in between the two calls, making @nr meaningless. Fix this by replacing all the __foo_notifier_call_chain() functions with foo_notifier_call_chain_robust() that embeds the above pattern, but ensures it is inside a single lock region. Note: I switched atomic_notifier_call_chain_robust() to use the spinlock, since RCU cannot provide the guarantee required for the recovery. Note: software_resume() error handling was broken afaict. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20200818135804.325626653@infradead.org Signed-off-by: Sasha Levin commit d259c4da36247e2c9a222efce56d36d89cc389d5 Author: Vikash Garodia Date: Tue Aug 4 13:48:45 2020 +0200 media: venus: fixes for list corruption [ Upstream commit e1c69c4eef61ffe295b747992c6fd849e6cd747d ] There are few list handling issues while adding and deleting node in the registered buf list in the driver. 1. list addition - buffer added into the list during buf_init while not deleted during cleanup. 2. list deletion - In capture streamoff, the list was reinitialized. As a result, if any node was present in the list, it would lead to issue while cleaning up that node during buf_cleanup. Corresponding call traces below: [ 165.751014] Call trace: [ 165.753541] __list_add_valid+0x58/0x88 [ 165.757532] venus_helper_vb2_buf_init+0x74/0xa8 [venus_core] [ 165.763450] vdec_buf_init+0x34/0xb4 [venus_dec] [ 165.768271] __buf_prepare+0x598/0x8a0 [videobuf2_common] [ 165.773820] vb2_core_qbuf+0xb4/0x334 [videobuf2_common] [ 165.779298] vb2_qbuf+0x78/0xb8 [videobuf2_v4l2] [ 165.784053] v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem] [ 165.789067] v4l2_m2m_ioctl_qbuf+0x2c/0x38 [v4l2_mem2mem] [ 165.794624] v4l_qbuf+0x48/0x58 [ 1797.556001] Call trace: [ 1797.558516] __list_del_entry_valid+0x88/0x9c [ 1797.562989] vdec_buf_cleanup+0x54/0x228 [venus_dec] [ 1797.568088] __buf_prepare+0x270/0x8a0 [videobuf2_common] [ 1797.573625] vb2_core_qbuf+0xb4/0x338 [videobuf2_common] [ 1797.579082] vb2_qbuf+0x78/0xb8 [videobuf2_v4l2] [ 1797.583830] v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem] [ 1797.588843] v4l2_m2m_ioctl_qbuf+0x2c/0x38 [v4l2_mem2mem] [ 1797.594389] v4l_qbuf+0x48/0x58 Signed-off-by: Vikash Garodia Reviewed-by: Fritz Koenig Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a966c457e61d34e3052f81d932b51216f64f976f Author: Dinghao Liu Date: Fri Aug 21 07:49:16 2020 +0200 media: atomisp: fix memleak in ia_css_stream_create [ Upstream commit c1bca5b5ced0cbd779d56f60cdbc9f5e6f6449fe ] When aspect_ratio_crop_init() fails, curr_stream needs to be freed just like what we've done in the following error paths. However, current code is returning directly and ends up leaking memory. Signed-off-by: Dinghao Liu Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ba7a8eed706db7a1fe18b5150758bc5a00d8f487 Author: Mauro Carvalho Chehab Date: Wed Sep 2 08:37:12 2020 +0200 media: saa7134: avoid a shift overflow [ Upstream commit 15a36aae1ec1c1f17149b6113b92631791830740 ] As reported by smatch: drivers/media/pci/saa7134//saa7134-tvaudio.c:686 saa_dsp_writel() warn: should 'reg << 2' be a 64 bit type? On a 64-bits Kernel, the shift might be bigger than 32 bits. In real, this should never happen, but let's shut up the warning. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fa0a1c79c0028c5724d89c3d38b47ca9c322966c Author: Pali Rohár Date: Mon Jul 27 15:38:34 2020 +0200 mmc: sdio: Check for CISTPL_VERS_1 buffer size [ Upstream commit 8ebe2607965d3e2dc02029e8c7dd35fbe508ffd0 ] Before parsing CISTPL_VERS_1 structure check that its size is at least two bytes to prevent buffer overflow. Signed-off-by: Pali Rohár Link: https://lore.kernel.org/r/20200727133837.19086-2-pali@kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ec650318ebb7f7a75f86ce3cdc6d86baa2ebc913 Author: Adam Goode Date: Sun Aug 23 03:21:33 2020 +0200 media: uvcvideo: Ensure all probed info is returned to v4l2 [ Upstream commit 8a652a17e3c005dcdae31b6c8fdf14382a29cbbe ] bFrameIndex and bFormatIndex can be negotiated by the camera during probing, resulting in the camera choosing a different format than expected. v4l2 can already accommodate such changes, but the code was not updating the proper fields. Without such a change, v4l2 would potentially interpret the payload incorrectly, causing corrupted output. This was happening on the Elgato HD60 S+, which currently always renegotiates to format 1. As an aside, the Elgato firmware is buggy and should not be renegotating, but it is still a valid thing for the camera to do. Both macOS and Windows will properly probe and read uncorrupted images from this camera. With this change, both qv4l2 and chromium can now read uncorrupted video from the Elgato HD60 S+. [Add blank lines, remove periods at the of messages] Signed-off-by: Adam Goode Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 9a0dc5e66c30c6039bc4bd15c486455448ab41f5 Author: Borislav Petkov Date: Sun Sep 6 23:02:52 2020 +0200 x86/mce: Make mce_rdmsrl() panic on an inaccessible MSR [ Upstream commit e2def7d49d0812ea40a224161b2001b2e815dce2 ] If an exception needs to be handled while reading an MSR - which is in most of the cases caused by a #GP on a non-existent MSR - then this is most likely the incarnation of a BIOS or a hardware bug. Such bug violates the architectural guarantee that MCA banks are present with all MSRs belonging to them. The proper fix belongs in the hardware/firmware - not in the kernel. Handling an #MC exception which is raised while an NMI is being handled would cause the nasty NMI nesting issue because of the shortcoming of IRET of reenabling NMIs when executed. And the machine is in an #MC context already so be at its side. Tracing MSR accesses while in #MC is another no-no due to tracing being inherently a bad idea in atomic context: vmlinux.o: warning: objtool: do_machine_check()+0x4a: call to mce_rdmsrl() leaves .noinstr.text section so remove all that "additional" functionality from mce_rdmsrl() and provide it with a special exception handler which panics the machine when that MSR is not accessible. The exception handler prints a human-readable message explaining what the panic reason is but, what is more, it panics while in the #GP handler and latter won't have executed an IRET, thus opening the NMI nesting issue in the case when the #MC has happened while handling an NMI. (#MC itself won't be reenabled until MCG_STATUS hasn't been cleared). Suggested-by: Andy Lutomirski Suggested-by: Peter Zijlstra [ Add missing prototypes for ex_handler_* ] Reported-by: kernel test robot Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Link: https://lkml.kernel.org/r/20200906212130.GA28456@zn.tnic Signed-off-by: Sasha Levin commit b2a934c571420663c3b23add925b71f8de8283e3 Author: Ming Lei Date: Fri Sep 11 18:41:14 2020 +0800 blk-mq: always allow reserved allocation in hctx_may_queue [ Upstream commit 285008501c65a3fcee05d2c2c26cbf629ceff2f0 ] NVMe shares tagset between fabric queue and admin queue or between connect_q and NS queue, so hctx_may_queue() can be called to allocate request for these queues. Tags can be reserved in these tagset. Before error recovery, there is often lots of in-flight requests which can't be completed, and new reserved request may be needed in error recovery path. However, hctx_may_queue() can always return false because there is too many in-flight requests which can't be completed during error handling. Finally, nothing can proceed. Fix this issue by always allowing reserved tag allocation in hctx_may_queue(). This is reasonable because reserved tags are supposed to always be available. Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Cc: David Milburn Cc: Ewan D. Milne Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 020b700552021a50b64854ad6b8464e4c4808244 Author: Brad Bishop Date: Wed Sep 9 17:28:53 2020 -0500 spi: fsi: Fix clock running too fast [ Upstream commit 0b546bbe9474ff23e6843916ad6d567f703b2396 ] Use a clock divider tuned to a 200MHz FSI bus frequency (the maximum). Use of the previous divider at 200MHz results in corrupt data from endpoint devices. Ideally the clock divider would be calculated from the FSI clock, but that would require some significant work on the FSI driver. With FSI frequencies slower than 200MHz, the SPI clock will simply run slower, but safely. Signed-off-by: Brad Bishop Signed-off-by: Eddie James Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20200909222857.28653-3-eajames@linux.ibm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ba628cf85aabdd977f0a6a6abf3ba58b3dd4888f Author: Longfang Liu Date: Thu Sep 10 19:56:43 2020 +0800 crypto: hisilicon - fixed memory allocation error [ Upstream commit 24efcec2919afa7d56f848c83a605b46c8042a53 ] 1. Fix the bug of 'mac' memory leak as allocating 'pbuf' failing. 2. Fix the bug of 'qps' leak as allocating 'qp_ctx' failing. Signed-off-by: Longfang Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 88b7969b252eb839d2ef55398adc5e6869b92038 Author: Borislav Petkov Date: Mon Sep 14 19:21:28 2020 +0200 x86/mce: Annotate mce_rd/wrmsrl() with noinstr [ Upstream commit e100777016fdf6ec3a9d7c1773b15a2b5eca6c55 ] They do get called from the #MC handler which is already marked "noinstr". Commit e2def7d49d08 ("x86/mce: Make mce_rdmsrl() panic on an inaccessible MSR") already got rid of the instrumentation in the MSR accessors, fix the annotation now too, in order to get rid of: vmlinux.o: warning: objtool: do_machine_check()+0x4a: call to mce_rdmsrl() leaves .noinstr.text section Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200915194020.28807-1-bp@alien8.de Signed-off-by: Sasha Levin commit e967ca08730bbdc96024f6988b37216dbe473c5e Author: Xiaolong Huang Date: Fri Apr 17 11:52:30 2020 +0200 media: media/pci: prevent memory leak in bttv_probe [ Upstream commit 7b817585b730665126b45df5508dd69526448bc8 ] In bttv_probe if some functions such as pci_enable_device, pci_set_dma_mask and request_mem_region fails the allocated memory for btv should be released. Signed-off-by: Xiaolong Huang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 15e43e9e063f9a9032f850386397484dfeae0bda Author: Dinghao Liu Date: Thu May 21 12:00:21 2020 +0200 media: bdisp: Fix runtime PM imbalance on error [ Upstream commit dbd2f2dc025f9be8ae063e4f270099677238f620 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Reviewed-by: Fabien Dessenne Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 26b31569354f22a9b85c25d32ad96ef38ddacf21 Author: Dinghao Liu Date: Thu May 21 12:05:02 2020 +0200 media: platform: sti: hva: Fix runtime PM imbalance on error [ Upstream commit d912a1d9e9afe69c6066c1ceb6bfc09063074075 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2cb0554f89b0d9aad3fdcebceb635bd950091750 Author: Dinghao Liu Date: Thu May 21 15:29:33 2020 +0200 media: platform: s3c-camif: Fix runtime PM imbalance on error [ Upstream commit dafa3605fe60d5a61239d670919b2a36e712481e ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Also, call pm_runtime_disable() when pm_runtime_get_sync() returns an error code. Signed-off-by: Dinghao Liu Reviewed-by: Sylwester Nawrocki Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit cf6e195005f7cc5ddef68d70711cbce992639b54 Author: Dinghao Liu Date: Mon Jun 8 07:29:19 2020 +0200 media: vsp1: Fix runtime PM imbalance on error [ Upstream commit 98fae901c8883640202802174a4bd70a1b9118bd ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 48582b3ce35ff63c45579fed2ad868f782faea4e Author: Qiushi Wu Date: Sun Jun 14 05:01:11 2020 +0200 media: exynos4-is: Fix a reference count leak [ Upstream commit 64157b2cb1940449e7df2670e85781c690266588 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if pm_runtime_put_noidle() is not called in error handling paths. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails. Signed-off-by: Qiushi Wu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6146da1eed577e75b68402c31eedee153be984c0 Author: Qiushi Wu Date: Sun Jun 14 05:10:58 2020 +0200 media: exynos4-is: Fix a reference count leak due to pm_runtime_get_sync [ Upstream commit c47f7c779ef0458a58583f00c9ed71b7f5a4d0a2 ] On calling pm_runtime_get_sync() the reference count of the device is incremented. In case of failure, decrement the reference count before returning the error. Signed-off-by: Qiushi Wu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 49cb98d0212dcd036b2d278882e94da24d2bb011 Author: Qiushi Wu Date: Sun Jun 14 05:18:29 2020 +0200 media: exynos4-is: Fix several reference count leaks due to pm_runtime_get_sync [ Upstream commit 7ef64ceea0008c17e94a8a2c60c5d6d46f481996 ] On calling pm_runtime_get_sync() the reference count of the device is incremented. In case of failure, decrement the reference count before returning the error. Signed-off-by: Qiushi Wu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3ee4caeba5e62147ebeac7b95736622478d35a8d Author: Qiushi Wu Date: Sun Jun 14 05:31:06 2020 +0200 media: sti: Fix reference count leaks [ Upstream commit 6f4432bae9f2d12fc1815b5e26cc07e69bcad0df ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if pm_runtime_put_noidle() is not called in error handling paths. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails. Signed-off-by: Qiushi Wu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 9c0110b722f819c4808b259a870943f2e95ef3ac Author: Aditya Pakki Date: Sun Jun 14 05:58:41 2020 +0200 media: st-delta: Fix reference count leak in delta_run_work [ Upstream commit 57cc666d36adc7b45e37ba4cd7bc4e44ec4c43d7 ] delta_run_work() calls delta_get_sync() that increments the reference counter. In case of failure, decrement the reference count by calling delta_put_autosuspend(). Signed-off-by: Aditya Pakki Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit de71ba5e5308a3bde7755b7f5b99204e8aec0d88 Author: Oliver Neukum Date: Wed Sep 16 15:50:51 2020 +0200 media: ati_remote: sanity check for both endpoints [ Upstream commit a8be80053ea74bd9c3f9a3810e93b802236d6498 ] If you do sanity checks, you should do them for both endpoints. Hence introduce checking for endpoint type for the output endpoint, too. Reported-by: syzbot+998261c2ae5932458f6c@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 683ace5330e6d2ef7bc00d0f2be5b18300d776e4 Author: Pavel Machek Date: Sun Sep 20 11:01:37 2020 +0200 media: firewire: fix memory leak [ Upstream commit b28e32798c78a346788d412f1958f36bb760ec03 ] Fix memory leak in node_probe. Signed-off-by: Pavel Machek (CIP) Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4286dc105f25976de214869670e831901cee29d8 Author: Borislav Petkov Date: Tue Sep 29 19:13:12 2020 -0700 x86/mce: Add Skylake quirk for patrol scrub reported errors [ Upstream commit fd258dc4442c5c1c069c6b5b42bfe7d10cddda95 ] The patrol scrubber in Skylake and Cascade Lake systems can be configured to report uncorrected errors using a special signature in the machine check bank and to signal using CMCI instead of machine check. Update the severity calculation mechanism to allow specifying the model, minimum stepping and range of machine check bank numbers. Add a new rule to detect the special signature (on model 0x55, stepping >=4 in any of the memory controller banks). [ bp: Rewrite it. aegl: Productize it. ] Suggested-by: Youquan Song Signed-off-by: Borislav Petkov Co-developed-by: Tony Luck Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200930021313.31810-2-tony.luck@intel.com Signed-off-by: Sasha Levin commit 0f1f0d3b9efaac249d2d097a33c8d438795a5529 Author: Arvind Sankar Date: Wed Sep 2 19:21:52 2020 -0400 x86/asm: Replace __force_order with a memory clobber [ Upstream commit aa5cacdc29d76a005cbbee018a47faa6e724dd2d ] The CRn accessor functions use __force_order as a dummy operand to prevent the compiler from reordering CRn reads/writes with respect to each other. The fact that the asm is volatile should be enough to prevent this: volatile asm statements should be executed in program order. However GCC 4.9.x and 5.x have a bug that might result in reordering. This was fixed in 8.1, 7.3 and 6.5. Versions prior to these, including 5.x and 4.9.x, may reorder volatile asm statements with respect to each other. There are some issues with __force_order as implemented: - It is used only as an input operand for the write functions, and hence doesn't do anything additional to prevent reordering writes. - It allows memory accesses to be cached/reordered across write functions, but CRn writes affect the semantics of memory accesses, so this could be dangerous. - __force_order is not actually defined in the kernel proper, but the LLVM toolchain can in some cases require a definition: LLVM (as well as GCC 4.9) requires it for PIE code, which is why the compressed kernel has a definition, but also the clang integrated assembler may consider the address of __force_order to be significant, resulting in a reference that requires a definition. Fix this by: - Using a memory clobber for the write functions to additionally prevent caching/reordering memory accesses across CRn writes. - Using a dummy input operand with an arbitrary constant address for the read functions, instead of a global variable. This will prevent reads from being reordered across writes, while allowing memory loads to be cached/reordered across CRn reads, which should be safe. Signed-off-by: Arvind Sankar Signed-off-by: Borislav Petkov Reviewed-by: Kees Cook Reviewed-by: Miguel Ojeda Tested-by: Nathan Chancellor Tested-by: Sedat Dilek Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602 Link: https://lore.kernel.org/lkml/20200527135329.1172644-1-arnd@arndb.de/ Link: https://lkml.kernel.org/r/20200902232152.3709896-1-nivedita@alum.mit.edu Signed-off-by: Sasha Levin commit 2c9d4ccc23099e0ceb23054cc36e7f4a034a59df Author: Pavel Machek Date: Mon Sep 21 13:34:35 2020 +0200 crypto: ccp - fix error handling [ Upstream commit e356c49c6cf0db3f00e1558749170bd56e47652d ] Fix resource leak in error handling. Signed-off-by: Pavel Machek (CIP) Acked-by: John Allen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 46c53c22182e2527afbaf65fe251866b60f11c8a Author: Mark Mossberg Date: Fri Oct 2 04:29:16 2020 +0000 x86/dumpstack: Fix misleading instruction pointer error message [ Upstream commit 238c91115cd05c71447ea071624a4c9fe661f970 ] Printing "Bad RIP value" if copy_code() fails can be misleading for userspace pointers, since copy_code() can fail if the instruction pointer is valid but the code is paged out. This is because copy_code() calls copy_from_user_nmi() for userspace pointers, which disables page fault handling. This is reproducible in OOM situations, where it's plausible that the code may be reclaimed in the time between entry into the kernel and when this message is printed. This leaves a misleading log in dmesg that suggests instruction pointer corruption has occurred, which may alarm users. Change the message to state the error condition more precisely. [ bp: Massage a bit. ] Signed-off-by: Mark Mossberg Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20201002042915.403558-1-mark.mossberg@gmail.com Signed-off-by: Sasha Levin commit 089930fabeae73d1c83d068bb2c18179228e85d4 Author: Tetsuo Handa Date: Thu Oct 8 22:37:23 2020 +0900 block: ratelimit handle_bad_sector() message [ Upstream commit f4ac712e4fe009635344b9af5d890fe25fcc8c0d ] syzbot is reporting unkillable task [1], for the caller is failing to handle a corrupted filesystem image which attempts to access beyond the end of the device. While we need to fix the caller, flooding the console with handle_bad_sector() message is unlikely useful. [1] https://syzkaller.appspot.com/bug?id=f1f49fb971d7a3e01bd8ab8cff2ff4572ccf3092 Signed-off-by: Tetsuo Handa Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9b0d1c5500f0dc9f0a150618a691bbf5a0eecbf8 Author: Zhao Heming Date: Sun Sep 27 13:40:13 2020 +0800 md/bitmap: fix memory leak of temporary bitmap [ Upstream commit 1383b347a8ae4a69c04ae3746e6cb5c8d38e2585 ] Callers of get_bitmap_from_slot() are responsible to free the bitmap. Suggested-by: Guoqing Jiang Signed-off-by: Zhao Heming Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit c60acf07aae2492b7011626e1fd2710f117dff11 Author: Hans de Goede Date: Wed Oct 14 16:41:58 2020 +0200 i2c: core: Restore acpi_walk_dep_device_list() getting called after registering the ACPI i2c devs [ Upstream commit 8058d69905058ec8f467a120b5ec5bb831ea67f3 ] Commit 21653a4181ff ("i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices()")'s intention was to only move the acpi_install_address_space_handler() call to the point before where the ACPI declared i2c-children of the adapter where instantiated by i2c_acpi_register_devices(). But i2c_acpi_install_space_handler() had a call to acpi_walk_dep_device_list() hidden (that is I missed it) at the end of it, so as an unwanted side-effect now acpi_walk_dep_device_list() was also being called before i2c_acpi_register_devices(). Move the acpi_walk_dep_device_list() call to the end of i2c_acpi_register_devices(), so that it is once again called *after* the i2c_client-s hanging of the adapter have been created. This fixes the Microsoft Surface Go 2 hanging at boot. Fixes: 21653a4181ff ("i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices()") Link: https://bugzilla.kernel.org/show_bug.cgi?id=209627 Reported-by: Rainer Finke Reported-by: Kieran Bingham Suggested-by: Maximilian Luz Tested-by: Kieran Bingham Signed-off-by: Hans de Goede Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit b4d2a13ebb6dc36236ade3534af2557d382577a1 Author: George Spelvin Date: Sun Aug 9 06:57:44 2020 +0000 random32: make prandom_u32() output unpredictable [ Upstream commit c51f8f88d705e06bd696d7510aff22b33eb8e638 ] Non-cryptographic PRNGs may have great statistical properties, but are usually trivially predictable to someone who knows the algorithm, given a small sample of their output. An LFSR like prandom_u32() is particularly simple, even if the sample is widely scattered bits. It turns out the network stack uses prandom_u32() for some things like random port numbers which it would prefer are *not* trivially predictable. Predictability led to a practical DNS spoofing attack. Oops. This patch replaces the LFSR with a homebrew cryptographic PRNG based on the SipHash round function, which is in turn seeded with 128 bits of strong random key. (The authors of SipHash have *not* been consulted about this abuse of their algorithm.) Speed is prioritized over security; attacks are rare, while performance is always wanted. Replacing all callers of prandom_u32() is the quick fix. Whether to reinstate a weaker PRNG for uses which can tolerate it is an open question. Commit f227e3ec3b5c ("random32: update the net random state on interrupt and activity") was an earlier attempt at a solution. This patch replaces it. Reported-by: Amit Klein Cc: Willy Tarreau Cc: Eric Dumazet Cc: "Jason A. Donenfeld" Cc: Andy Lutomirski Cc: Kees Cook Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Linus Torvalds Cc: tytso@mit.edu Cc: Florian Westphal Cc: Marc Plumb Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and activity") Signed-off-by: George Spelvin Link: https://lore.kernel.org/netdev/20200808152628.GA27941@SDF.ORG/ [ willy: partial reversal of f227e3ec3b5c; moved SIPROUND definitions to prandom.h for later use; merged George's prandom_seed() proposal; inlined siprand_u32(); replaced the net_rand_state[] array with 4 members to fix a build issue; cosmetic cleanups to make checkpatch happy; fixed RANDOM32_SELFTEST build ] Signed-off-by: Willy Tarreau Signed-off-by: Sasha Levin commit c536c6d5e9016d04c7d6c96a0df3cbb0e0c79738 Author: Al Grant Date: Mon Sep 21 21:46:37 2020 +0100 perf: correct SNOOPX field offset [ Upstream commit f3d301c1f2f5676465cdf3259737ea19cc82731f ] perf_event.h has macros that define the field offsets in the data_src bitmask in perf records. The SNOOPX and REMOTE offsets were both 37. These are distinct fields, and the bitfield layout in perf_mem_data_src confirms that SNOOPX should be at offset 38. Fixes: 52839e653b5629bd ("perf tools: Add support for printing new mem_info encodings") Signed-off-by: Al Grant Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Andi Kleen Link: https://lkml.kernel.org/r/4ac9f5cc-4388-b34a-9999-418a4099415d@foss.arm.com Signed-off-by: Sasha Levin commit 14a9d076e628581b42268d6f74ce361b10d2da2b Author: Juri Lelli Date: Tue Oct 13 07:31:14 2020 +0200 sched/features: Fix !CONFIG_JUMP_LABEL case [ Upstream commit a73f863af4ce9730795eab7097fb2102e6854365 ] Commit: 765cc3a4b224e ("sched/core: Optimize sched_feat() for !CONFIG_SCHED_DEBUG builds") made sched features static for !CONFIG_SCHED_DEBUG configurations, but overlooked the CONFIG_SCHED_DEBUG=y and !CONFIG_JUMP_LABEL cases. For the latter echoing changes to /sys/kernel/debug/sched_features has the nasty effect of effectively changing what sched_features reports, but without actually changing the scheduler behaviour (since different translation units get different sysctl_sched_features). Fix CONFIG_SCHED_DEBUG=y and !CONFIG_JUMP_LABEL configurations by properly restructuring ifdefs. Fixes: 765cc3a4b224e ("sched/core: Optimize sched_feat() for !CONFIG_SCHED_DEBUG builds") Co-developed-by: Daniel Bristot de Oliveira Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Juri Lelli Signed-off-by: Ingo Molnar Acked-by: Patrick Bellasi Reviewed-by: Valentin Schneider Link: https://lore.kernel.org/r/20201013053114.160628-1-juri.lelli@redhat.com Signed-off-by: Sasha Levin commit ea2cd2d04739c50333c5012eb6f3f1234e425351 Author: Dinghao Liu Date: Sun Aug 23 14:55:12 2020 +0800 ntb: intel: Fix memleak in intel_ntb_pci_probe [ Upstream commit dbb8df5c2d27610a87b0168a8acc89d73fbfde94 ] The default error branch of a series of pdev_is_gen calls should free ndev just like what we've done in these calls. Fixes: 26bfe3d0b227 ("ntb: intel: Add Icelake (gen4) support for Intel NTB") Signed-off-by: Dinghao Liu Acked-by: Dave Jiang Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 83f7a42b30c041b924f5836e407e60ac49f876b7 Author: Kaige Li Date: Tue Aug 11 09:59:57 2020 +0800 NTB: hw: amd: fix an issue about leak system resources [ Upstream commit 44a0a3c17919db1498cebb02ecf3cf4abc1ade7b ] The related system resources were not released when pci_set_dma_mask(), pci_set_consistent_dma_mask(), or pci_iomap() return error in the amd_ntb_init_pci() function. Add pci_release_regions() to fix it. Fixes: a1b3695820aa ("NTB: Add support for AMD PCI-Express Non-Transparent Bridge") Signed-off-by: Kaige Li Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 293c420c1af6355ccb53d816146f5455909e26b9 Author: Vitaly Kuznetsov Date: Sat Oct 24 04:13:24 2020 -0400 KVM: ioapic: break infinite recursion on lazy EOI [ Upstream commit 77377064c3a94911339f13ce113b3abf265e06da ] During shutdown the IOAPIC trigger mode is reset to edge triggered while the vfio-pci INTx is still registered with a resampler. This allows us to get into an infinite loop: ioapic_set_irq -> ioapic_lazy_update_eoi -> kvm_ioapic_update_eoi_one -> kvm_notify_acked_irq -> kvm_notify_acked_gsi -> (via irq_acked fn ptr) irqfd_resampler_ack -> kvm_set_irq -> (via set fn ptr) kvm_set_ioapic_irq -> kvm_ioapic_set_irq -> ioapic_set_irq Commit 8be8f932e3db ("kvm: ioapic: Restrict lazy EOI update to edge-triggered interrupts", 2020-05-04) acknowledges that this recursion loop exists and tries to avoid it at the call to ioapic_lazy_update_eoi, but at this point the scenario is already set, we have an edge interrupt with resampler on the same gsi. Fortunately, the only user of irq ack notifiers (in addition to resamplefd) is i8254 timer interrupt reinjection. These are edge-triggered, so in principle they would need the call to kvm_ioapic_update_eoi_one from ioapic_lazy_update_eoi, but they already disable AVIC(*), so they don't need the lazy EOI behavior. Therefore, remove the call to kvm_ioapic_update_eoi_one from ioapic_lazy_update_eoi. This fixes CVE-2020-27152. Note that this issue cannot happen with SR-IOV assigned devices because virtual functions do not have INTx, only MSI. Fixes: f458d039db7e ("kvm: ioapic: Lazy update IOAPIC EOI") Suggested-by: Paolo Bonzini Tested-by: Alex Williamson Signed-off-by: Vitaly Kuznetsov Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 70ba5cda1c096fc9af22e6822393ac4c889ab28d Author: Logan Gunthorpe Date: Fri Oct 16 16:19:04 2020 -0600 nvmet: limit passthru MTDS by BIO_MAX_PAGES [ Upstream commit df06047d54276f73782c9d97882b305fca745d3f ] nvmet_passthru_map_sg() only supports mapping a single BIO, not a chain so the effective maximum transfer should also be limitted by BIO_MAX_PAGES (presently this works out to 1MB). For PCI passthru devices the max_sectors would typically be more limitting than BIO_MAX_PAGES, but this may not be true for all passthru devices. Fixes: c1fef73f793b ("nvmet: add passthru code to process commands") Suggested-by: Christoph Hellwig Signed-off-by: Logan Gunthorpe Cc: Christoph Hellwig Cc: Sagi Grimberg Cc: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 004e3d1496eabb9bb9c5a9db1c0bad8bbebf92dd Author: zhenwei pi Date: Thu Oct 15 09:51:40 2020 +0800 nvmet: fix uninitialized work for zero kato [ Upstream commit 85bd23f3dc09a2ae9e56885420e52c54bf983713 ] When connecting a controller with a zero kato value using the following command line nvme connect -t tcp -n NQN -a ADDR -s PORT --keep-alive-tmo=0 the warning below can be reproduced: WARNING: CPU: 1 PID: 241 at kernel/workqueue.c:1627 __queue_delayed_work+0x6d/0x90 with trace: mod_delayed_work_on+0x59/0x90 nvmet_update_cc+0xee/0x100 [nvmet] nvmet_execute_prop_set+0x72/0x80 [nvmet] nvmet_tcp_try_recv_pdu+0x2f7/0x770 [nvmet_tcp] nvmet_tcp_io_work+0x63f/0xb2d [nvmet_tcp] ... This is caused by queuing up an uninitialized work. Althrough the keep-alive timer is disabled during allocating the controller (fixed in 0d3b6a8d213a), ka_work still has a chance to run (called by nvmet_start_ctrl). Fixes: 0d3b6a8d213a ("nvmet: Disable keep-alive timer when kato is cleared to 0h") Signed-off-by: zhenwei pi Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ae04a238f748906270ede9228304528d7d730895 Author: Ganesh Goudar Date: Fri Jul 24 12:09:46 2020 +0530 powerpc/pseries: Avoid using addr_to_pfn in real mode [ Upstream commit 4ff753feab021242144818b9a3ba011238218145 ] When an UE or memory error exception is encountered the MCE handler tries to find the pfn using addr_to_pfn() which takes effective address as an argument, later pfn is used to poison the page where memory error occurred, recent rework in this area made addr_to_pfn to run in real mode, which can be fatal as it may try to access memory outside RMO region. Have two helper functions to separate things to be done in real mode and virtual mode without changing any functionality. This also fixes the following error as the use of addr_to_pfn is now moved to virtual mode. Without this change following kernel crash is seen on hitting UE. [ 485.128036] Oops: Kernel access of bad area, sig: 11 [#1] [ 485.128040] LE SMP NR_CPUS=2048 NUMA pSeries [ 485.128047] Modules linked in: [ 485.128067] CPU: 15 PID: 6536 Comm: insmod Kdump: loaded Tainted: G OE 5.7.0 #22 [ 485.128074] NIP: c00000000009b24c LR: c0000000000398d8 CTR: c000000000cd57c0 [ 485.128078] REGS: c000000003f1f970 TRAP: 0300 Tainted: G OE (5.7.0) [ 485.128082] MSR: 8000000000001003 CR: 28008284 XER: 00000001 [ 485.128088] CFAR: c00000000009b190 DAR: c0000001fab00000 DSISR: 40000000 IRQMASK: 1 [ 485.128088] GPR00: 0000000000000001 c000000003f1fbf0 c000000001634300 0000b0fa01000000 [ 485.128088] GPR04: d000000002220000 0000000000000000 00000000fab00000 0000000000000022 [ 485.128088] GPR08: c0000001fab00000 0000000000000000 c0000001fab00000 c000000003f1fc14 [ 485.128088] GPR12: 0000000000000008 c000000003ff5880 d000000002100008 0000000000000000 [ 485.128088] GPR16: 000000000000ff20 000000000000fff1 000000000000fff2 d0000000021a1100 [ 485.128088] GPR20: d000000002200000 c00000015c893c50 c000000000d49b28 c00000015c893c50 [ 485.128088] GPR24: d0000000021a0d08 c0000000014e5da8 d0000000021a0818 000000000000000a [ 485.128088] GPR28: 0000000000000008 000000000000000a c0000000017e2970 000000000000000a [ 485.128125] NIP [c00000000009b24c] __find_linux_pte+0x11c/0x310 [ 485.128130] LR [c0000000000398d8] addr_to_pfn+0x138/0x170 [ 485.128133] Call Trace: [ 485.128135] Instruction dump: [ 485.128138] 3929ffff 7d4a3378 7c883c36 7d2907b4 794a1564 7d294038 794af082 3900ffff [ 485.128144] 79291f24 790af00e 78e70020 7d095214 <7c69502a> 2fa30000 419e011c 70690040 [ 485.128152] ---[ end trace d34b27e29ae0e340 ]--- Fixes: 9ca766f9891d ("powerpc/64s/pseries: machine check convert to use common event code") Signed-off-by: Ganesh Goudar Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200724063946.21378-1-ganeshgr@linux.ibm.com Signed-off-by: Sasha Levin commit 30c28960c40b29f5c21fca40c648f9a7b91003d0 Author: Jordan Niethe Date: Thu Aug 27 13:55:29 2020 +1000 powerpc/64s: Remove TM from Power10 features [ Upstream commit ec613a57fa1d57381f890c3166175fe68cf43f12 ] ISA v3.1 removes transactional memory and hence it should not be present in cpu_features or cpu_user_features2. Remove CPU_FTR_TM_COMP from CPU_FTRS_POWER10. Remove PPC_FEATURE2_HTM_COMP and PPC_FEATURE2_HTM_NOSC_COMP from COMMON_USER2_POWER10. Fixes: a3ea40d5c736 ("powerpc: Add POWER10 architected mode") Signed-off-by: Jordan Niethe Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200827035529.900-1-jniethe5@gmail.com Signed-off-by: Sasha Levin commit b6a49c2768a9ad57cc91d6c985cef887d25b855b Author: Vasant Hegde Date: Sat Oct 17 22:12:10 2020 +0530 powerpc/powernv/dump: Fix race while processing OPAL dump [ Upstream commit 0a43ae3e2beb77e3481d812834d33abe270768ab ] Every dump reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the dump and acknowledges that the dump is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning dump entries when a new sysfs dump entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between dump_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_dump_obj() returns the dump object which if used by caller function will end up in use-after-free problem again. However, the return value of create_dump_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: c7e64b9ce04a ("powerpc/powernv Platform dump interface") Signed-off-by: Vasant Hegde Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201017164210.264619-1-hegdevasant@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 0db50a0ee9ed84456448ad5ec79ee211895bb0b4 Author: Colin Ian King Date: Fri Oct 16 15:33:51 2020 +0100 lightnvm: fix out-of-bounds write to array devices->info[] [ Upstream commit a48faebe65b0db55a73b9220c3d919eee849bb79 ] There is an off-by-one array check that can lead to a out-of-bounds write to devices->info[i]. Fix this by checking by using >= rather than > for the size check. Also replace hard-coded array size limit with ARRAY_SIZE on the array. Addresses-Coverity: ("Out-of-bounds write") Fixes: cd9e9808d18f ("lightnvm: Support for Open-Channel SSDs") Signed-off-by: Colin Ian King Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3c967d12eb96eefad5936818ce52f2556ae8147a Author: Martin Blumenstingl Date: Sat Aug 15 20:19:57 2020 +0200 ARM: dts: meson8: remove two invalid interrupt lines from the GPU node [ Upstream commit 737e7610b545cc901a9696083c1824a7104b8d1b ] The 3.10 vendor kernel defines the following GPU 20 interrupt lines: #define INT_MALI_GP AM_IRQ(160) #define INT_MALI_GP_MMU AM_IRQ(161) #define INT_MALI_PP AM_IRQ(162) #define INT_MALI_PMU AM_IRQ(163) #define INT_MALI_PP0 AM_IRQ(164) #define INT_MALI_PP0_MMU AM_IRQ(165) #define INT_MALI_PP1 AM_IRQ(166) #define INT_MALI_PP1_MMU AM_IRQ(167) #define INT_MALI_PP2 AM_IRQ(168) #define INT_MALI_PP2_MMU AM_IRQ(169) #define INT_MALI_PP3 AM_IRQ(170) #define INT_MALI_PP3_MMU AM_IRQ(171) #define INT_MALI_PP4 AM_IRQ(172) #define INT_MALI_PP4_MMU AM_IRQ(173) #define INT_MALI_PP5 AM_IRQ(174) #define INT_MALI_PP5_MMU AM_IRQ(175) #define INT_MALI_PP6 AM_IRQ(176) #define INT_MALI_PP6_MMU AM_IRQ(177) #define INT_MALI_PP7 AM_IRQ(178) #define INT_MALI_PP7_MMU AM_IRQ(179) However, the driver from the 3.10 vendor kernel does not use the following four interrupt lines: - INT_MALI_PP3 - INT_MALI_PP3_MMU - INT_MALI_PP7 - INT_MALI_PP7_MMU Drop the "pp3" and "ppmmu3" interrupt lines. This is also important because there is no matching entry in interrupt-names for it (meaning the "pp2" interrupt is actually assigned to the "pp3" interrupt line). Fixes: 7d3f6b536e72c9 ("ARM: dts: meson8: add the Mali-450 MP6 GPU") Reported-by: Thomas Graichen Signed-off-by: Martin Blumenstingl Signed-off-by: Kevin Hilman Tested-by: thomas graichen Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20200815181957.408649-1-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit db8734fc3338794e41e7a18e8542f2e14afc13ca Author: Michal Simek Date: Mon Aug 24 10:59:14 2020 +0200 arm64: dts: zynqmp: Remove additional compatible string for i2c IPs [ Upstream commit 35292518cb0a626fcdcabf739aed75060a018ab5 ] DT binding permits only one compatible string which was decribed in past by commit 63cab195bf49 ("i2c: removed work arounds in i2c driver for Zynq Ultrascale+ MPSoC"). The commit aea37006e183 ("dt-bindings: i2c: cadence: Migrate i2c-cadence documentation to YAML") has converted binding to yaml and the following issues is reported: ...: i2c@ff030000: compatible: Additional items are not allowed ('cdns,i2c-r1p10' was unexpected) From schema: .../Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml fds ...: i2c@ff030000: compatible: ['cdns,i2c-r1p14', 'cdns,i2c-r1p10'] is too long The commit c415f9e8304a ("ARM64: zynqmp: Fix i2c node's compatible string") has added the second compatible string but without removing origin one. The patch is only keeping one compatible string "cdns,i2c-r1p14". Fixes: c415f9e8304a ("ARM64: zynqmp: Fix i2c node's compatible string") Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/cc294ae1a79ef845af6809ddb4049f0c0f5bb87a.1598259551.git.michal.simek@xilinx.com Reviewed-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 86af52b93be106ad2b999d268cd3da8a702c89de Author: Dennis YC Hsieh Date: Tue Jul 7 23:45:14 2020 +0800 drm/mediatek: reduce clear event [ Upstream commit bee1abc9cc021f50b90f22a589d9ddc816a80db0 ] No need to clear event again since event always clear before wait. This fix depend on patch: "soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api" Fixes: 2f965be7f9008 ("drm/mediatek: apply CMDQ control flow") Signed-off-by: Dennis YC Hsieh Reviewed-by: Bibby Hsieh Acked-by: Chun-Kuang Hu Link: https://lore.kernel.org/r/1594136714-11650-10-git-send-email-dennis-yc.hsieh@mediatek.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit a34d444aa27e9eb431b469db4faf98f898f3574c Author: Dennis YC Hsieh Date: Tue Jul 7 23:45:13 2020 +0800 soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api [ Upstream commit 23c22299cd290409c6b78f57c42b64f8dfb6dd92 ] Add clear parameter to let client decide if event should be clear to 0 after GCE receive it. Signed-off-by: Dennis YC Hsieh Acked-by: Chun-Kuang Hu Link: https://lore.kernel.org/r/1594136714-11650-9-git-send-email-dennis-yc.hsieh@mediatek.com [mb: fix commit message] Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit b18eb82bfc848eeca176e0e032465a05cac75c67 Author: Biju Das Date: Thu Sep 24 09:05:35 2020 +0100 ARM: dts: iwg20d-q7-common: Fix touch controller probe failure [ Upstream commit 08d7a73fffb6769b1cf2278bf697e692daba3abf ] As per the iWave RZ/G1M schematic, the signal LVDS_PPEN controls the supply voltage for the touch panel, LVDS receiver and RGB LCD panel. Add a regulator for these device nodes and remove the powerdown-gpios property from the lvds-receiver node as it results in a touch controller driver probe failure. Fixes: 6f89dd9e9325 ("ARM: dts: iwg20d-q7-common: Add LCD support") Signed-off-by: Biju Das Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20200924080535.3641-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit c1b3f654bed2d2606d173dfd63d834e472b8da1c Author: Marek Vasut Date: Sat Aug 22 22:32:55 2020 +0200 ARM: dts: stm32: Fix DH PDK2 display PWM channel [ Upstream commit 57592d2a98dbc3bde3ddc062e91a8486bdcb211e ] The display PWM channel is number 3 (PWM2 CH4), make it so. Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board") Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Maxime Coquelin Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit b5a2fbe41788d47a88926125c8a877a3f8d1b1b1 Author: Marek Vasut Date: Fri Aug 28 14:14:12 2020 +0200 ARM: dts: stm32: Swap PHY reset GPIO and TSC2004 IRQ on DHCOM SOM [ Upstream commit 9ad98319e95263469d8ca2cb543c37c5a2f40980 ] On the production revision of the SoM, 587-200, the PHY reset GPIO and touchscreen IRQs are swapped to prevent collision between EXTi IRQs, reflect that in DT. Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board") Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Maxime Coquelin Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 2a7a15936b5f9e7f261d6daf62b3201a6011fbf6 Author: Marek Vasut Date: Wed Jul 29 18:51:40 2020 +0200 ARM: dts: stm32: Move ethernet PHY into DH SoM DT [ Upstream commit b0a07f609600b6fa4c30f783db50c38456804485 ] The PHY and the VIO regulator is populated on the SoM, move it into the SoM DT. Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Maxime Coquelin Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit bdd44aa70d0cad177fdfa960621f658262b5f4b4 Author: Holger Assmann Date: Fri Aug 7 17:03:56 2020 +0200 ARM: dts: stm32: lxa-mc1: Fix kernel warning about PHY delays [ Upstream commit 42a31ac6698681363363d48335559d212a26a7ca ] The KSZ9031 PHY skew timings for rxc/txc, originally set to achieve the desired phase shift between clock- and data-signal, now trigger a kernel warning when used in rgmii-id mode: *-skew-ps values should be used only with phy-mode = "rgmii" This is because commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") now configures own timings when phy-mode = "rgmii-id". Device trees wanting to set their own delays should use phy-mode "rgmii" instead as the warning prescribes. The "standard" timings now used with "rgmii-id" work fine on this board, so drop the explicit timings in the device tree and thereby silence the warning. Fixes: 666b5ca85cd3 ("ARM: dts: stm32: add STM32MP1-based Linux Automation MC-1 board") Signed-off-by: Holger Assmann Acked-by: Ahmad Fatoum Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit d9b0cce125db18f6312185281ce359778ac8d0f5 Author: Marek Vasut Date: Fri Jul 31 01:27:57 2020 +0200 ARM: dts: stm32: Fix sdmmc2 pins on AV96 [ Upstream commit 1ad6e36ec266cedb0d274aa13253ff1fb2eed4ba ] The AV96 uses sdmmc2_d47_pins_c and sdmmc2_d47_sleep_pins_c, which differ from sdmmc2_d47_pins_b and sdmmc2_d47_sleep_pins_b in one pin, SDMMC2_D5, which is PA15 in the former and PA9 in the later. The PA15 is correct on AV96, so fix this. This error is likely a result of rebasing across the stm32mp1 DT pinctrl rework. Fixes: 611325f68102 ("ARM: dts: stm32: Add eMMC attached to SDMMC2 on AV96") Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Maxime Coquelin Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit e7663717b62557d11c5659e40c1d19870e24dc70 Author: Tony Lindgren Date: Wed Sep 23 09:16:22 2020 +0300 ARM: OMAP2+: Restore MPU power domain if cpu_cluster_pm_enter() fails [ Upstream commit 8f04aea048d56f3e39a7e543939450246542a6fc ] If cpu_cluster_pm_enter() fails, we need to set MPU power domain back to enabled to prevent the next WFI from potentially triggering an undesired MPU power domain state change. We already do this for omap_enter_idle_smp() but are missing it for omap_enter_idle_coupled(). Fixes: 55be2f50336f ("ARM: OMAP2+: Handle errors for cpu_pm") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit e6406d99e20b35c17a35cb9bb894593c40459199 Author: Krzysztof Kozlowski Date: Sun Sep 20 22:26:25 2020 +0200 soc: fsl: qbman: Fix return value on success [ Upstream commit 750cf40c0f7088f36a8a5d102e0488b1ac47faf5 ] On error the function was meant to return -ERRNO. This also fixes compile warning: drivers/soc/fsl/qbman/bman.c:640:6: warning: variable 'err' set but not used [-Wunused-but-set-variable] Fixes: 0505d00c8dba ("soc/fsl/qbman: Cleanup buffer pools if BMan was initialized prior to bootup") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Li Yang Signed-off-by: Sasha Levin commit 53d8f17e1bd108e6c5e9f64c1d529be88ecd6599 Author: Cristian Ciocaltea Date: Fri Aug 28 16:53:17 2020 +0300 ARM: dts: owl-s500: Fix incorrect PPI interrupt specifiers [ Upstream commit 55f6c9931f7c32f19cf221211f099dfd8dab3af9 ] The PPI interrupts for cortex-a9 were incorrectly specified, fix them. Fixes: fdfe7f4f9d85 ("ARM: dts: Add Actions Semi S500 and LeMaker Guitar") Signed-off-by: Cristian Ciocaltea Reviewed-by: Peter Korsgaard Reviewed-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit 44c69f272e5094bc9fca8983364842e66f52eb46 Author: Amit Singh Tomar Date: Sun Jul 19 23:12:02 2020 +0530 arm64: dts: actions: limit address range for pinctrl node [ Upstream commit 4bb1eb3cd4bd6241d5e5f99bbfd801ea5a007b6c ] After commit 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for Actions Semi S700") following error has been observed while booting Linux on Cubieboard7-lite(based on S700 SoC). [ 0.257415] pinctrl-s700 e01b0000.pinctrl: can't request region for resource [mem 0xe01b0000-0xe01b0fff] [ 0.266902] pinctrl-s700: probe of e01b0000.pinctrl failed with error -16 This is due to the fact that memory range for "sps" power domain controller clashes with pinctrl. One way to fix it, is to limit pinctrl address range which is safe to do as current pinctrl driver uses address range only up to 0x100. This commit limits the pinctrl address range to 0x100 so that it doesn't conflict with sps range. Fixes: 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for Actions Semi S700") Reviewed-by: Manivannan Sadhasivam Suggested-by: Andre Przywara Signed-off-by: Amit Singh Tomar Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit af4c7bf659dee320c7af165c921cafd549a6ab9a Author: Roger Quadros Date: Fri Sep 18 19:59:30 2020 +0300 arm64: dts: ti: k3-j721e: Rename mux header and update macro names [ Upstream commit c65176fd49f45bd5a5ffaa1790109745d1fa462c ] We intend to use one header file for SERDES MUX for all TI SoCs so rename the header file. The exsting macros are too generic. Prefix them with SoC name. While at that, add the missing configurations for completeness. Fixes: b766e3b0d5f6 ("arm64: dts: ti: k3-j721e-main: Add system controller node and SERDES lane mux") Reported-by: Peter Rosin Signed-off-by: Roger Quadros Signed-off-by: Nishanth Menon Acked-by: Peter Rosin Link: https://lore.kernel.org/r/20200918165930.2031-1-rogerq@ti.com Signed-off-by: Sasha Levin commit 056d8b3acb81187774098f4c2f2ab2efb955fc21 Author: Hsin-Yi Wang Date: Mon Jul 27 15:41:24 2020 +0800 arm64: dts: mt8173: elm: Fix nor_flash node property [ Upstream commit 1276be23fd53e1c4e752966d0eab42aa54a343da ] bus-width and non-removable is not used by the driver. max-frequency should be spi-max-frequency for flash node. Fixes: 689b937bedde ("arm64: dts: mediatek: add mt8173 elm and hana board") Reported-by: Nicolas Boichat Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20200727074124.3779237-1-hsinyi@chromium.org Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 378ab34ac3b9cc1f5c196f0992a852d731e43b0a Author: Geert Uytterhoeven Date: Thu Sep 17 15:21:17 2020 +0200 arm64: dts: renesas: r8a774c0: Fix MSIOF1 DMA channels [ Upstream commit c91dfc9818df5f43c10c727f1cecaebdb5e2fa92 ] According to Technical Update TN-RCT-S0352A/E, MSIOF1 DMA can only be used with SYS-DMAC0 on R-Car E3. Fixes: 62c0056f1c3eb15d ("arm64: dts: renesas: r8a774c0: Add MSIOF nodes") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20200917132117.8515-3-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 1873a981d5b9e87ef10b9e2c9364112b4e46793e Author: Geert Uytterhoeven Date: Thu Sep 17 15:21:16 2020 +0200 arm64: dts: renesas: r8a77990: Fix MSIOF1 DMA channels [ Upstream commit 453802c463abd003a7c38ffbc90b67ba162335b6 ] According to Technical Update TN-RCT-S0352A/E, MSIOF1 DMA can only be used with SYS-DMAC0 on R-Car E3. Fixes: 8517042060b55a37 ("arm64: dts: renesas: r8a77990: Add DMA properties to MSIOF nodes") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20200917132117.8515-2-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 797a930c8da808d70bb76a87f8c5aeafc361fef3 Author: Corentin Labbe Date: Mon Sep 7 19:54:37 2020 +0200 dt-bindings: crypto: Specify that allwinner, sun8i-a33-crypto needs reset [ Upstream commit 884d1a334ae8130fabede56f59b224619ad6bca4 ] When adding allwinner,sun8i-a33-crypto, I forgot to add that it needs reset. Furthermore, there are no need to use items to list only one compatible in compatible list. Fixes: f81547ba7a98 ("dt-bindings: crypto: add new compatible for A33 SS") Signed-off-by: Corentin Labbe Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20200907175437.4464-1-clabbe.montjoie@gmail.com Signed-off-by: Sasha Levin commit b812ab66659da3745516fabf6fcb9bab13e7bb06 Author: Sibi Sankar Date: Tue Sep 15 21:12:32 2020 +0530 soc: qcom: apr: Fixup the error displayed on lookup failure [ Upstream commit ba34f977c333f96c8acd37ec30e232220399f5a5 ] APR client incorrectly prints out "ret" variable on pdr_add_lookup failure, it should be printing the error value returned by the lookup instead. Fixes: 8347356626028 ("soc: qcom: apr: Add avs/audio tracking functionality") Signed-off-by: Sibi Sankar Link: https://lore.kernel.org/r/20200915154232.27523-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9d4e8dfea2674622ff40c11711ad3661502876db Author: Stephan Gerhold Date: Tue Sep 15 09:12:11 2020 +0200 arm64: dts: qcom: msm8916: Fix MDP/DSI interrupts [ Upstream commit 027cca9eb5b450c3f6bb916ba999144c2ec23cb7 ] The mdss node sets #interrupt-cells = <1>, so its interrupts should be referenced using a single cell (in this case: only the interrupt number). However, right now the mdp/dsi node both have two interrupt cells set, e.g. interrupts = <4 0>. The 0 is probably meant to say IRQ_TYPE_NONE (= 0), but with #interrupt-cells = <1> this is actually interpreted as a second interrupt line. Remove the IRQ flags from both interrupts to fix this. Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20200915071221.72895-5-stephan@gerhold.net Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1febd03845eb21391025e4165ada69c114e79823 Author: Stephan Gerhold Date: Tue Sep 15 09:12:10 2020 +0200 arm64: dts: qcom: pm8916: Remove invalid reg size from wcd_codec [ Upstream commit c2f0cbb57dbac6da3d38b47b5b96de0fe4e23884 ] Tha parent node of "wcd_codec" specifies #address-cells = <1> and #size-cells = <0>, which means that each resource should be described by one cell for the address and size omitted. However, wcd_codec currently lists 0x200 as second cell (probably the size of the resource). When parsing this would be treated like another memory resource - which is entirely wrong. To quote the device tree specification [1]: "If the parent node specifies a value of 0 for #size-cells, the length field in the value of reg shall be omitted." [1]: https://www.devicetree.org/specifications/ Fixes: 5582fcb3829f ("arm64: dts: apq8016-sbc: add analog audio support with multicodec") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20200915071221.72895-4-stephan@gerhold.net Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 899ea140a9af42e2fcb77227b7c814cdbfa1ba8c Author: Stephan Gerhold Date: Tue Sep 15 09:12:09 2020 +0200 arm64: dts: qcom: msm8916: Remove one more thermal trip point unit name [ Upstream commit e6859ae8603c5946b8f3ecbd9b4f02b72955b9d0 ] Commit fe2aff0c574d2 ("arm64: dts: qcom: msm8916: remove unit name for thermal trip points") removed the unit names for most of the thermal trip points defined in msm8916.dtsi, but missed to update the one for cpu0_1-thermal. So why wasn't this spotted by "make dtbs_check"? Apparently, the name of the thermal zone is already invalid: thermal-zones.yaml specifies a regex of ^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$, so it is not allowed to contain underscores. Therefore the thermal zone was never verified using the DTB schema. After replacing the underscore in the thermal zone name, the warning shows up: apq8016-sbc.dt.yaml: thermal-zones: cpu0-1-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' Fix up the thermal zone names and remove the unit name for the trip point. Cc: Amit Kucheria Fixes: fe2aff0c574d2 ("arm64: dts: qcom: msm8916: remove unit name for thermal trip points") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20200915071221.72895-3-stephan@gerhold.net Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c3cd677444346c2098f84c58481c537eb45ea742 Author: Sibi Sankar Date: Mon Sep 14 20:28:07 2020 +0530 soc: qcom: pdr: Fixup array type of get_domain_list_resp message [ Upstream commit 7a366707bb6a93baeb1a9ef46c4b9c875e0132d6 ] The array type of get_domain_list_resp is incorrectly marked as NO_ARRAY. Due to which the following error was observed when using pdr helpers with the downstream proprietary pd-mapper. Fix this up by marking it as VAR_LEN_ARRAY instead. Err logs: qmi_decode_struct_elem: Fault in decoding: dl(2), db(27), tl(160), i(1), el(1) failed to decode incoming message PDR: tms/servreg get domain list txn wait failed: -14 PDR: service lookup for tms/servreg failed: -14 Tested-by: Rishabh Bhatnagar Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") Reported-by: Rishabh Bhatnagar Signed-off-by: Sibi Sankar Link: https://lore.kernel.org/r/20200914145807.1224-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 25fbbd5f9ece50e49662856a08018abdbf9b2860 Author: Rajendra Nayak Date: Wed Aug 12 15:52:10 2020 +0530 arm64: dts: sdm845: Fixup OPP table for all qup devices [ Upstream commit e0b760a5f6c9e54db8bd22b1d6b19223e6b92264 ] This OPP table was based on the clock VDD-FMAX tables seen in downstream code, however it turns out the downstream clock driver does update these tables based on later/production rev of the chip and whats seen in the tables belongs to an early engineering rev of the SoC. Fix up the OPP tables such that it now matches with the production rev of sdm845 SoC. Tested-by: Amit Pundir Tested-by: John Stultz Tested-by: Steev Klimaszewski Fixes: 13cadb34e593 ("arm64: dts: sdm845: Add OPP table for all qup devices") Reported-by: John Stultz Signed-off-by: Rajendra Nayak Link: https://lore.kernel.org/r/1597227730-16477-1-git-send-email-rnayak@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d1c07decc8d6081f516d19b8b248514e1043367d Author: Stephen Boyd Date: Tue Aug 11 12:25:03 2020 -0700 arm64: dts: qcom: sc7180: Drop flags on mdss irqs [ Upstream commit 51e9874d382e089f664b3ce12773bbbaece5f369 ] The number of interrupt cells for the mdss interrupt controller is 1, meaning there should only be one cell for the interrupt number, not two where the second cell is the irq flags. Drop the second cell to match the binding. Cc: Kalyan Thota Cc: Harigovindan P Link: https://lore.kernel.org/r/20200811192503.1811462-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c29d671b9f0fd80d0ebcadae848bdd0558362074 Author: Krzysztof Kozlowski Date: Fri Sep 4 16:53:09 2020 +0200 arm64: dts: imx8mq: Add missing interrupts to GPC [ Upstream commit 791619f66843a213784efb2f171be98933bad991 ] The i.MX General Power Controller v2 device node was missing interrupts property necessary to route its interrupt to GIC. This also fixes the dbts_check warnings like: arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: gpc@303a0000: {'compatible': ... '$nodename': ['gpc@303a0000']} is not valid under any of the given schemas arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: gpc@303a0000: 'interrupts' is a required property Fixes: fdbcc04da246 ("arm64: dts: imx8mq: add GPC power domains") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Lucas Stach Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 67559b60410e1209895f89b7375293f8416368c0 Author: Peter Ujfalusi Date: Fri Sep 11 21:47:39 2020 -0700 dmaengine: ti: k3-udma-glue: Fix parameters for rx ring pair request [ Upstream commit 6259c8441c4de3f1727a0db61465a8dc8f340c05 ] The original commit mixed up the forward and completion ring IDs for the rx flow configuration. Acked-by: Vinod Koul Reviewed-by: Grygorii Strashko Fixes: 4927b1ab2047 ("dmaengine: ti: k3-udma: Switch to k3_ringacc_request_rings_pair") Signed-off-by: Peter Ujfalusi Signed-off-by: Santosh Shilimkar Signed-off-by: Sasha Levin commit 84f1af07c6cc6944d89de63f6676a9f1e366e51b Author: Manivannan Sadhasivam Date: Fri Sep 4 12:06:33 2020 +0530 arm64: dts: qcom: sm8250: Rename UART2 node to UART12 [ Upstream commit bb1dfb4da1d031380cd631dd0d6884d4e79a8d51 ] The UART12 node has been mistakenly mentioned as UART2. Let's fix that for both SM8250 SoC and MTP board and also add pinctrl definition for it. Fixes: 60378f1a171e ("arm64: dts: qcom: sm8250: Add sm8250 dts file") Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20200904063637.28632-3-manivannan.sadhasivam@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit eda7039748591c892538396f6ceb5d8e025d69f2 Author: Dafna Hirschfeld Date: Thu Sep 3 16:28:19 2020 +0200 arm64: dts: mt8173-elm: fix supported values for regulator-allowed-modes of da9211 [ Upstream commit 9d955478a89b4a1ff4e7442216f2822dee8fde73 ] According to the datasheet the allowed modes for the da9211 regulator are sync and auto mode. This should be changed in the devicetree. This also fix an error message 'BUCKA: invalid regulator-allowed-modes element 0' since value 0 is invalid. Fixes: 689b937beddeb ("arm64: dts: mediatek: add mt8173 elm and hana board") Signed-off-by: Dafna Hirschfeld Tested-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20200903142819.24487-1-dafna.hirschfeld@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 8483df18898a6e4422928b312dc39d51af7beae2 Author: Sudeep Holla Date: Tue Sep 8 12:26:11 2020 +0100 firmware: arm_scmi: Fix NULL pointer dereference in mailbox_chan_free [ Upstream commit 6ed6c558234f0b6c22e47a3c2feddce3d02324dd ] scmi_mailbox is obtained from cinfo->transport_info and the first call to mailbox_chan_free frees the channel and sets cinfo->transport_info to NULL. Care is taken to check for non NULL smbox->chan but smbox can itself be NULL. Fix it by checking for it without which, kernel crashes with below NULL pointer dereference and eventually kernel panic. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Modules linked in: scmi_module(-) Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 2 2020 pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--) pc : mailbox_chan_free+0x2c/0x70 [scmi_module] lr : idr_for_each+0x6c/0xf8 Call trace: mailbox_chan_free+0x2c/0x70 [scmi_module] idr_for_each+0x6c/0xf8 scmi_remove+0xa8/0xf0 [scmi_module] platform_drv_remove+0x34/0x58 device_release_driver_internal+0x118/0x1f0 driver_detach+0x58/0xe8 bus_remove_driver+0x64/0xe0 driver_unregister+0x38/0x68 platform_driver_unregister+0x1c/0x28 scmi_driver_exit+0x38/0x44 [scmi_module] ---[ end trace 17bde19f50436de9 ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs Kernel Offset: 0x1d0000 from 0xffff800010000000 PHYS_OFFSET: 0x80000000 CPU features: 0x0240022,25806004 Memory Limit: none ---[ end Kernel panic - not syncing: Fatal exception ]--- Link: https://lore.kernel.org/r/20200908112611.31515-1-sudeep.holla@arm.com Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Cc: Cristian Marussi Cc: Viresh Kumar Tested-by: Cristian Marussi Reviewed-by: Cristian Marussi Reviewed-by: Viresh Kumar Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 570bcf7d32e8f914157ce734f059778eeca74947 Author: Krzysztof Kozlowski Date: Thu Aug 27 09:33:15 2020 +0200 memory: fsl-corenet-cf: Fix handling of platform_get_irq() error [ Upstream commit dd85345abca60a8916617e8d75c0f9ce334336dd ] platform_get_irq() returns -ERRNO on error. In such case comparison to 0 would pass the check. Fixes: 54afbec0d57f ("memory: Freescale CoreNet Coherency Fabric error reporting driver") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20200827073315.29351-1-krzk@kernel.org Signed-off-by: Sasha Levin commit d125fc753a66d0bf62c9e742f9b6392f6be09b9f Author: Sai Prakash Ranjan Date: Tue Aug 18 20:25:14 2020 +0530 arm64: dts: qcom: sc7180: Fix the LLCC base register size [ Upstream commit efe788361f72914017515223414d3f20abe4b403 ] There is one LLCC logical bank(LLCC0) on SC7180 SoC and the size of the LLCC0 base is 0x50000(320KB) not 2MB, so correct the size and fix copy paste mistake carried over from SDM845. Reviewed-by: Douglas Anderson Fixes: 7cee5c742899 ("arm64: dts: qcom: sc7180: Fix node order") Fixes: c831fa299996 ("arm64: dts: qcom: sc7180: Add Last level cache controller node") Signed-off-by: Sai Prakash Ranjan Link: https://lore.kernel.org/r/20200818145514.16262-1-saiprakash.ranjan@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 18a3b3b42b42efb447b0e39e9b2c47247299bc9b Author: Jonathan Marek Date: Tue Aug 18 12:04:43 2020 -0400 arm64: dts: qcom: sm8150: fix up primary USB nodes [ Upstream commit 79493db5bb573017767b4f48b0fc69bfd01b82d2 ] The compatible for hsphy has out of place indentation, and the assigned clock rate for GCC_USB30_PRIM_MASTER_CLK is incorrect, the clock doesn't support a rate of 150000000. Use a rate of 200000000 to match downstream. Fixes: b33d2868e8d3 ("arm64: dts: qcom: sm8150: Add USB and PHY device nodes") Signed-off-by: Jonathan Marek Link: https://lore.kernel.org/r/20200818160445.14008-1-jonathan@marek.ca Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 59076a927e9a5e668ac7b8507da5b179b87464d4 Author: Vinod Koul Date: Fri Aug 28 13:13:47 2020 +0530 arm64: dts: qcom: sdm845-db845c: Fix hdmi nodes [ Upstream commit bca4339bda0989e49189c164795b120eb261970c ] As per binding documentation, we should have dsi as node 0 and hdmi audio as node 1, so fix it Reported-by: Dmitry Baryshkov Fixes: aef9a119dfb9 ("arm64: dts: qcom: sdm845-db845c: Add hdmi bridge nodes") Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20200828074347.3788518-1-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit daf112a4e1476348cb6a07e4014cd997f68c77c6 Author: Krzysztof Kozlowski Date: Sat Aug 29 13:12:09 2020 +0200 arm64: dts: qcom: msm8992: Fix UART interrupt property [ Upstream commit aa551bd7a04159cf2ca8806abe5da8012b59d058 ] "interrupt" is not a valid property. Fixes: 7f8bcc0c4cfe ("arm64: dts: qcom: msm8992: Add BLSP2_UART2 and I2C nodes") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20200829111209.32685-1-krzk@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f1e099d600004bc84db4d8552a083117596a1558 Author: YueHaibing Date: Thu Aug 27 20:53:16 2020 +0800 memory: omap-gpmc: Fix build error without CONFIG_OF [ Upstream commit 13d029ee51da365aa9c859db0c7395129252bde8 ] If CONFIG_OF is n, gcc fails: drivers/memory/omap-gpmc.o: In function `gpmc_omap_onenand_set_timings': omap-gpmc.c:(.text+0x2a88): undefined reference to `gpmc_read_settings_dt' Add gpmc_read_settings_dt() helper function, which zero the gpmc_settings so the caller doesn't proceed with random/invalid settings. Fixes: a758f50f10cf ("mtd: onenand: omap2: Configure driver from DT") Signed-off-by: YueHaibing Acked-by: Roger Quadros Link: https://lore.kernel.org/r/20200827125316.20780-1-yuehaibing@huawei.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 7adc07a6a0885bb65246cde7a525e4770211d6d6 Author: Dan Carpenter Date: Tue Aug 25 13:47:07 2020 +0300 memory: omap-gpmc: Fix a couple off by ones [ Upstream commit 4c54228ac8fd55044195825873c50a524131fa53 ] These comparisons should be >= instead of > to prevent reading one element beyond the end of the gpmc_cs[] array. Fixes: cdd6928c589a ("ARM: OMAP2+: Add device-tree support for NOR flash") Fixes: f37e4580c409 ("ARM: OMAP2: Dynamic allocator for GPMC memory space") Signed-off-by: Dan Carpenter Acked-by: Roger Quadros Link: https://lore.kernel.org/r/20200825104707.GB278587@mwanda Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit ccd4f9a7fcaf54984503c8302c55035925c09f8e Author: Qiang Yu Date: Sat Aug 22 14:27:55 2020 +0800 arm64: dts: allwinner: h5: remove Mali GPU PMU module [ Upstream commit 2933bf3528007f834fb7f5eab033f9c5b0683f91 ] H5's Mali GPU PMU is not present or working corretly although H5 datasheet record its interrupt vector. Adding this module will miss lead lima driver try to shutdown it and get waiting timeout. This problem is not exposed before lima runtime PM support is added. Fixes: bb39ed07e55b ("arm64: dts: allwinner: h5: Add device node for Mali-450 GPU") Signed-off-by: Qiang Yu Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20200822062755.534761-1-yuq825@gmail.com Signed-off-by: Sasha Levin commit 659fbb04a4718ac7abf3a9b101cdaa3ad3d07c4a Author: Jernej Skrabec Date: Mon Aug 24 21:36:49 2020 +0200 ARM: dts: sun8i: r40: bananapi-m2-ultra: Fix dcdc1 regulator [ Upstream commit 3658a2b7f3e16c7053eb8d70657b94bb62c5a0f4 ] DCDC1 regulator powers many different subsystems. While some of them can work at 3.0 V, some of them can not. For example, VCC-HDMI can only work between 3.24 V and 3.36 V. According to OS images provided by the board manufacturer this regulator should be set to 3.3 V. Set DCDC1 and DCDC1SW to 3.3 V in order to fix this. Fixes: da7ac948fa93 ("ARM: dts: sun8i: Add board dts file for Banana Pi M2 Ultra") Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20200824193649.978197-1-jernej.skrabec@siol.net Signed-off-by: Sasha Levin commit 89343d2545efdeb10dec276fa00c431acc100263 Author: Markus Mayer Date: Sat Aug 22 13:50:00 2020 -0700 memory: brcmstb_dpfe: fix array index out of bounds [ Upstream commit f42ae4bbf94c15aa720afb9d176ecbfe140d792e ] We would overrun the error_text array if we hit a TIMEOUT condition, because we were using the error code "ETIMEDOUT" (which is 110) as an array index. We fix the problem by correcting the array index and by providing a function to retrieve error messages rather than accessing the array directly. The function includes a bounds check that prevents the array from being overrun. Link: https://lore.kernel.org/linux-arm-kernel/38d00022-730c-948a-917c-d86382df8cb9@canonical.com/ Link: https://lore.kernel.org/r/20200822205000.15841-1-mmayer@broadcom.com Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE") Reported-by: Colin Ian King Signed-off-by: Markus Mayer Acked-by: Florian Fainelli Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 985ed6368cbab3a6f6f9015848efc8bba68a68db Author: Arnd Bergmann Date: Thu Aug 6 20:20:20 2020 +0200 ARM: s3c24xx: fix mmc gpio lookup tables [ Upstream commit 3af4e8774b6d03683932b0961998e01355bccd74 ] The gpio controller names differ between s3c24xx and s3c64xx, and it seems that these all got the wrong names, using GPx instead of GPIOx. Fixes: d2951dfa070d ("mmc: s3cmci: Use the slot GPIO descriptor") Signed-off-by: Arnd Bergmann Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20200806182059.2431-3-krzk@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 545db31fd56636e0e4720113e037dd22f4525092 Author: Claudiu Beznea Date: Wed Aug 5 11:36:50 2020 +0300 ARM: at91: pm: of_node_put() after its usage [ Upstream commit e222f943519564978e082c152b4140a47e93392c ] Put node after it has been used. Fixes: 13f16017d3e3f ("ARM: at91: pm: Tie the USB clock mask to the pmc") Signed-off-by: Claudiu Beznea Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/1596616610-15460-4-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit 5676e6941fd9e42c75b3126d025d5fb2944e57be Author: Horia Geantă Date: Wed Jul 15 18:26:01 2020 +0300 ARM: dts: imx6sl: fix rng node [ Upstream commit 82ffb35c2ce63ef8e0325f75eb48022abcf8edbe ] rng DT node was added without a compatible string. i.MX driver for RNGC (drivers/char/hw_random/imx-rngc.c) also claims support for RNGB, and is currently used for i.MX25. Let's use this driver also for RNGB block in i.MX6SL. Fixes: e29fe21cff96 ("ARM: dts: add device tree source for imx6sl SoC") Signed-off-by: Horia Geantă Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 5030ff3a5abe93b42e20421e6776f26f1055d5a4 Author: Jerome Brunet Date: Mon Aug 3 16:18:50 2020 +0200 arm64: dts: meson: vim3: correct led polarity [ Upstream commit 1f9d87d08e4a2299e86f8a1600aedf87ecd3b636 ] The LEDs on the vim3 are active when the gpio is high, not low. Fixes: c6d29c66e582 ("arm64: dts: meson-g12b-khadas-vim3: add initial device-tree") Signed-off-by: Jerome Brunet Signed-off-by: Kevin Hilman Link: https://lore.kernel.org/r/20200803141850.172704-1-jbrunet@baylibre.com Signed-off-by: Sasha Levin commit c3f29079ac2a8736cf9ecf7bc62982ef2b7603c4 Author: Dan Carpenter Date: Fri Jun 5 14:00:20 2020 +0300 soc: xilinx: Fix error code in zynqmp_pm_probe() [ Upstream commit a6f2f0fdc73aacc6e10ae48ae78634dba26702d4 ] This should be returning PTR_ERR() but it returns IS_ERR() instead. Fixes: ffdbae28d9d1 ("drivers: soc: xilinx: Use mailbox IPI callback") Signed-off-by: Dan Carpenter Reviewed-by: Michal Simek Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20200605110020.GA978434@mwanda Signed-off-by: Sasha Levin commit 3bbd53ba677cce6b024d615f314d34381d156191 Author: Pablo Neira Ayuso Date: Wed Oct 21 12:55:52 2020 +0200 netfilter: nf_fwd_netdev: clear timestamp in forwarding path [ Upstream commit c77761c8a59405cb7aa44188b30fffe13fbdd02d ] Similar to 7980d2eabde8 ("ipvs: clear skb->tstamp in forwarding path"). fq qdisc requires tstamp to be cleared in forwarding path. Fixes: 8203e2d844d3 ("net: clear skb->tstamp in forwarding paths") Fixes: fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC") Fixes: 80b14dee2bea ("net: Add a new socket option for a future transmit time.") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 4439fec7e7547b06c6efdcfdd083ebf38e7d6eda Author: Eli Cohen Date: Tue Sep 8 15:33:46 2020 +0300 vdpa/mlx5: Setup driver only if VIRTIO_CONFIG_S_DRIVER_OK [ Upstream commit 1897f0b618b0af0eb9dca709ab6bdf9ef1969ef7 ] set_map() is used by mlx5 vdpa to create a memory region based on the address map passed by the iotlb argument. If we get successive calls, we will destroy the current memory region and build another one based on the new address mapping. We also need to setup the hardware resources since they depend on the memory region. If these calls happen before DRIVER_OK, It means that driver VQs may also not been setup and we may not create them yet. In this case we want to avoid setting up the other resources and defer this till we get DRIVER OK. Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Eli Cohen Link: https://lore.kernel.org/r/20200908123346.GA169007@mtl-vdi-166.wap.labs.mlnx Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit cde94b533acc687d696f4717b66676c55080887a Author: Eli Cohen Date: Thu Sep 17 15:15:40 2020 +0300 vdpa/mlx5: Fix failure to bring link up [ Upstream commit 36b02df2d204da9f7a571f16ed9e91a4d083f207 ] Set VIRTIO_NET_S_LINK_UP in config status to allow the get the bring the net device's link up. Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Eli Cohen Link: https://lore.kernel.org/r/20200917121540.GA98184@mtl-vdi-166.wap.labs.mlnx Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit 3460f161b570c797dd47d3be9029993508133a44 Author: Eli Cohen Date: Thu Sep 17 15:14:25 2020 +0300 vdpa/mlx5: Make use of a specific 16 bit endianness API [ Upstream commit 36bdcf318bc21af24de10b68e32cdea6b9a8d17f ] Introduce a dedicated function to be used for setting 16 bit fields per virio endianness requirements and use it to set the mtu field. Signed-off-by: Eli Cohen Link: https://lore.kernel.org/r/20200917121425.GA98139@mtl-vdi-166.wap.labs.mlnx Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit b7d23c2c87584eb429f115c078ed511be8b18e29 Author: Timothée COCAULT Date: Wed Oct 14 12:36:15 2020 +0000 netfilter: ebtables: Fixes dropping of small packets in bridge nat [ Upstream commit 63137bc5882a1882c553d389fdeeeace86ee1741 ] Fixes an error causing small packets to get dropped. skb_ensure_writable expects the second parameter to be a length in the ethernet payload.=20 If we want to write the ethernet header (src, dst), we should pass 0. Otherwise, packets with small payloads (< ETH_ALEN) will get dropped. Fixes: c1a831167901 ("netfilter: bridge: convert skb_make_writable to skb_ensure_writable") Signed-off-by: Timothée COCAULT Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 790e611eea052fe6743e4ceb67ec24023b897480 Author: Francesco Ruggeri Date: Wed Oct 7 12:32:52 2020 -0700 netfilter: conntrack: connection timeout after re-register [ Upstream commit 4f25434bccc28cf8a07876ef5142a2869a674353 ] If the first packet conntrack sees after a re-register is an outgoing keepalive packet with no data (SEG.SEQ = SND.NXT-1), td_end is set to SND.NXT-1. When the peer correctly acknowledges SND.NXT, tcp_in_window fails check III (Upper bound for valid (s)ack: sack <= receiver.td_end) and returns false, which cascades into nf_conntrack_in setting skb->_nfct = 0 and in later conntrack iptables rules not matching. In cases where iptables are dropping packets that do not match conntrack rules this can result in idle tcp connections to time out. v2: adjust td_end when getting the reply rather than when sending out the keepalive packet. Fixes: f94e63801ab2 ("netfilter: conntrack: reset tcp maxwin on re-register") Signed-off-by: Francesco Ruggeri Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1ced28122aa872d1242fc2d98da0473737262310 Author: Maxim Kochetkov Date: Mon Oct 19 08:06:25 2020 +0300 net: dsa: seville: the packet buffer is 2 megabits, not megabytes [ Upstream commit a15a6afb3bf9388eb83a4b876d3453f305fba909 ] The VSC9953 Seville switch has 2 megabits of buffer split into 4360 words of 60 bytes each. 2048 * 1024 is 2 megabytes instead of 2 megabits. 2 megabits is (2048 / 8) * 1024 = 256 * 1024. Signed-off-by: Maxim Kochetkov Reviewed-by: Vladimir Oltean Fixes: a63ed92d217f ("net: dsa: seville: fix buffer size of the queue system") Link: https://lore.kernel.org/r/20201019050625.21533-1-fido_max@inbox.ru Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 79e1957821f52af4a8792a0c4ac7de651ca41dfa Author: Martin KaFai Lau Date: Mon Oct 19 12:42:12 2020 -0700 bpf: Enforce id generation for all may-be-null register type [ Upstream commit 93c230e3f5bd6e1d2b2759d582fdfe9c2731473b ] The commit af7ec1383361 ("bpf: Add bpf_skc_to_tcp6_sock() helper") introduces RET_PTR_TO_BTF_ID_OR_NULL and the commit eaa6bcb71ef6 ("bpf: Introduce bpf_per_cpu_ptr()") introduces RET_PTR_TO_MEM_OR_BTF_ID_OR_NULL. Note that for RET_PTR_TO_MEM_OR_BTF_ID_OR_NULL, the reg0->type could become PTR_TO_MEM_OR_NULL which is not covered by BPF_PROBE_MEM. The BPF_REG_0 will then hold a _OR_NULL pointer type. This _OR_NULL pointer type requires the bpf program to explicitly do a NULL check first. After NULL check, the verifier will mark all registers having the same reg->id as safe to use. However, the reg->id is not set for those new _OR_NULL return types. One of the ways that may be wrong is, checking NULL for one btf_id typed pointer will end up validating all other btf_id typed pointers because all of them have id == 0. The later tests will exercise this path. To fix it and also avoid similar issue in the future, this patch moves the id generation logic out of each individual RET type test in check_helper_call(). Instead, it does one reg_type_may_be_null() test and then do the id generation if needed. This patch also adds a WARN_ON_ONCE in mark_ptr_or_null_reg() to catch future breakage. The _OR_NULL pointer usage in the bpf_iter_reg.ctx_arg_info is fine because it just happens that the existing id generation after check_ctx_access() has covered it. It is also using the reg_type_may_be_null() to decide if id generation is needed or not. Fixes: af7ec1383361 ("bpf: Add bpf_skc_to_tcp6_sock() helper") Fixes: eaa6bcb71ef6 ("bpf: Introduce bpf_per_cpu_ptr()") Signed-off-by: Martin KaFai Lau Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20201019194212.1050855-1-kafai@fb.com Signed-off-by: Sasha Levin commit 0409c06fe168dbd8a2a94e34bb0f40962ccf7485 Author: Ard Biesheuvel Date: Thu Oct 8 17:35:59 2020 +0200 arm64: mm: use single quantity to represent the PA to VA translation [ Upstream commit 7bc1a0f9e1765830e945669c99c59c35cf9bca82 ] On arm64, the global variable memstart_addr represents the physical address of PAGE_OFFSET, and so physical to virtual translations or vice versa used to come down to simple additions or subtractions involving the values of PAGE_OFFSET and memstart_addr. When support for 52-bit virtual addressing was introduced, we had to deal with PAGE_OFFSET potentially being outside of the region that can be covered by the virtual range (as the 52-bit VA capable build needs to be able to run on systems that are only 48-bit VA capable), and for this reason, another translation was introduced, and recorded in the global variable physvirt_offset. However, if we go back to the original definition of memstart_addr, i.e., the physical address of PAGE_OFFSET, it turns out that there is no need for two separate translations: instead, we can simply subtract the size of the unaddressable VA space from memstart_addr to make the available physical memory appear in the 48-bit addressable VA region. This simplifies things, but also fixes a bug on KASLR builds, which may update memstart_addr later on in arm64_memblock_init(), but fails to update vmemmap and physvirt_offset accordingly. Fixes: 5383cc6efed1 ("arm64: mm: Introduce vabits_actual") Signed-off-by: Ard Biesheuvel Reviewed-by: Steve Capper Link: https://lore.kernel.org/r/20201008153602.9467-2-ardb@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit be81691c39d868aed49065cdb5c5c853cc4c636c Author: Jing Xiangfeng Date: Fri Sep 25 14:24:23 2020 +0800 scsi: bfa: Fix error return in bfad_pci_init() [ Upstream commit f0f6c3a4fcb80fcbcce4ff6739996dd98c228afd ] Fix to return error code -ENODEV from the error handling case instead of 0. Link: https://lore.kernel.org/r/20200925062423.161504-1-jingxiangfeng@huawei.com Fixes: 11ea3824140c ("scsi: bfa: fix calls to dma_set_mask_and_coherent()") Signed-off-by: Jing Xiangfeng Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f482fd2a6bb782d8fa857d954c01e92b86011c9d Author: Krish Sadhukhan Date: Sat Aug 29 00:48:22 2020 +0000 KVM: nSVM: CR3 MBZ bits are only 63:52 [ Upstream commit fb0f33fdefe9f473dc5f7b71345096c8d60ab9dd ] Commit 761e4169346553c180bbd4a383aedd72f905bc9a created a wrong mask for the CR3 MBZ bits. According to APM vol 2, only the upper 12 bits are MBZ. Fixes: 761e41693465 ("KVM: nSVM: Check that MBZ bits in CR3 and CR4 are not set on vmrun of nested guests", 2020-07-08) Signed-off-by: Krish Sadhukhan Message-Id: <20200829004824.4577-2-krish.sadhukhan@oracle.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 4c25173e0853e7fa0dbc0d9e8993e380f8596334 Author: Robert Hoo Date: Fri Aug 28 10:23:42 2020 +0800 KVM: x86: emulating RDPID failure shall return #UD rather than #GP [ Upstream commit a9e2e0ae686094571378c72d8146b5a1a92d0652 ] Per Intel's SDM, RDPID takes a #UD if it is unsupported, which is more or less what KVM is emulating when MSR_TSC_AUX is not available. In fact, there are no scenarios in which RDPID is supposed to #GP. Fixes: fb6d4d340e ("KVM: x86: emulate RDPID") Signed-off-by: Robert Hoo Message-Id: <1598581422-76264-1-git-send-email-robert.hu@linux.intel.com> Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 429cbd0a4dcb344e9c5a3194fcf89a44f6d47a64 Author: Krzysztof Kozlowski Date: Tue Sep 15 17:56:40 2020 -0700 Input: sun4i-ps2 - fix handling of platform_get_irq() error [ Upstream commit cafb3abea6136e59ea534004e5773361e196bb94 ] platform_get_irq() returns -ERRNO on error. In such case comparison to 0 would pass the check. Fixes: e443631d20f5 ("Input: serio - add support for Alwinner A10/A20 PS/2 controller") Signed-off-by: Krzysztof Kozlowski Acked-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20200828145744.3636-4-krzk@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 3c3e98b52b03d12af44f15f56155e8fcacfb4543 Author: Krzysztof Kozlowski Date: Tue Sep 15 17:56:19 2020 -0700 Input: twl4030_keypad - fix handling of platform_get_irq() error [ Upstream commit c277e1f0dc3c7d7b5b028e20dd414df241642036 ] platform_get_irq() returns -ERRNO on error. In such case casting to unsigned and comparing to 0 would pass the check. Fixes: 7abf38d6d13c ("Input: twl4030-keypad - add device tree support") Reported-by: kernel test robot Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20200828145744.3636-3-krzk@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit da948496b6528ff05c29754bb2d15ee17c3fe8e5 Author: Krzysztof Kozlowski Date: Tue Sep 15 17:52:15 2020 -0700 Input: omap4-keypad - fix handling of platform_get_irq() error [ Upstream commit 4738dd1992fa13acfbbd71800c71c612f466fa44 ] platform_get_irq() returns -ERRNO on error. In such case comparison to 0 would pass the check. Fixes: f3a1ba60dbdb ("Input: omap4-keypad - use platform device helpers") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20200828145744.3636-2-krzk@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 9996f58b63ab4204b27290c9cfd1497db29690ea Author: Krzysztof Kozlowski Date: Tue Sep 15 17:51:05 2020 -0700 Input: ep93xx_keypad - fix handling of platform_get_irq() error [ Upstream commit 7d50f6656dacf085a00beeedbc48b19a37d17881 ] platform_get_irq() returns -ERRNO on error. In such case comparison to 0 would pass the check. Fixes: 60214f058f44 ("Input: ep93xx_keypad - update driver to new core support") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20200828145744.3636-1-krzk@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 18a1a9c6dd513ca53de191b437636bd447d54449 Author: YueHaibing Date: Wed Sep 16 10:26:09 2020 -0700 Input: stmfts - fix a & vs && typo [ Upstream commit d04afe14b23651e7a8bc89727a759e982a8458e4 ] In stmfts_sysfs_hover_enable_write(), we should check value and sdata->hover_enabled is all true. Fixes: 78bcac7b2ae1 ("Input: add support for the STMicroelectronics FingerTip touchscreen") Signed-off-by: YueHaibing Link: https://lore.kernel.org/r/20200916141941.16684-1-yuehaibing@huawei.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 11f2a1d1911d9923bab3ef546a96932132fb3dfb Author: Dan Carpenter Date: Mon Sep 14 10:17:01 2020 -0700 Input: imx6ul_tsc - clean up some errors in imx6ul_tsc_resume() [ Upstream commit 30df23c5ecdfb8da5b0bc17ceef67eff9e1b0957 ] If imx6ul_tsc_init() fails then we need to clean up the clocks. I reversed the "if (input_dev->users) {" condition to make the code a bit simpler. Fixes: 6cc527b05847 ("Input: imx6ul_tsc - propagate the errors") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20200905124942.GC183976@mwanda Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 4bb7b5e2606b98168992bc48349d7ff13b392aee Author: Johnny Chuang Date: Wed Sep 16 10:26:57 2020 -0700 Input: elants_i2c - fix typo for an attribute to show calibration count [ Upstream commit 93f634069707cfe562c38739f5062feccbe9a834 ] Fixed typo for command from 0xE0 to 0xD0. Fixes: cf520c643012 ("Input: elants_i2c - provide an attribute to show calibration count") Signed-off-by: Johnny Chuang Link: https://lore.kernel.org/r/1600238783-32303-1-git-send-email-johnny.chuang.emc@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 4964fa421339b2d04a4caef75d0490162c7de463 Author: Gwendal Grignou Date: Sat Aug 29 23:59:37 2020 -0700 platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command [ Upstream commit 1e7913ff5f9f1b73146ad8522958bd266f22a510 ] By default, the lightbar commands are set to the biggest lightbar command and response. That length is greater than 128 bytes and may not work on all machines. But all EC are probed for lightbar by sending a get version request. Set that request size precisely. Before the command would be: cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 194, insize: 128, result: 0 Afer: cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 1, insize: 8, result: 0 Fixes: a841178445bb7 ("mfd: cros_ec: Use a zero-length array for command data") Signed-off-by: Gwendal Grignou Signed-off-by: Enric Balletbo i Serra Signed-off-by: Sasha Levin commit 33c2d0360b06f1e0029f3b74bbbbdf674d1a9bbb Author: Azhar Shaikh Date: Fri Aug 21 14:47:22 2020 -0700 platform/chrome: cros_ec_typec: Send enum values to usb_role_switch_set_role() [ Upstream commit 5381b0ed54b6af3c0e8184b43e34154e17904848 ] usb_role_switch_set_role() has the second argument as enum for usb_role. Currently depending upon the data role i.e. UFP(0) or DFP(1) is sent. This eventually translates to USB_ROLE_NONE in case of UFP and USB_ROLE_DEVICE in case of DFP. Correct this by sending correct enum values as USB_ROLE_DEVICE in case of UFP and USB_ROLE_HOST in case of DFP. Fixes: 7e7def15fa4b ("platform/chrome: cros_ec_typec: Add USB mux control") Signed-off-by: Azhar Shaikh Cc: Prashant Malani Reviewed-by: Prashant Malani Reviewed-by: Heikki Krogerus Signed-off-by: Enric Balletbo i Serra Signed-off-by: Sasha Levin commit faa7b07c65a60707e606617b216fac927f17175b Author: Dai Ngo Date: Sun Oct 18 23:42:49 2020 -0400 NFSv4.2: Fix NFS4ERR_STALE error when doing inter server copy [ Upstream commit 0cfcd405e758ba1d277e58436fb32f06888c3e41 ] NFS_FS=y as dependency of CONFIG_NFSD_V4_2_INTER_SSC still have build errors and some configs with NFSD=m to get NFS4ERR_STALE error when doing inter server copy. Added ops table in nfs_common for knfsd to access NFS client modules. Fixes: 3ac3711adb88 ("NFSD: Fix NFS server build errors") Signed-off-by: Dai Ngo Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 2b8b5aa05cf8954f91e1b6740b8f2f04c610444e Author: Martijn de Gouw Date: Mon Oct 19 13:42:27 2020 +0200 SUNRPC: fix copying of multiple pages in gss_read_proxy_verf() [ Upstream commit d48c8124749c9a5081fe68680f83605e272c984b ] When the passed token is longer than 4032 bytes, the remaining part of the token must be copied from the rqstp->rq_arg.pages. But the copy must make sure it happens in a consecutive way. With the existing code, the first memcpy copies 'length' bytes from argv->iobase, but since the header is in front, this never fills the whole first page of in_token->pages. The mecpy in the loop copies the following bytes, but starts writing at the next page of in_token->pages. This leaves the last bytes of page 0 unwritten. Symptoms were that users with many groups were not able to access NFS exports, when using Active Directory as the KDC. Signed-off-by: Martijn de Gouw Fixes: 5866efa8cbfb "SUNRPC: Fix svcauth_gss_proxy_init()" Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 81ed921d03fb4abb6c24531af3dd09ee5a913df0 Author: Abel Vesa Date: Thu Oct 15 12:25:44 2020 +0300 clk: imx8mq: Fix usdhc parents order [ Upstream commit b159c63d82ff8ffddc6c6f0eb881b113b36ecad7 ] According to the latest RM (see Table 5-1. Clock Root Table), both usdhc root clocks have the parent order as follows: 000 - 25M_REF_CLK 001 - SYSTEM_PLL1_DIV2 010 - SYSTEM_PLL1_CLK 011 - SYSTEM_PLL2_DIV2 100 - SYSTEM_PLL3_CLK 101 - SYSTEM_PLL1_DIV3 110 - AUDIO_PLL2_CLK 111 - SYSTEM_PLL1_DIV8 So the audio_pll2_out and sys3_pll_out have to be swapped. Fixes: b80522040cd3 ("clk: imx: Add clock driver for i.MX8MQ CCM") Signed-off-by: Abel Vesa Reported-by: Cosmin Stefan Stoica Link: https://lore.kernel.org/r/1602753944-30757-1-git-send-email-abel.vesa@nxp.com Reviewed-by: Fabio Estevam Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit d8993487f8d761c590665fed514c65eb7ab94603 Author: Stephen Boyd Date: Fri Oct 16 19:01:37 2020 -0700 clk: qcom: gdsc: Keep RETAIN_FF bit set if gdsc is already on [ Upstream commit fda48bf5c86d88fd7074e318f290ad636dff4eaa ] If the GDSC is enabled out of boot but doesn't have the retain ff bit set we will get confusing results where the registers that are powered by the GDSC lose their contents on the first power off of the GDSC but thereafter they retain their contents. This is because gdsc_init() fails to make sure the RETAIN_FF bit is set when it probes the GDSC the first time and thus powering off the GDSC causes the register contents to be reset. We do set the RETAIN_FF bit the next time we power on the GDSC, see gdsc_enable(), so that subsequent GDSC power off's don't lose register contents state. Forcibly set the bit at device probe time so that the kernel's assumed view of the GDSC is consistent with the state of the hardware. This fixes a problem where the audio PLL doesn't work on sc7180 when the bootloader leaves the lpass_core_hm GDSC enabled at boot (e.g. to make a noise) but critically doesn't set the RETAIN_FF bit. Cc: Douglas Anderson Cc: Taniya Das Cc: Rajendra Nayak Fixes: 173722995cdb ("clk: qcom: gdsc: Add support to enable retention of GSDCR") Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20201017020137.1251319-1-sboyd@kernel.org Reviewed-by: Taniya Das Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson Signed-off-by: Sasha Levin commit 54a5a665b393c1a74b183adc3a979c478b456e87 Author: Xiaoyang Xu Date: Fri Oct 16 17:35:58 2020 +0800 vfio iommu type1: Fix memory leak in vfio_iommu_type1_pin_pages [ Upstream commit 2e6cfd496f5b57034cf2aec738799571b5a52124 ] pfn is not added to pfn_list when vfio_add_to_pfn_list fails. vfio_unpin_page_external will exit directly without calling vfio_iova_put_vfio_pfn. This will lead to a memory leak. Fixes: a54eb55045ae ("vfio iommu type1: Add support for mediated devices") Signed-off-by: Xiaoyang Xu [aw: simplified logic, add Fixes] Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 098b4078cc75634a710c83f5294886121371f48b Author: Alex Williamson Date: Mon Oct 19 07:13:55 2020 -0600 vfio/pci: Clear token on bypass registration failure [ Upstream commit 852b1beecb6ff9326f7ca4bc0fe69ae860ebdb9e ] The eventfd context is used as our irqbypass token, therefore if an eventfd is re-used, our token is the same. The irqbypass code will return an -EBUSY in this case, but we'll still attempt to unregister the producer, where if that duplicate token still exists, results in removing the wrong object. Clear the token of failed producers so that they harmlessly fall out when unregistered. Fixes: 6d7425f109d2 ("vfio: Register/unregister irq_bypass_producer") Reported-by: guomin chen Tested-by: guomin chen Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 7f2163212646646836a97168a54d694324aa1f30 Author: Darrick J. Wong Date: Thu Oct 1 15:21:48 2020 -0700 ext4: limit entries returned when counting fsmap records [ Upstream commit af8c53c8bc087459b1aadd4c94805d8272358d79 ] If userspace asked fsmap to try to count the number of entries, we cannot return more than UINT_MAX entries because fmh_entries is u32. Therefore, stop counting if we hit this limit or else we will waste time to return truncated results. Fixes: 0c9ec4beecac ("ext4: support GETFSMAP ioctls") Signed-off-by: Darrick J. Wong Link: https://lore.kernel.org/r/20201001222148.GA49520@magnolia Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit aa6d245fa0fe8b0a6184d6a2fb857df5e871815e Author: Xiao Yang Date: Fri Aug 28 16:43:30 2020 +0800 ext4: disallow modifying DAX inode flag if inline_data has been set [ Upstream commit aa2f77920b743c44e02e2dc8474bbf8bd30007a2 ] inline_data is mutually exclusive to DAX so enabling both of them triggers the following issue: ------------------------------------------ # mkfs.ext4 -F -O inline_data /dev/pmem1 ... # mount /dev/pmem1 /mnt # echo 'test' >/mnt/file # lsattr -l /mnt/file /mnt/file Inline_Data # xfs_io -c "chattr +x" /mnt/file # xfs_io -c "lsattr -v" /mnt/file [dax] /mnt/file # umount /mnt # mount /dev/pmem1 /mnt # cat /mnt/file cat: /mnt/file: Numerical result out of range ------------------------------------------ Fixes: b383a73f2b83 ("fs/ext4: Introduce DAX inode flag") Signed-off-by: Xiao Yang Reviewed-by: Jan Kara Reviewed-by: Ira Weiny Reviewed-by: Andreas Dilger Link: https://lore.kernel.org/r/20200828084330.15776-1-yangx.jy@cn.fujitsu.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 24c8b035faf24aa1f73a041e6c718e7b65dd0903 Author: Jan Kara Date: Thu Sep 24 17:09:59 2020 +0200 ext4: discard preallocations before releasing group lock [ Upstream commit 5b3dc19dda6691e8ab574e8eede1aef6f02a4f1c ] ext4_mb_discard_group_preallocations() can be releasing group lock with preallocations accumulated on its local list. Thus although discard_pa_seq was incremented and concurrent allocating processes will be retrying allocations, it can happen that premature ENOSPC error is returned because blocks used for preallocations are not available for reuse yet. Make sure we always free locally accumulated preallocations before releasing group lock. Fixes: 07b5b8e1ac40 ("ext4: mballoc: introduce pcpu seqcnt for freeing PA to improve ENOSPC handling") Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20200924150959.4335-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 44e26e8d8315d9015ef9bfbf4b4df2badfbbfd96 Author: Ye Bin Date: Wed Sep 16 19:38:59 2020 +0800 ext4: fix dead loop in ext4_mb_new_blocks [ Upstream commit 70022da804f0f3f152115688885608c39182082e ] As we test disk offline/online with running fsstress, we find fsstress process is keeping running state. kworker/u32:3-262 [004] ...1 140.787471: ext4_mb_discard_preallocations: dev 8,32 needed 114 .... kworker/u32:3-262 [004] ...1 140.787471: ext4_mb_discard_preallocations: dev 8,32 needed 114 ext4_mb_new_blocks repeat: ext4_mb_discard_preallocations_should_retry(sb, ac, &seq) freed = ext4_mb_discard_preallocations ext4_mb_discard_group_preallocations this_cpu_inc(discard_pa_seq); ---> freed == 0 seq_retry = ext4_get_discard_pa_seq_sum for_each_possible_cpu(__cpu) __seq += per_cpu(discard_pa_seq, __cpu); if (seq_retry != *seq) { *seq = seq_retry; ret = true; } As we see seq_retry is sum of discard_pa_seq every cpu, if ext4_mb_discard_group_preallocations return zero discard_pa_seq in this cpu maybe increase one, so condition "seq_retry != *seq" have always been met. Ritesh Harjani suggest to in ext4_mb_discard_group_preallocations function we only increase discard_pa_seq when there is some PA to free. Fixes: 07b5b8e1ac40 ("ext4: mballoc: introduce pcpu seqcnt for freeing PA to improve ENOSPC handling") Signed-off-by: Ye Bin Reviewed-by: Jan Kara Reviewed-by: Ritesh Harjani Link: https://lore.kernel.org/r/20200916113859.1556397-3-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit b928b1935d85620de49ca2dcf0ccb264973753ef Author: Dan Aloni Date: Fri Oct 2 22:33:43 2020 +0300 svcrdma: fix bounce buffers for unaligned offsets and multiple pages [ Upstream commit c327a310ec4d6ecbea13185ed56c11def441d9ab ] This was discovered using O_DIRECT at the client side, with small unaligned file offsets or IOs that span multiple file pages. Fixes: e248aa7be86 ("svcrdma: Remove max_sge check at connect time") Signed-off-by: Dan Aloni Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit a8ba752a126c0b9291e6a34eb02c3ed57857a7b7 Author: Claudiu Beznea Date: Wed Oct 14 17:34:32 2020 +0300 clk: at91: sam9x60: support only two programmable clocks [ Upstream commit fcedb589b5a88d73d3155c4a8690d6dda91a3156 ] According to datasheet (Chapter 29.16.13, PMC Programmable Clock Register) there are only two programmable clocks on SAM9X60. Fixes: 01e2113de9a5 ("clk: at91: add sam9x60 pmc driver") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/1602686072-28296-1-git-send-email-claudiu.beznea@microchip.com Acked-by: Nicolas Ferre Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit b39f0f308aed1132af6eafee435a5f69f7fc8358 Author: Guenter Roeck Date: Thu Sep 10 09:31:08 2020 -0700 watchdog: sp5100: Fix definition of EFCH_PM_DECODEEN3 [ Upstream commit 08c619b4923056b5dd2d5045757468c76ad0e3fe ] EFCH_PM_DECODEEN3 is supposed to access DECODEEN register bits 24..31, in other words the register at byte offset 3. Cc: Jan Kiszka Fixes: 887d2ec51e34b ("watchdog: sp5100_tco: Add support for recent FCH versions") Tested-by: Jan Kiszka Link: https://lore.kernel.org/r/20200910163109.235136-1-linux@roeck-us.net Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 9f4439b85d0295edfdbda9f99dd5cabfb5d5b36a Author: Dinghao Liu Date: Mon Aug 24 11:12:30 2020 +0800 watchdog: Use put_device on error [ Upstream commit 937425d4cd3ae4e2882b41e332bbbab616bcf0ad ] We should use put_device() instead of freeing device directly after device_initialize(). Fixes: cb36e29bb0e4b ("watchdog: initialize device before misc_register") Signed-off-by: Dinghao Liu Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20200824031230.31050-1-dinghao.liu@zju.edu.cn Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 6bd1c9e3c0921e267e9d7483e1e94e6baf5fd7b8 Author: Dinghao Liu Date: Mon Aug 24 10:40:01 2020 +0800 watchdog: Fix memleak in watchdog_cdev_register [ Upstream commit 5afb6d203d0293512aa2c6ae098274a2a4f6ed02 ] When watchdog_kworker is NULL, we should free wd_data before the function returns to prevent memleak. Fixes: 664a39236e718 ("watchdog: Introduce hardware maximum heartbeat in watchdog core") Signed-off-by: Dinghao Liu Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20200824024001.25474-1-dinghao.liu@zju.edu.cn Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 38e14d7c02f3f8900f559755c20f3025ee7f07bf Author: Masahiro Yamada Date: Wed Oct 14 03:38:19 2020 +0900 kbuild: deb-pkg: do not build linux-headers package if CONFIG_MODULES=n [ Upstream commit bac977cbc0d6731fb8e67c2be0e4acbd959e10b3 ] Since commit 269a535ca931 ("modpost: generate vmlinux.symvers and reuse it for the second modpost"), with CONFIG_MODULES disabled, "make deb-pkg" (or "make bindeb-pkg") fails with: find: ‘Module.symvers’: No such file or directory If CONFIG_MODULES is disabled, it doesn't really make sense to build the linux-headers package. Fixes: 269a535ca931 ("modpost: generate vmlinux.symvers and reuse it for the second modpost") Reported-by: Josh Triplett Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 7108a44911dec72e2da58baa368e3fc8f6f009e8 Author: Navid Emamdoost Date: Sun Aug 9 18:11:58 2020 -0500 clk: bcm2835: add missing release if devm_clk_hw_register fails [ Upstream commit f6c992ca7dd4f49042eec61f3fb426c94d901675 ] In the implementation of bcm2835_register_pll(), the allocated pll is leaked if devm_clk_hw_register() fails to register hw. Release pll if devm_clk_hw_register() fails. Signed-off-by: Navid Emamdoost Link: https://lore.kernel.org/r/20200809231202.15811-1-navid.emamdoost@gmail.com Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 02c941d4d7c53eb05a40dab678c89a9d000fb116 Author: Claudiu Beznea Date: Tue Aug 25 09:59:10 2020 +0300 clk: at91: clk-main: update key before writing AT91_CKGR_MOR [ Upstream commit 85d071e7f19a6a9abf30476b90b3819642568756 ] SAMA5D2 datasheet specifies on chapter 33.22.8 (PMC Clock Generator Main Oscillator Register) that writing any value other than 0x37 on KEY field aborts the write operation. Use the key when selecting main clock parent. Fixes: 27cb1c2083373 ("clk: at91: rework main clk implementation") Signed-off-by: Claudiu Beznea Reviewed-by: Alexandre Belloni Link: https://lore.kernel.org/r/1598338751-20607-3-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 79d50bf4a8583940c62a8866b4eef191f7c4c871 Author: Daniel Jordan Date: Thu Oct 8 13:32:20 2020 -0400 module: statically initialize init section freeing data [ Upstream commit fdf09ab887829cd1b671e45d9549f8ec1ffda0fa ] Corentin hit the following workqueue warning when running with CRYPTO_MANAGER_EXTRA_TESTS: WARNING: CPU: 2 PID: 147 at kernel/workqueue.c:1473 __queue_work+0x3b8/0x3d0 Modules linked in: ghash_generic CPU: 2 PID: 147 Comm: modprobe Not tainted 5.6.0-rc1-next-20200214-00068-g166c9264f0b1-dirty #545 Hardware name: Pine H64 model A (DT) pc : __queue_work+0x3b8/0x3d0 Call trace: __queue_work+0x3b8/0x3d0 queue_work_on+0x6c/0x90 do_init_module+0x188/0x1f0 load_module+0x1d00/0x22b0 I wasn't able to reproduce on x86 or rpi 3b+. This is WARN_ON(!list_empty(&work->entry)) from __queue_work(), and it happens because the init_free_wq work item isn't initialized in time for a crypto test that requests the gcm module. Some crypto tests were recently moved earlier in boot as explained in commit c4741b230597 ("crypto: run initcalls for generic implementations earlier"), which went into mainline less than two weeks before the Fixes commit. Avoid the warning by statically initializing init_free_wq and the corresponding llist. Link: https://lore.kernel.org/lkml/20200217204803.GA13479@Red/ Fixes: 1a7b7d922081 ("modules: Use vmalloc special flag") Reported-by: Corentin Labbe Tested-by: Corentin Labbe Tested-on: sun50i-h6-pine-h64 Tested-on: imx8mn-ddr4-evk Tested-on: sun50i-a64-bananapi-m64 Reviewed-by: Eric Biggers Signed-off-by: Daniel Jordan Signed-off-by: Jessica Yu Signed-off-by: Sasha Levin commit a3de4717643b388e40323e53979dded24454f03d Author: Hanks Chen Date: Thu Jul 30 21:30:16 2020 +0800 clk: mediatek: add UART0 clock support [ Upstream commit 804a892456b73604b7ecfb1b00a96a29f3d2aedf ] Add MT6779 UART0 clock support. Fixes: 710774e04861 ("clk: mediatek: Add MT6779 clock support") Signed-off-by: Wendell Lin Signed-off-by: Hanks Chen Reviewed-by: Matthias Brugger Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4f621de73d43059aeb9a32e9be08e761c385e893 Author: Stephen Boyd Date: Wed Sep 23 17:41:44 2020 -0700 clk: rockchip: Initialize hw to error to avoid undefined behavior [ Upstream commit b608f11d49ec671739604cc763248d8e8fadbbeb ] We can get down to this return value from ERR_CAST() without initializing hw. Set it to -ENOMEM so that we always return something sane. Fixes the following smatch warning: drivers/clk/rockchip/clk-half-divider.c:228 rockchip_clk_register_halfdiv() error: uninitialized symbol 'hw'. drivers/clk/rockchip/clk-half-divider.c:228 rockchip_clk_register_halfdiv() warn: passing zero to 'ERR_CAST' Cc: Elaine Zhang Cc: Heiko Stuebner Fixes: 956060a52795 ("clk: rockchip: add support for half divider") Reviewed-by: Heiko Stuebner Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 1ff3584589d272e9d32660ca52b6add5fad6293f Author: Dexuan Cui Date: Fri Oct 2 01:51:58 2020 -0700 PCI: hv: Fix hibernation in case interrupts are not re-created [ Upstream commit 915cff7f38c5e4d47f187f8049245afc2cb3e503 ] pci_restore_msi_state() directly writes the MSI/MSI-X related registers via MMIO. On a physical machine, this works perfectly; for a Linux VM running on a hypervisor, which typically enables IOMMU interrupt remapping, the hypervisor usually should trap and emulate the MMIO accesses in order to re-create the necessary interrupt remapping table entries in the IOMMU, otherwise the interrupts can not work in the VM after hibernation. Hyper-V is different from other hypervisors in that it does not trap and emulate the MMIO accesses, and instead it uses a para-virtualized method, which requires the VM to call hv_compose_msi_msg() to notify the hypervisor of the info that would be passed to the hypervisor in the case of the trap-and-emulate method. This is not an issue to a lot of PCI device drivers, which destroy and re-create the interrupts across hibernation, so hv_compose_msi_msg() is called automatically. However, some PCI device drivers (e.g. the in-tree GPU driver nouveau and the out-of-tree Nvidia proprietary GPU driver) do not destroy and re-create MSI/MSI-X interrupts across hibernation, so hv_pci_resume() has to call hv_compose_msi_msg(), otherwise the PCI device drivers can no longer receive interrupts after the VM resumes from hibernation. Hyper-V is also different in that chip->irq_unmask() may fail in a Linux VM running on Hyper-V (on a physical machine, chip->irq_unmask() can not fail because unmasking an MSI/MSI-X register just means an MMIO write): during hibernation, when a CPU is offlined, the kernel tries to move the interrupt to the remaining CPUs that haven't been offlined yet. In this case, hv_irq_unmask() -> hv_do_hypercall() always fails because the vmbus channel has been closed: here the early "return" in hv_irq_unmask() means the pci_msi_unmask_irq() is not called, i.e. the desc->masked remains "true", so later after hibernation, the MSI interrupt always remains masked, which is incorrect. Refer to cpu_disable_common() -> fixup_irqs() -> irq_migrate_all_off_this_cpu() -> migrate_one_irq(): static bool migrate_one_irq(struct irq_desc *desc) { ... if (maskchip && chip->irq_mask) chip->irq_mask(d); ... err = irq_do_set_affinity(d, affinity, false); ... if (maskchip && chip->irq_unmask) chip->irq_unmask(d); Fix the issue by calling pci_msi_unmask_irq() unconditionally in hv_irq_unmask(). Also suppress the error message for hibernation because the hypercall failure during hibernation does not matter (at this time all the devices have been frozen). Note: the correct affinity info is still updated into the irqdata data structure in migrate_one_irq() -> irq_do_set_affinity() -> hv_set_affinity(), so later when the VM resumes, hv_pci_restore_msi_state() is able to correctly restore the interrupt with the correct affinity. Link: https://lore.kernel.org/r/20201002085158.9168-1-decui@microsoft.com Fixes: ac82fc832708 ("PCI: hv: Add hibernation support") Signed-off-by: Dexuan Cui Signed-off-by: Lorenzo Pieralisi Reviewed-by: Jake Oshins Signed-off-by: Sasha Levin commit 4aef5366fcac289a112dffcc71d8daf078bfcae9 Author: Colin Ian King Date: Fri Sep 18 16:24:28 2020 +0100 remoteproc/mediatek: fix null pointer dereference on null scp pointer [ Upstream commit 434ac4d51407ce3764a6ae96a89d90b8ae2826fb ] Currently when pointer scp is null a dev_err is being called that references the pointer which is the very thing we are trying to avoid doing. Remove the extraneous error message to avoid this issue. Addresses-Coverity: ("Dereference after null check") Fixes: 63c13d61eafe ("remoteproc/mediatek: add SCP support for mt8183") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20200918152428.27258-1-colin.king@canonical.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d69974a89cbd522e0b87a75ac79db44e3197254b Author: J. Bruce Fields Date: Fri Jul 17 18:54:54 2020 -0400 nfsd: Cache R, RW, and W opens separately [ Upstream commit ae3c57b5ca47665dc3416447a5534a9796096d86 ] The nfsd open code has always kept separate read-only, read-write, and write-only opens as necessary to ensure that when a client closes or downgrades, we don't retain more access than necessary. Also, I didn't realize the cache behaved this way when I wrote 94415b06eb8a "nfsd4: a client's own opens needn't prevent delegations". There I assumed fi_fds[O_WRONLY] and fi_fds[O_RDWR] would always be distinct. The violation of that assumption is triggering a WARN_ON_ONCE() and could also cause the server to give out a delegation when it shouldn't. Fixes: 94415b06eb8a ("nfsd4: a client's own opens needn't prevent delegations") Tested-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 53ee4219c43cbbb2af12adb6cecb5b54086b69d9 Author: Hauke Mehrtens Date: Thu Aug 20 19:14:25 2020 +0200 pwm: img: Fix null pointer access in probe [ Upstream commit b39c0615d0667b3a6f2f5c4bf99ffadf3b518bb1 ] dev_get_drvdata() is called in img_pwm_runtime_resume() before the driver data is set. When pm_runtime_enabled() returns false in img_pwm_probe() it calls img_pwm_runtime_resume() which results in a null pointer access. This patch fixes the problem by setting the driver data earlier in the img_pwm_probe() function. This crash was seen when booting the Imagination Technologies Creator Ci40 (Marduk) with kernel 5.4 in OpenWrt. Fixes: e690ae526216 ("pwm: img: Add runtime PM") Signed-off-by: Hauke Mehrtens Acked-by: Lee Jones Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 113578261006d346d547b3df507794e7fa38cfbe Author: Simon South Date: Sat Sep 19 15:33:06 2020 -0400 pwm: rockchip: Keep enabled PWMs running while probing [ Upstream commit 457f74abbed060a0395f75ab5297f2d76cada516 ] Following commit cfc4c189bc70 ("pwm: Read initial hardware state at request time") the Rockchip PWM driver can no longer assume a device's pwm_state structure has been populated after a call to pwmchip_add(). Consequently, the test in rockchip_pwm_probe() intended to prevent the driver from stopping PWM devices already enabled by the bootloader no longer functions reliably and this can lead to the kernel hanging during startup, particularly on devices like the Pinebook Pro that use a PWM-controlled backlight for their display. Avoid this by querying the device directly at probe time to determine whether or not it is enabled. Fixes: cfc4c189bc70 ("pwm: Read initial hardware state at request time") Signed-off-by: Simon South Reviewed-by: Uwe Kleine-König Reviewed-by: Heiko Stuebner Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 338e9b11f78257a7291ea726544677e945f8dc1f Author: Tero Kristo Date: Mon Sep 7 11:57:38 2020 +0300 clk: keystone: sci-clk: fix parsing assigned-clock data during probe [ Upstream commit 2f05cced7307489faab873367fb20cd212e1d890 ] The DT clock probe loop incorrectly terminates after processing "clocks" only, fix this by re-starting the loop when all entries for current DT property have been parsed. Fixes: 8e48b33f9def ("clk: keystone: sci-clk: probe clocks from DT instead of firmware") Reported-by: Peter Ujfalusi Signed-off-by: Tero Kristo Link: https://lore.kernel.org/r/20200907085740.1083-2-t-kristo@ti.com Acked-by: Santosh Shilimkar Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 41935c1335d916fd7c79b51ed2b73c33c4073345 Author: Konrad Dybcio Date: Tue Sep 22 14:09:09 2020 +0200 clk: qcom: gcc-sdm660: Fix wrong parent_map [ Upstream commit d46e5a39f9be9288f1ce2170c4c7f8098f4e7f68 ] This was likely overlooked while porting the driver upstream. Reported-by: Pavel Dubrova Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20200922120909.97203-1-konradybcio@gmail.com Fixes: f2a76a2955c0 ("clk: qcom: Add Global Clock controller (GCC) driver for SDM660") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit edae92fdbf37120a7042019123c27b4be59f1b9c Author: Yan Zhao Date: Wed Sep 16 10:30:05 2020 +0800 vfio/type1: fix dirty bitmap calculation in vfio_dma_rw [ Upstream commit 2c5af98592f65517170c7bcc714566590d3f7397 ] The count of dirtied pages is not only determined by count of copied pages, but also by the start offset. e.g. if offset = PAGE_SIZE - 1, and *copied=2, the dirty pages count is 2, instead of 1 or 0. Fixes: d6a4c185660c ("vfio iommu: Implementation of ioctl for dirty pages tracking") Signed-off-by: Yan Zhao Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit cb924410c3a1629122f01d05552814891d96d337 Author: Yan Zhao Date: Wed Sep 16 10:29:27 2020 +0800 vfio: fix a missed vfio group put in vfio_pin_pages [ Upstream commit 28b130244061863cf0437b7af1625fb45ec1a71e ] When error occurs, need to put vfio group after a successful get. Fixes: 95fc87b44104 ("vfio: Selective dirty page tracking if IOMMU backed device pins pages") Signed-off-by: Yan Zhao Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit ccca9dae4f128ff733f7b196bff1155e89268620 Author: Matthew Rosato Date: Thu Sep 10 10:59:57 2020 -0400 vfio/pci: Decouple PCI_COMMAND_MEMORY bit checks from is_virtfn [ Upstream commit 515ecd5368f1510152fa4f9b9ce55b66ac56c334 ] While it is true that devices with is_virtfn=1 will have a Memory Space Enable bit that is hard-wired to 0, this is not the only case where we see this behavior -- For example some bare-metal hypervisors lack Memory Space Enable bit emulation for devices not setting is_virtfn (s390). Fix this by instead checking for the newly-added no_command_memory bit which directly denotes the need for PCI_COMMAND_MEMORY emulation in vfio. Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory") Signed-off-by: Matthew Rosato Reviewed-by: Niklas Schnelle Reviewed-by: Pierre Morel Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit d8b44e9cad83f4ab27368b7b12c5062074732883 Author: Matthew Rosato Date: Thu Sep 10 10:59:56 2020 -0400 s390/pci: Mark all VFs as not implementing PCI_COMMAND_MEMORY [ Upstream commit 08b6e22b850c28b6032da1e4d767a33116e23dfb ] For s390 we can have VFs that are passed-through without the associated PF. Firmware provides an emulation layer to allow these devices to operate independently, but is missing emulation of the Memory Space Enable bit. For these as well as linked VFs, set no_command_memory which specifies these devices do not implement PCI_COMMAND_MEMORY. Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory") Signed-off-by: Matthew Rosato Reviewed-by: Niklas Schnelle Reviewed-by: Pierre Morel Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 9a15e9921f9eb9137eb48bd96ae33497043fc82e Author: Yan Zhao Date: Wed Sep 16 10:28:33 2020 +0800 vfio: add a singleton check for vfio_group_pin_pages [ Upstream commit 7ef32e52368f62a4e041a4f0abefb4fb64e7fd4a ] Page pinning is used both to translate and pin device mappings for DMA purpose, as well as to indicate to the IOMMU backend to limit the dirty page scope to those pages that have been pinned, in the case of an IOMMU backed device. To support this, the vfio_pin_pages() interface limits itself to only singleton groups such that the IOMMU backend can consider dirty page scope only at the group level. Implement the same requirement for the vfio_group_pin_pages() interface. Fixes: 95fc87b44104 ("vfio: Selective dirty page tracking if IOMMU backed device pins pages") Signed-off-by: Yan Zhao Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit c548dcabf8eecb9e90bd72a710d78e6e63fc232b Author: Matthew Rosato Date: Thu Sep 10 10:59:55 2020 -0400 PCI/IOV: Mark VFs as not implementing PCI_COMMAND_MEMORY [ Upstream commit 12856e7acde4702b7c3238c15fcba86ff6aa507f ] For VFs, the Memory Space Enable bit in the Command Register is hard-wired to 0. Add a new bit to signify devices where the Command Register Memory Space Enable bit does not control the device's response to MMIO accesses. Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory") Signed-off-by: Matthew Rosato Acked-by: Bjorn Helgaas Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 388f72e631cdfe5a07588df7d7f07e4a5c44e145 Author: Mathieu Poirier Date: Mon Aug 31 15:37:58 2020 -0600 remoteproc: stm32: Fix pointer assignement [ Upstream commit cb2d8d5b196c2e96e29343383c8c8d8db68b934e ] Fix the assignment of the @state pointer - it is obviously wrong. Acked-by: Arnaud Pouliquen Fixes: 376ffdc04456 ("remoteproc: stm32: Properly set co-processor state when attaching") Reported-by: kernel test robot Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200831213758.206690-1-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cfddd30e0bd147d71d7c6242a3ccce6320370094 Author: Nicolas Boichat Date: Thu Sep 3 08:05:58 2020 +0800 rpmsg: Avoid double-free in mtk_rpmsg_register_device [ Upstream commit 231331b2dbd71487159a0400d9ffd967eb0d0e08 ] If rpmsg_register_device fails, it will call mtk_rpmsg_release_device which already frees mdev. Fixes: 7017996951fd ("rpmsg: add rpmsg support for mt8183 SCP.") Signed-off-by: Nicolas Boichat Reviewed-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200903080547.v3.1.I56cf27cd59f4013bd074dc622c8b8248b034a4cc@changeid Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 43f5185ac472205bea8b02d2d6fff0d0674a145c Author: Dan Carpenter Date: Tue Sep 8 10:18:41 2020 +0300 rpmsg: smd: Fix a kobj leak in in qcom_smd_parse_edge() [ Upstream commit e69ee0cf655e8e0c4a80f4319e36019b74f17639 ] We need to call of_node_put(node) on the error paths for this function. Fixes: 53e2822e56c7 ("rpmsg: Introduce Qualcomm SMD backend") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20200908071841.GA294938@mwanda Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cb611860472e9fa7e2d864468ceb973df0c02dca Author: Mark Tomlinson Date: Mon Aug 3 15:52:40 2020 +1200 PCI: iproc: Set affinity mask on MSI interrupts [ Upstream commit eb7eacaa5b9e4f665bd08d416c8f88e63d2f123c ] The core interrupt code expects the irq_set_affinity call to update the effective affinity for the interrupt. This was not being done, so update iproc_msi_irq_set_affinity() to do so. Link: https://lore.kernel.org/r/20200803035241.7737-1-mark.tomlinson@alliedtelesis.co.nz Fixes: 3bc2b2348835 ("PCI: iproc: Add iProc PCIe MSI support") Signed-off-by: Mark Tomlinson Signed-off-by: Lorenzo Pieralisi Reviewed-by: Ray Jui Signed-off-by: Sasha Levin commit b06fc343987066fb44ad3991c0e2db5fa5fdd8a8 Author: Pali Rohár Date: Mon Sep 7 13:10:35 2020 +0200 PCI: aardvark: Check for errors from pci_bridge_emul_init() call [ Upstream commit 7862a6134456c8b4f8c39e8c94aa97e5c2f7f2b7 ] Function pci_bridge_emul_init() may fail so correctly check for errors. Link: https://lore.kernel.org/r/20200907111038.5811-3-pali@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Signed-off-by: Sasha Levin commit 247bedae7cfcddf6b86c1ad9ca15696517ff4a5e Author: Pali Rohár Date: Mon Sep 7 13:10:34 2020 +0200 PCI: aardvark: Fix compilation on s390 [ Upstream commit b32c012e4b98f0126aa327be2d1f409963057643 ] Include linux/gpio/consumer.h instead of linux/gpio.h, as is said in the latter file. This was reported by kernel test bot when compiling for s390. drivers/pci/controller/pci-aardvark.c:350:2: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror,-Wimplicit-function-declaration] drivers/pci/controller/pci-aardvark.c:1074:21: error: implicit declaration of function 'devm_gpiod_get_from_of_node' [-Werror,-Wimplicit-function-declaration] drivers/pci/controller/pci-aardvark.c:1076:14: error: use of undeclared identifier 'GPIOD_OUT_LOW' Link: https://lore.kernel.org/r/202006211118.LxtENQfl%25lkp@intel.com Link: https://lore.kernel.org/r/20200907111038.5811-2-pali@kernel.org Fixes: 5169a9851daa ("PCI: aardvark: Issue PERST via GPIO") Reported-by: kernel test robot Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Signed-off-by: Sasha Levin commit 09f4182fb8b5c4975f7419c246dda21201c93706 Author: Hou Zhiqiang Date: Tue Aug 18 17:27:46 2020 +0800 PCI: designware-ep: Fix the Header Type check [ Upstream commit 16270a92355722e387e9ca19627c5a4d7bae1354 ] The current check will result in the multiple function device fails to initialize. So fix the check by masking out the multiple function bit. Link: https://lore.kernel.org/r/20200818092746.24366-1-Zhiqiang.Hou@nxp.com Fixes: 0b24134f7888 ("PCI: dwc: Add validation that PCIe core is set to correct mode") Signed-off-by: Hou Zhiqiang Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Signed-off-by: Sasha Levin commit 57411fb851fbdbb794738885f8ededa7ec127aa5 Author: Stefan Agner Date: Fri Aug 28 17:52:05 2020 +0200 clk: meson: g12a: mark fclk_div2 as critical [ Upstream commit 2c4e80e06790cb49ad2603855d30c5aac2209c47 ] On Amlogic Meson G12b platform, similar to fclk_div3, the fclk_div2 seems to be necessary for the system to operate correctly as well. Typically, the clock also gets chosen by the eMMC peripheral. This probably masked the problem so far. However, when booting from a SD card the clock seems to get disabled which leads to a system freeze. Let's mark this clock as critical, fixing boot from SD card on G12b platforms. Fixes: 085a4ea93d54 ("clk: meson: g12a: add peripheral clock controller") Signed-off-by: Stefan Agner Signed-off-by: Jerome Brunet Tested-by: Anand Moon Cc: Marek Szyprowski Link: https://lore.kernel.org/r/577e0129e8ee93972d92f13187ff4e4286182f67.1598629915.git.stefan@agner.ch Signed-off-by: Sasha Levin commit a09dc892cf65ae8da44d6d9a72749fc5c6e19757 Author: Dirk Behme Date: Thu Aug 27 11:23:30 2020 +0200 i2c: rcar: Auto select RESET_CONTROLLER [ Upstream commit 5b9bacf28a973a6b16510493416baeefa2c06289 ] The i2c-rcar driver utilizes the Generic Reset Controller kernel feature, so select the RESET_CONTROLLER option when the I2C_RCAR option is selected with a Gen3 SoC. Fixes: 2b16fd63059ab9 ("i2c: rcar: handle RXDMA HW behaviour on Gen3") Signed-off-by: Dirk Behme Signed-off-by: Andy Lowe [erosca: Add "if ARCH_RCAR_GEN3" per Wolfram's request] Signed-off-by: Eugeniu Rosca Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit d914bcc2e9ebb2a1adde1d0728c4979e36aed9e1 Author: Chris Packham Date: Tue Aug 18 13:35:43 2020 +1200 rtc: ds1307: Clear OSF flag on DS1388 when setting time [ Upstream commit f471b05f76e4b1b6ba07ebc7681920a5c5b97c5d ] Ensure the OSF flag is cleared on the DS1388 when the clock is set. Fixes: df11b323b16f ("rtc: ds1307: handle oscillator failure flags for ds1388 variant") Signed-off-by: Chris Packham Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20200818013543.4283-1-chris.packham@alliedtelesis.co.nz Signed-off-by: Sasha Levin commit bdcac9c14ae8352a046ee02827be31d0218cd64c Author: Jerome Brunet Date: Wed Jul 29 17:43:58 2020 +0200 clk: meson: axg-audio: separate axg and g12a regmap tables [ Upstream commit cdabb1ffc7c2349b8930f752df1edcafc1d37cc1 ] There are more differences than what we initially thought. Let's keeps things clear and separate the axg and g12a regmap tables of the audio clock controller. Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20200729154359.1983085-3-jbrunet@baylibre.com Signed-off-by: Sasha Levin commit 344ebdb39f85be85b5b6ecb29f3845d2d7abfeac Author: Jassi Brar Date: Fri Oct 16 12:20:56 2020 -0500 mailbox: avoid timer start from callback [ Upstream commit c7dacf5b0f32957b24ef29df1207dc2cd8307743 ] If the txdone is done by polling, it is possible for msg_submit() to start the timer while txdone_hrtimer() callback is running. If the timer needs recheduling, it could already be enqueued by the time hrtimer_forward_now() is called, leading hrtimer to loudly complain. WARNING: CPU: 3 PID: 74 at kernel/time/hrtimer.c:932 hrtimer_forward+0xc4/0x110 CPU: 3 PID: 74 Comm: kworker/u8:1 Not tainted 5.9.0-rc2-00236-gd3520067d01c-dirty #5 Hardware name: Libre Computer AML-S805X-AC (DT) Workqueue: events_freezable_power_ thermal_zone_device_check pstate: 20000085 (nzCv daIf -PAN -UAO BTYPE=--) pc : hrtimer_forward+0xc4/0x110 lr : txdone_hrtimer+0xf8/0x118 [...] This can be fixed by not starting the timer from the callback path. Which requires the timer reloading as long as any message is queued on the channel, and not just when current tx is not done yet. Fixes: 0cc67945ea59 ("mailbox: switch to hrtimer for tx_complete polling") Reported-by: Da Xue Reviewed-by: Sudeep Holla Tested-by: Sudeep Holla Acked-by: Jerome Brunet Tested-by: Jerome Brunet Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 39b7d5f0e21b348a7fc26d1c4ac0ba373036db68 Author: Jing Xiangfeng Date: Thu Oct 15 20:13:18 2020 -0700 rapidio: fix the missed put_device() for rio_mport_add_riodev [ Upstream commit 85094c05eeb47d195a74a25366a2db066f1c9d47 ] rio_mport_add_riodev() misses to call put_device() when the device already exists. Add the missed function call to fix it. Fixes: e8de370188d0 ("rapidio: add mport char device driver") Signed-off-by: Jing Xiangfeng Signed-off-by: Andrew Morton Reviewed-by: Dan Carpenter Cc: Matt Porter Cc: Alexandre Bounine Cc: Gustavo A. R. Silva Cc: John Hubbard Cc: Kees Cook Cc: Madhuparna Bhowmik Link: https://lkml.kernel.org/r/20200922072525.42330-1-jingxiangfeng@huawei.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit adb4aca5d4a00c68d8f38759b338f572cbc54280 Author: Souptick Joarder Date: Thu Oct 15 20:13:15 2020 -0700 rapidio: fix error handling path [ Upstream commit fa63f083b3492b5ed5332b8d7c90b03b5ef24a1d ] rio_dma_transfer() attempts to clamp the return value of pin_user_pages_fast() to be >= 0. However, the attempt fails because nr_pages is overridden a few lines later, and restored to the undesirable -ERRNO value. The return value is ultimately stored in nr_pages, which in turn is passed to unpin_user_pages(), which expects nr_pages >= 0, else, disaster. Fix this by fixing the nesting of the assignment to nr_pages: nr_pages should be clamped to zero if pin_user_pages_fast() returns -ERRNO, or set to the return value of pin_user_pages_fast(), otherwise. [jhubbard@nvidia.com: new changelog] Fixes: e8de370188d09 ("rapidio: add mport char device driver") Signed-off-by: Souptick Joarder Signed-off-by: Andrew Morton Reviewed-by: Ira Weiny Reviewed-by: John Hubbard Cc: Matthew Wilcox Cc: Matt Porter Cc: Alexandre Bounine Cc: Gustavo A. R. Silva Cc: Madhuparna Bhowmik Cc: Dan Carpenter Link: https://lkml.kernel.org/r/1600227737-20785-1-git-send-email-jrdr.linux@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit dbff954e97d046aa2d86a81c1c5517a7632c9e11 Author: Matthew Wilcox (Oracle) Date: Thu Oct 15 20:13:04 2020 -0700 ramfs: fix nommu mmap with gaps in the page cache [ Upstream commit 50b7d85680086126d7bd91dae81d57d4cb1ab6b7 ] ramfs needs to check that pages are both physically contiguous and contiguous in the file. If the page cache happens to have, eg, page A for index 0 of the file, no page for index 1, and page A+1 for index 2, then an mmap of the first two pages of the file will succeed when it should fail. Fixes: 642fb4d1f1dd ("[PATCH] NOMMU: Provide shared-writable mmap support on ramfs") Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Andrew Morton Cc: David Howells Link: https://lkml.kernel.org/r/20200914122239.GO6583@casper.infradead.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 12034673ada8a00715e0f48a03cba085def3ede8 Author: Tobias Jordan Date: Thu Oct 15 20:11:38 2020 -0700 lib/crc32.c: fix trivial typo in preprocessor condition [ Upstream commit 904542dc56524f921a6bab0639ff6249c01e775f ] Whether crc32_be needs a lookup table is chosen based on CRC_LE_BITS. Obviously, the _be function should be governed by the _BE_ define. This probably never pops up as it's hard to come up with a configuration where CRC_BE_BITS isn't the same as CRC_LE_BITS and as nobody is using bitwise CRC anyway. Fixes: 46c5801eaf86 ("crc32: bolt on crc32c") Signed-off-by: Tobias Jordan Signed-off-by: Andrew Morton Cc: Krzysztof Kozlowski Cc: Jonathan Corbet Cc: Mauro Carvalho Chehab Link: https://lkml.kernel.org/r/20200923182122.GA3338@agrajag.zerfleddert.de Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 155317149d60cc25365b33b3939e4c2022573a3b Author: Huang Ying Date: Thu Oct 15 20:06:07 2020 -0700 mm: fix a race during THP splitting [ Upstream commit c4f9c701f9b44299e6adbc58d1a4bb2c40383494 ] It is reported that the following bug is triggered if the HDD is used as swap device, [ 5758.157556] BUG: kernel NULL pointer dereference, address: 0000000000000007 [ 5758.165331] #PF: supervisor write access in kernel mode [ 5758.171161] #PF: error_code(0x0002) - not-present page [ 5758.176894] PGD 0 P4D 0 [ 5758.179721] Oops: 0002 [#1] SMP PTI [ 5758.183614] CPU: 10 PID: 316 Comm: kswapd1 Kdump: loaded Tainted: G S --------- --- 5.9.0-0.rc3.1.tst.el8.x86_64 #1 [ 5758.196717] Hardware name: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.02.01.0002.082220131453 08/22/2013 [ 5758.208176] RIP: 0010:split_swap_cluster+0x47/0x60 [ 5758.213522] Code: c1 e3 06 48 c1 eb 0f 48 8d 1c d8 48 89 df e8 d0 20 6a 00 80 63 07 fb 48 85 db 74 16 48 89 df c6 07 00 66 66 66 90 31 c0 5b c3 <80> 24 25 07 00 00 00 fb 31 c0 5b c3 b8 f0 ff ff ff 5b c3 66 0f 1f [ 5758.234478] RSP: 0018:ffffb147442d7af0 EFLAGS: 00010246 [ 5758.240309] RAX: 0000000000000000 RBX: 000000000014b217 RCX: ffffb14779fd9000 [ 5758.248281] RDX: 000000000014b217 RSI: ffff9c52f2ab1400 RDI: 000000000014b217 [ 5758.256246] RBP: ffffe00c51168080 R08: ffffe00c5116fe08 R09: ffff9c52fffd3000 [ 5758.264208] R10: ffffe00c511537c8 R11: ffff9c52fffd3c90 R12: 0000000000000000 [ 5758.272172] R13: ffffe00c51170000 R14: ffffe00c51170000 R15: ffffe00c51168040 [ 5758.280134] FS: 0000000000000000(0000) GS:ffff9c52f2a80000(0000) knlGS:0000000000000000 [ 5758.289163] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5758.295575] CR2: 0000000000000007 CR3: 0000000022a0e003 CR4: 00000000000606e0 [ 5758.303538] Call Trace: [ 5758.306273] split_huge_page_to_list+0x88b/0x950 [ 5758.311433] deferred_split_scan+0x1ca/0x310 [ 5758.316202] do_shrink_slab+0x12c/0x2a0 [ 5758.320491] shrink_slab+0x20f/0x2c0 [ 5758.324482] shrink_node+0x240/0x6c0 [ 5758.328469] balance_pgdat+0x2d1/0x550 [ 5758.332652] kswapd+0x201/0x3c0 [ 5758.336157] ? finish_wait+0x80/0x80 [ 5758.340147] ? balance_pgdat+0x550/0x550 [ 5758.344525] kthread+0x114/0x130 [ 5758.348126] ? kthread_park+0x80/0x80 [ 5758.352214] ret_from_fork+0x22/0x30 [ 5758.356203] Modules linked in: fuse zram rfkill sunrpc intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp mgag200 iTCO_wdt crct10dif_pclmul iTCO_vendor_support drm_kms_helper crc32_pclmul ghash_clmulni_intel syscopyarea sysfillrect sysimgblt fb_sys_fops cec rapl joydev intel_cstate ipmi_si ipmi_devintf drm intel_uncore i2c_i801 ipmi_msghandler pcspkr lpc_ich mei_me i2c_smbus mei ioatdma ip_tables xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg igb ahci libahci i2c_algo_bit crc32c_intel libata dca wmi dm_mirror dm_region_hash dm_log dm_mod [ 5758.412673] CR2: 0000000000000007 [ 0.000000] Linux version 5.9.0-0.rc3.1.tst.el8.x86_64 (mockbuild@x86-vm-15.build.eng.bos.redhat.com) (gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5), GNU ld version 2.30-79.el8) #1 SMP Wed Sep 9 16:03:34 EDT 2020 After further digging it's found that the following race condition exists in the original implementation, CPU1 CPU2 ---- ---- deferred_split_scan() split_huge_page(page) /* page isn't compound head */ split_huge_page_to_list(page, NULL) __split_huge_page(page, ) ClearPageCompound(head) /* unlock all subpages except page (not head) */ add_to_swap(head) /* not THP */ get_swap_page(head) add_to_swap_cache(head, ) SetPageSwapCache(head) if PageSwapCache(head) split_swap_cluster(/* swap entry of head */) /* Deref sis->cluster_info: NULL accessing! */ So, in split_huge_page_to_list(), PageSwapCache() is called for the already split and unlocked "head", which may be added to swap cache in another CPU. So split_swap_cluster() may be called wrongly. To fix the race, the call to split_swap_cluster() is moved to __split_huge_page() before all subpages are unlocked. So that the PageSwapCache() is stable. Fixes: 59807685a7e77 ("mm, THP, swap: support splitting THP for THP swap out") Reported-by: Rafael Aquini Signed-off-by: "Huang, Ying" Signed-off-by: Andrew Morton Tested-by: Rafael Aquini Acked-by: Kirill A. Shutemov Cc: Hugh Dickins Cc: Andrea Arcangeli Cc: Matthew Wilcox Link: https://lkml.kernel.org/r/20201009073647.1531083-1-ying.huang@intel.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3088a79edd2f95824afabc3d8714704cad2c4e1d Author: Kirill A. Shutemov Date: Thu Oct 15 20:05:36 2020 -0700 mm/huge_memory: fix split assumption of page size [ Upstream commit 8cce54756806e5777069c46011c5f54f9feac717 ] File THPs may now be of arbitrary size, and we can't rely on that size after doing the split so remember the number of pages before we start the split. Signed-off-by: Kirill A. Shutemov Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Andrew Morton Reviewed-by: SeongJae Park Cc: Huang Ying Link: https://lkml.kernel.org/r/20200908195539.25896-6-willy@infradead.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4e81f8b6092e54beab2135a9acc6be54d9eaec5d Author: Matthew Wilcox (Oracle) Date: Thu Oct 15 20:05:29 2020 -0700 mm/page_owner: change split_page_owner to take a count [ Upstream commit 8fb156c9ee2db94f7127c930c89917634a1a9f56 ] The implementation of split_page_owner() prefers a count rather than the old order of the page. When we support a variable size THP, we won't have the order at this point, but we will have the number of pages. So change the interface to what the caller and callee would prefer. Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Andrew Morton Reviewed-by: SeongJae Park Acked-by: Kirill A. Shutemov Cc: Huang Ying Link: https://lkml.kernel.org/r/20200908195539.25896-4-willy@infradead.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 67ffeb7ee6f39f2bac1e18619186c70d54ed1733 Author: Bob Pearson Date: Tue Oct 13 13:42:37 2020 -0500 RDMA/rxe: Handle skb_clone() failure in rxe_recv.c [ Upstream commit 71abf20b28ff87fee6951ec2218d5ce7969c4e87 ] If skb_clone() is unable to allocate memory for a new sk_buff this is not detected by the current code. Check for a NULL return and continue. This is similar to other errors in this loop over QPs attached to the multicast address and consistent with the unreliable UD transport. Fixes: e7ec96fc7932f ("RDMA/rxe: Fix skb lifetime in rxe_rcv_mcast_pkt()") Addresses-Coverity-ID: 1497804: Null pointer dereferences (NULL_RETURNS) Link: https://lore.kernel.org/r/20201013184236.5231-1-rpearson@hpe.com Signed-off-by: Bob Pearson Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 72ba8ec11f5f9eeb4f58c61a136cb783a3ce84e1 Author: David Howells Date: Fri Oct 16 13:21:14 2020 +0100 afs: Fix cell removal [ Upstream commit 1d0e850a49a5b56f8f3cb51e74a11e2fedb96be6 ] Fix cell removal by inserting a more final state than AFS_CELL_FAILED that indicates that the cell has been unpublished in case the manager is already requeued and will go through again. The new AFS_CELL_REMOVED state will just immediately leave the manager function. Going through a second time in the AFS_CELL_FAILED state will cause it to try to remove the cell again, potentially leading to the proc list being removed. Fixes: 989782dcdc91 ("afs: Overhaul cell database management") Reported-by: syzbot+b994ecf2b023f14832c1@syzkaller.appspotmail.com Reported-by: syzbot+0e0db88e1eb44a91ae8d@syzkaller.appspotmail.com Reported-by: syzbot+2d0585e5efcd43d113c2@syzkaller.appspotmail.com Reported-by: syzbot+1ecc2f9d3387f1d79d42@syzkaller.appspotmail.com Reported-by: syzbot+18d51774588492bf3f69@syzkaller.appspotmail.com Reported-by: syzbot+a5e4946b04d6ca8fa5f3@syzkaller.appspotmail.com Suggested-by: Hillf Danton Signed-off-by: David Howells cc: Hillf Danton Signed-off-by: Sasha Levin commit 34a3fc1ec41c92002511109abd2c939a3bb7486a Author: David Howells Date: Thu Oct 15 11:05:01 2020 +0100 afs: Fix cell purging with aliases [ Upstream commit 286377f6bdf71568a4cf07104fe44006ae0dba6d ] When the afs module is removed, one of the things that has to be done is to purge the cell database. afs_cell_purge() cancels the management timer and then starts the cell manager work item to do the purging. This does a single run through and then assumes that all cells are now purged - but this is no longer the case. With the introduction of alias detection, a later cell in the database can now be holding an active count on an earlier cell (cell->alias_of). The purge scan passes by the earlier cell first, but this can't be got rid of until it has discarded the alias. Ordinarily, afs_unuse_cell() would handle this by setting the management timer to trigger another pass - but afs_set_cell_timer() doesn't do anything if the namespace is being removed (net->live == false). rmmod then hangs in the wait on cells_outstanding in afs_cell_purge(). Fix this by making afs_set_cell_timer() directly queue the cell manager if net->live is false. This causes additional management passes. Queueing the cell manager increments cells_outstanding to make sure the wait won't complete until all cells are destroyed. Fixes: 8a070a964877 ("afs: Detect cell aliases 1 - Cells with root volumes") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit f339eda9b90e49e82043c145ac628d679d913638 Author: David Howells Date: Tue Jul 23 11:24:59 2019 +0100 afs: Fix cell refcounting by splitting the usage counter [ Upstream commit 88c853c3f5c0a07c5db61b494ee25152535cfeee ] Management of the lifetime of afs_cell struct has some problems due to the usage counter being used to determine whether objects of that type are in use in addition to whether anyone might be interested in the structure. This is made trickier by cell objects being cached for a period of time in case they're quickly reused as they hold the result of a setup process that may be slow (DNS lookups, AFS RPC ops). Problems include the cached root volume from alias resolution pinning its parent cell record, rmmod occasionally hanging and occasionally producing assertion failures. Fix this by splitting the count of active users from the struct reference count. Things then work as follows: (1) The cell cache keeps +1 on the cell's activity count and this has to be dropped before the cell can be removed. afs_manage_cell() tries to exchange the 1 to a 0 with the cells_lock write-locked, and if successful, the record is removed from the net->cells. (2) One struct ref is 'owned' by the activity count. That is put when the active count is reduced to 0 (final_destruction label). (3) A ref can be held on a cell whilst it is queued for management on a work queue without confusing the active count. afs_queue_cell() is added to wrap this. (4) The queue's ref is dropped at the end of the management. This is split out into a separate function, afs_manage_cell_work(). (5) The root volume record is put after a cell is removed (at the final_destruction label) rather then in the RCU destruction routine. (6) Volumes hold struct refs, but aren't active users. (7) Both counts are displayed in /proc/net/afs/cells. There are some management function changes: (*) afs_put_cell() now just decrements the refcount and triggers the RCU destruction if it becomes 0. It no longer sets a timer to have the manager do this. (*) afs_use_cell() and afs_unuse_cell() are added to increase and decrease the active count. afs_unuse_cell() sets the management timer. (*) afs_queue_cell() is added to queue a cell with approprate refs. There are also some other fixes: (*) Don't let /proc/net/afs/cells access a cell's vllist if it's NULL. (*) Make sure that candidate cells in lookups are properly destroyed rather than being simply kfree'd. This ensures the bits it points to are destroyed also. (*) afs_dec_cells_outstanding() is now called in cell destruction rather than at "final_destruction". This ensures that cell->net is still valid to the end of the destructor. (*) As a consequence of the previous two changes, move the increment of net->cells_outstanding that was at the point of insertion into the tree to the allocation routine to correctly balance things. Fixes: 989782dcdc91 ("afs: Overhaul cell database management") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 6f65c9d02cfa950f35556a241b32f56540e2743e Author: David Howells Date: Fri Oct 9 14:11:58 2020 +0100 afs: Fix rapid cell addition/removal by not using RCU on cells tree [ Upstream commit 92e3cc91d8f51ce64a8b7c696377180953dd316e ] There are a number of problems that are being seen by the rapidly mounting and unmounting an afs dynamic root with an explicit cell and volume specified (which should probably be rejected, but that's a separate issue): What the tests are doing is to look up/create a cell record for the name given and then tear it down again without actually using it to try to talk to a server. This is repeated endlessly, very fast, and the new cell collides with the old one if it's not quick enough to reuse it. It appears (as suggested by Hillf Danton) that the search through the RB tree under a read_seqbegin_or_lock() under RCU conditions isn't safe and that it's not blocking the write_seqlock(), despite taking two passes at it. He suggested that the code should take a ref on the cell it's attempting to look at - but this shouldn't be necessary until we've compared the cell names. It's possible that I'm missing a barrier somewhere. However, using an RCU search for this is overkill, really - we only need to access the cell name in a few places, and they're places where we're may end up sleeping anyway. Fix this by switching to an R/W semaphore instead. Additionally, draw the down_read() call inside the function (renamed to afs_find_cell()) since all the callers were taking the RCU read lock (or should've been[*]). [*] afs_probe_cell_name() should have been, but that doesn't appear to be involved in the bug reports. The symptoms of this look like: general protection fault, probably for non-canonical address 0xf27d208691691fdb: 0000 [#1] PREEMPT SMP KASAN KASAN: maybe wild-memory-access in range [0x93e924348b48fed8-0x93e924348b48fedf] ... RIP: 0010:strncasecmp lib/string.c:52 [inline] RIP: 0010:strncasecmp+0x5f/0x240 lib/string.c:43 afs_lookup_cell_rcu+0x313/0x720 fs/afs/cell.c:88 afs_lookup_cell+0x2ee/0x1440 fs/afs/cell.c:249 afs_parse_source fs/afs/super.c:290 [inline] ... Fixes: 989782dcdc91 ("afs: Overhaul cell database management") Reported-by: syzbot+459a5dce0b4cb70fd076@syzkaller.appspotmail.com Signed-off-by: David Howells cc: Hillf Danton cc: syzkaller-bugs@googlegroups.com Signed-off-by: Sasha Levin commit a0aaecaa947d9f947993ca48b640dce9b2f00431 Author: Jamie Iles Date: Mon Oct 12 14:09:48 2020 +0100 f2fs: wait for sysfs kobject removal before freeing f2fs_sb_info [ Upstream commit ae284d87abade58c8db7760c808f311ef1ce693c ] syzkaller found that with CONFIG_DEBUG_KOBJECT_RELEASE=y, unmounting an f2fs filesystem could result in the following splat: kobject: 'loop5' ((____ptrval____)): kobject_release, parent 0000000000000000 (delayed 250) kobject: 'f2fs_xattr_entry-7:5' ((____ptrval____)): kobject_release, parent 0000000000000000 (delayed 750) ------------[ cut here ]------------ ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x98 WARNING: CPU: 0 PID: 699 at lib/debugobjects.c:485 debug_print_object+0x180/0x240 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 699 Comm: syz-executor.5 Tainted: G S 5.9.0-rc8+ #101 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x4d8 show_stack+0x34/0x48 dump_stack+0x174/0x1f8 panic+0x360/0x7a0 __warn+0x244/0x2ec report_bug+0x240/0x398 bug_handler+0x50/0xc0 call_break_hook+0x160/0x1d8 brk_handler+0x30/0xc0 do_debug_exception+0x184/0x340 el1_dbg+0x48/0xb0 el1_sync_handler+0x170/0x1c8 el1_sync+0x80/0x100 debug_print_object+0x180/0x240 debug_check_no_obj_freed+0x200/0x430 slab_free_freelist_hook+0x190/0x210 kfree+0x13c/0x460 f2fs_put_super+0x624/0xa58 generic_shutdown_super+0x120/0x300 kill_block_super+0x94/0xf8 kill_f2fs_super+0x244/0x308 deactivate_locked_super+0x104/0x150 deactivate_super+0x118/0x148 cleanup_mnt+0x27c/0x3c0 __cleanup_mnt+0x28/0x38 task_work_run+0x10c/0x248 do_notify_resume+0x9d4/0x1188 work_pending+0x8/0x34c Like the error handling for f2fs_register_sysfs(), we need to wait for the kobject to be destroyed before returning to prevent a potential use-after-free. Fixes: bf9e697ecd42 ("f2fs: expose features to sysfs entry") Cc: Jaegeuk Kim Cc: Chao Yu Signed-off-by: Jamie Iles Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 4407321826374080ad06bdc69327211042c99777 Author: Oliver O'Halloran Date: Wed Oct 14 13:47:11 2020 +1100 selftests/powerpc: Fix eeh-basic.sh exit codes [ Upstream commit 996f9e0f93f16211945c8d5f18f296a88cb32f91 ] The kselftests test running infrastructure expects tests to finish with an exit code of 4 if the test decided it should be skipped. Currently eeh-basic.sh exits with the number of devices that failed to recover, so if four devices didn't recover we'll report a skip instead of a fail. Fix this by checking if the return code is non-zero and report success and failure by returning 0 or 1 respectively. For the cases where should actually skip return 4. Fixes: 85d86c8aa52e ("selftests/powerpc: Add basic EEH selftest") Signed-off-by: Oliver O'Halloran Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201014024711.1138386-1-oohall@gmail.com Signed-off-by: Sasha Levin commit b288076397147ab9add565265b44add03c1e5b36 Author: Jiri Slaby Date: Thu Oct 1 11:34:19 2020 +0200 perf trace: Fix off by ones in memset() after realloc() in arches using libaudit [ Upstream commit f3013f7ed465479e60c1ab1921a5718fc541cc3b ] 'perf trace ls' started crashing after commit d21cb73a9025 on !HAVE_SYSCALL_TABLE_SUPPORT configs (armv7l here) like this: 0 strlen () at ../sysdeps/arm/armv6t2/strlen.S:126 1 0xb6800780 in __vfprintf_internal (s=0xbeff9908, s@entry=0xbeff9900, format=0xa27160 "]: %s()", ap=..., mode_flags=) at vfprintf-internal.c:1688 ... 5 0x0056ecdc in fprintf (__fmt=0xa27160 "]: %s()", __stream=) at /usr/include/bits/stdio2.h:100 6 trace__sys_exit (trace=trace@entry=0xbeffc710, evsel=evsel@entry=0xd968d0, event=, sample=sample@entry=0xbeffc3e8) at builtin-trace.c:2475 7 0x00566d40 in trace__handle_event (sample=0xbeffc3e8, event=, trace=0xbeffc710) at builtin-trace.c:3122 ... 15 main (argc=2, argv=0xbefff6e8) at perf.c:538 It is because memset in trace__read_syscall_info zeroes wrong memory: 1) when initializing for the first time, it does not reset the last id. 2) in other cases, it resets the last id of previous buffer. ad 1) it causes the crash above as sc->name used in the fprintf above contains garbage. ad 2) it sets nonexistent from true back to false for id 11 here. Not sure, what the consequences are. So fix it by introducing a special case for the initial initialization and do the right +1 in both cases. Fixes: d21cb73a9025 ("perf trace: Grow the syscall table as needed when using libaudit") Signed-off-by: Jiri Slaby Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20201001093419.15761-1-jslaby@suse.cz Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 0dc689f0c6ae79206fc6031e6301cceedd8e3b03 Author: Krzysztof Kozlowski Date: Thu Aug 27 09:31:28 2020 +0200 maiblox: mediatek: Fix handling of platform_get_irq() error [ Upstream commit 558e4c36ec9f2722af4fe8ef84dc812bcdb5c43a ] platform_get_irq() returns -ERRNO on error. In such case casting to u32 and comparing to 0 would pass the check. Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 1c395f4824ebbcc9af3c50ecfebdbd4dabe2110c Author: Jing Xiangfeng Date: Tue Sep 29 16:26:52 2020 +0800 thermal: core: Adding missing nlmsg_free() in thermal_genl_sampling_temp() [ Upstream commit 48b458591749d35c927351b4960b49e35af30fe6 ] thermal_genl_sampling_temp() misses to call nlmsg_free() in an error path. Jump to out_free to fix it. Fixes: 1ce50e7d408ef2 ("thermal: core: genetlink support for events/cmd/sampling") Signed-off-by: Jing Xiangfeng Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20200929082652.59876-1-jingxiangfeng@huawei.com Signed-off-by: Sasha Levin commit f41bcf9cd9bce57196e1543759fad547f9baa58f Author: Johannes Berg Date: Thu Sep 10 11:31:12 2020 +0200 um: time-travel: Fix IRQ handling in time_travel_handle_message() [ Upstream commit ebef8ea2ba967026192a26f4529890893919bc57 ] As the comment here indicates, we need to do the polling in the idle loop without blocking interrupts, since interrupts can be vhost-user messages that we must process even while in our idle loop. I don't know why I explained one thing and implemented another, but we have indeed observed random hangs due to this, depending on the timing of the messages. Fixes: 88ce64249233 ("um: Implement time-travel=ext") Signed-off-by: Johannes Berg Acked-By: Anton Ivanov Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 86299c13472b092404469ce1621991a23ccbd8e6 Author: Tiezhu Yang Date: Fri Jun 19 13:20:07 2020 +0800 um: vector: Use GFP_ATOMIC under spin lock [ Upstream commit e4e721fe4ccb504a29d1e8d4047667557281d932 ] Use GFP_ATOMIC instead of GFP_KERNEL under spin lock to fix possible sleep-in-atomic-context bugs. Fixes: 9807019a62dc ("um: Loadable BPF "Firmware" for vector drivers") Signed-off-by: Tiezhu Yang Acked-By: Anton Ivanov Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 07d5f75b6e9f81e46d1f441dc8065fab6af8b90f Author: Eric Biggers Date: Thu Oct 8 12:15:22 2020 -0700 f2fs: reject CASEFOLD inode flag without casefold feature [ Upstream commit f6322f3f1212e005e7e6aa82ceb62be53030a64b ] syzbot reported: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 6860 Comm: syz-executor835 Not tainted 5.9.0-rc8-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:utf8_casefold+0x43/0x1b0 fs/unicode/utf8-core.c:107 [...] Call Trace: f2fs_init_casefolded_name fs/f2fs/dir.c:85 [inline] __f2fs_setup_filename fs/f2fs/dir.c:118 [inline] f2fs_prepare_lookup+0x3bf/0x640 fs/f2fs/dir.c:163 f2fs_lookup+0x10d/0x920 fs/f2fs/namei.c:494 __lookup_hash+0x115/0x240 fs/namei.c:1445 filename_create+0x14b/0x630 fs/namei.c:3467 user_path_create fs/namei.c:3524 [inline] do_mkdirat+0x56/0x310 fs/namei.c:3664 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 [...] The problem is that an inode has F2FS_CASEFOLD_FL set, but the filesystem doesn't have the casefold feature flag set, and therefore super_block::s_encoding is NULL. Fix this by making sanity_check_inode() reject inodes that have F2FS_CASEFOLD_FL when the filesystem doesn't have the casefold feature. Reported-by: syzbot+05139c4039d0679e19ff@syzkaller.appspotmail.com Fixes: 2c2eb7a300cd ("f2fs: Support case-insensitive file name lookups") Signed-off-by: Eric Biggers Reviewed-by: Gabriel Krisman Bertazi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit c44841e7e9cb0cba2fb443a999422cd055b97ed6 Author: Bob Pearson Date: Thu Oct 8 15:36:52 2020 -0500 RDMA/rxe: Fix skb lifetime in rxe_rcv_mcast_pkt() [ Upstream commit e7ec96fc7932f48a6d6cdd05bf82004a1a04285b ] The changes referenced below replaced sbk_clone)_ by taking additional references, passing the skb along and then freeing the skb. This deleted the packets before they could be processed and additionally passed bad data in each packet. Since pkt is stored in skb->cb changing pkt->qp changed it for all the packets. Replace skb_get() by sbk_clone() in rxe_rcv_mcast_pkt() for cases where multiple QPs are receiving multicast packets on the same address. Delete kfree_skb() because the packets need to live until they have been processed by each QP. They are freed later. Fixes: 86af61764151 ("IB/rxe: remove unnecessary skb_clone") Fixes: fe896ceb5772 ("IB/rxe: replace refcount_inc with skb_get") Link: https://lore.kernel.org/r/20201008203651.256958-1-rpearson@hpe.com Signed-off-by: Bob Pearson Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 834e45aa18e3e4b421bc8dbd0d81cd839474a7b0 Author: Colin Ian King Date: Thu Oct 8 10:52:04 2020 +0100 IB/rdmavt: Fix sizeof mismatch [ Upstream commit 8e71f694e0c819db39af2336f16eb9689f1ae53f ] An incorrect sizeof is being used, struct rvt_ibport ** is not correct, it should be struct rvt_ibport *. Note that since ** is the same size as * this is not causing any issues. Improve this fix by using sizeof(*rdi->ports) as this allows us to not even reference the type of the pointer. Also remove line breaks as the entire statement can fit on one line. Link: https://lore.kernel.org/r/20201008095204.82683-1-colin.king@canonical.com Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)") Fixes: ff6acd69518e ("IB/rdmavt: Add device structure allocation") Signed-off-by: Colin Ian King Reviewed-by: Ira Weiny Acked-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7092c055e711f9c47259bb8ea85ebef63888f3f9 Author: Srikar Dronamraju Date: Tue Sep 22 13:32:54 2020 +0530 cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_reboot_notifier [ Upstream commit a2d0230b91f7e23ceb5d8fb6a9799f30517ec33a ] The patch avoids allocating cpufreq_policy on stack hence fixing frame size overflow in 'powernv_cpufreq_reboot_notifier': drivers/cpufreq/powernv-cpufreq.c: In function powernv_cpufreq_reboot_notifier: drivers/cpufreq/powernv-cpufreq.c:906:1: error: the frame size of 2064 bytes is larger than 2048 bytes Fixes: cf30af76 ("cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec") Signed-off-by: Srikar Dronamraju Reviewed-by: Daniel Axtens Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200922080254.41497-1-srikar@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit e16bf2337db340a0a10c8d19c5ad719c2279ac6a Author: Vaibhav Jain Date: Mon Sep 14 02:49:04 2020 +0530 powerpc/papr_scm: Add PAPR command family to pass-through command-set [ Upstream commit 13135b461cf205941308984bd3271ec7d403dc40 ] Add NVDIMM_FAMILY_PAPR to the list of valid 'dimm_family_mask' acceptable by papr_scm. This is needed as since commit 92fe2aa859f5 ("libnvdimm: Validate command family indices") libnvdimm performs a validation of 'nd_cmd_pkg.nd_family' received as part of ND_CMD_CALL processing to ensure only known command families can use the general ND_CMD_CALL pass-through functionality. Without this change the ND_CMD_CALL pass-through targeting NVDIMM_FAMILY_PAPR error out with -EINVAL. Fixes: 92fe2aa859f5 ("libnvdimm: Validate command family indices") Signed-off-by: Vaibhav Jain Reviewed-by: Ira Weiny Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200913211904.24472-1-vaibhav@linux.ibm.com Signed-off-by: Sasha Levin commit 6ebba2150323bdcb9bd486fd1f575057191c32b5 Author: Aneesh Kumar K.V Date: Wed Oct 7 17:18:35 2020 +0530 powerpc/book3s64/radix: Make radix_mem_block_size 64bit [ Upstream commit 950805f4d90eda14325ceab56b0f00d034baa8bc ] Similar to commit 89c140bbaeee ("pseries: Fix 64 bit logical memory block panic") make sure different variables tracking lmb_size are updated to be 64 bit. Fixes: af9d00e93a4f ("powerpc/mm/radix: Create separate mappings for hot-plugged memory") Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201007114836.282468-4-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin commit f17dd7850728c70be94865fbacd765582a54c188 Author: Nicholas Piggin Date: Wed Oct 7 18:06:05 2020 +1000 powerpc/security: Fix link stack flush instruction [ Upstream commit 792254a77201453d9a77479e63dc216ad90462d2 ] The inline execution path for the hardware assisted branch flush instruction failed to set CTR to the correct value before bcctr, causing a crash when the feature is enabled. Fixes: 4d24e21cc694 ("powerpc/security: Allow for processors that flush the link stack using the special bcctr") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201007080605.64423-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit e62014ff338f6ea3d3abd73aac81e8f92b95ea99 Author: Jing Xiangfeng Date: Fri Sep 11 11:33:50 2020 +0800 i3c: master: Fix error return in cdns_i3c_master_probe() [ Upstream commit abea14bfdebbe9bd02f2ad24a1f3a878ed21c8f0 ] Fix to return negative error code -ENOMEM from the error handling case instead of 0. Fixes: 603f2bee2c54 ("i3c: master: Add driver for Cadence IP") Signed-off-by: Jing Xiangfeng Signed-off-by: Boris Brezillon Link: https://lore.kernel.org/linux-i3c/20200911033350.23904-1-jingxiangfeng@huawei.com Signed-off-by: Sasha Levin commit b3e8c496e12a7d72a371af0f5ab0f4ef6a8fc591 Author: Namhyung Kim Date: Wed Oct 7 17:13:11 2020 +0900 perf stat: Fix out of bounds CPU map access when handling armv8_pmu events [ Upstream commit bef69bd7cfc363ab94b84ea29102f3e913ed3c6c ] It was reported that 'perf stat' crashed when using with armv8_pmu (CPU) events with the task mode. As 'perf stat' uses an empty cpu map for task mode but armv8_pmu has its own cpu mask, it has confused which map it should use when accessing file descriptors and this causes segfaults: (gdb) bt #0 0x0000000000603fc8 in perf_evsel__close_fd_cpu (evsel=, cpu=) at evsel.c:122 #1 perf_evsel__close_cpu (evsel=evsel@entry=0x716e950, cpu=7) at evsel.c:156 #2 0x00000000004d4718 in evlist__close (evlist=0x70a7cb0) at util/evlist.c:1242 #3 0x0000000000453404 in __run_perf_stat (argc=3, argc@entry=1, argv=0x30, argv@entry=0xfffffaea2f90, run_idx=119, run_idx@entry=1701998435) at builtin-stat.c:929 #4 0x0000000000455058 in run_perf_stat (run_idx=1701998435, argv=0xfffffaea2f90, argc=1) at builtin-stat.c:947 #5 cmd_stat (argc=1, argv=0xfffffaea2f90) at builtin-stat.c:2357 #6 0x00000000004bb888 in run_builtin (p=p@entry=0x9764b8 , argc=argc@entry=4, argv=argv@entry=0xfffffaea2f90) at perf.c:312 #7 0x00000000004bbb54 in handle_internal_command (argc=argc@entry=4, argv=argv@entry=0xfffffaea2f90) at perf.c:364 #8 0x0000000000435378 in run_argv (argcp=, argv=) at perf.c:408 #9 main (argc=4, argv=0xfffffaea2f90) at perf.c:538 To fix this, I simply used the given cpu map unless the evsel actually is not a system-wide event (like uncore events). Fixes: 7736627b865d ("perf stat: Use affinity for closing file descriptors") Reported-by: Wei Li Signed-off-by: Namhyung Kim Tested-by: Barry Song Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Mark Rutland Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lore.kernel.org/lkml/20201007081311.1831003-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 0a6e3da5ca9869a7eff997a48df5ff8b1c7db61f Author: Kajol Jain Date: Sat Oct 3 13:19:39 2020 +0530 powerpc/perf/hv-gpci: Fix starting index value [ Upstream commit 0f9866f7e85765bbda86666df56c92f377c3bc10 ] Commit 9e9f60108423f ("powerpc/perf/{hv-gpci, hv-common}: generate requests with counters annotated") adds a framework for defining gpci counters. In this patch, they adds starting_index value as '0xffffffffffffffff'. which is wrong as starting_index is of size 32 bits. Because of this, incase we try to run hv-gpci event we get error. In power9 machine: command#: perf stat -e hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ -C 0 -I 1000 event syntax error: '..bie_count_and_time_tlbie_instructions_issued/' \___ value too big for format, maximum is 4294967295 This patch fix this issue and changes starting_index value to '0xffffffff' After this patch: command#: perf stat -e hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ -C 0 -I 1000 1.000085786 1,024 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 2.000287818 1,024 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 2.439113909 17,408 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ Fixes: 9e9f60108423 ("powerpc/perf/{hv-gpci, hv-common}: generate requests with counters annotated") Signed-off-by: Kajol Jain Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201003074943.338618-1-kjain@linux.ibm.com Signed-off-by: Sasha Levin commit 0c8237873116d6fba411be660a5578a4e8fe0715 Author: Athira Rajeev Date: Mon Sep 21 03:10:04 2020 -0400 powerpc/perf: Exclude pmc5/6 from the irrelevant PMU group constraints [ Upstream commit 3b6c3adbb2fa42749c3d38cfc4d4d0b7e096bb7b ] PMU counter support functions enforces event constraints for group of events to check if all events in a group can be monitored. Incase of event codes using PMC5 and PMC6 ( 500fa and 600f4 respectively ), not all constraints are applicable, say the threshold or sample bits. But current code includes pmc5 and pmc6 in some group constraints (like IC_DC Qualifier bits) which is actually not applicable and hence results in those events not getting counted when scheduled along with group of other events. Patch fixes this by excluding PMC5/6 from constraints which are not relevant for it. Fixes: 7ffd948 ("powerpc/perf: factor out power8 pmu functions") Signed-off-by: Athira Rajeev Reviewed-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1600672204-1610-1-git-send-email-atrajeev@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 65ac955b4b54cd0a9575e6620da074a2900876ee Author: Daniel Axtens Date: Thu Sep 24 11:49:22 2020 +1000 powerpc: PPC_SECURE_BOOT should not require PowerNV [ Upstream commit 5c5e46dad939b2bf4df04293ab9ac68abd7c1f55 ] In commit 61f879d97ce4 ("powerpc/pseries: Detect secure and trusted boot state of the system.") we taught the kernel how to understand the secure-boot parameters used by a pseries guest. However, CONFIG_PPC_SECURE_BOOT still requires PowerNV. I didn't catch this because pseries_le_defconfig includes support for PowerNV and so everything still worked. Indeed, most configs will. Nonetheless, technically PPC_SECURE_BOOT doesn't require PowerNV any more. The secure variables support (PPC_SECVAR_SYSFS) doesn't do anything on pSeries yet, but I don't think it's worth adding a new condition - at some stage we'll want to add a backend for pSeries anyway. Fixes: 61f879d97ce4 ("powerpc/pseries: Detect secure and trusted boot state of the system.") Signed-off-by: Daniel Axtens Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200924014922.172914-1-dja@axtens.net Signed-off-by: Sasha Levin commit 14f7c6758d5e3322775ea1676f599361d0d9ff13 Author: Nicholas Piggin Date: Tue Sep 15 21:46:46 2020 +1000 powerpc/64: fix irq replay pt_regs->softe value [ Upstream commit 2b48e96be2f9f7151197fd25dc41487054bc6f5b ] Replayed interrupts get an "artificial" struct pt_regs constructed to pass to interrupt handler functions. This did not get the softe field set correctly, it's as though the interrupt has hit while irqs are disabled. It should be IRQS_ENABLED. This is possibly harmless, asynchronous handlers should not be testing if irqs were disabled, but it might be possible for example some code is shared with synchronous or NMI handlers, and it makes more sense if debug output looks at this. Fixes: 3282a3da25bd ("powerpc/64: Implement soft interrupt replay in C") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200915114650.3980244-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit 7392e4da5ad95f8e90fea303c8966271acee3470 Author: Nicholas Piggin Date: Tue Sep 15 21:46:45 2020 +1000 powerpc/64: fix irq replay missing preempt [ Upstream commit 903fd31d3212ab72d564c68f6cfb5d04db68773e ] Prior to commit 3282a3da25bd ("powerpc/64: Implement soft interrupt replay in C"), replayed interrupts returned by the regular interrupt exit code, which performs preemption in case an interrupt had set need_resched. This logic was missed by the conversion. Adding preempt_disable/enable around the interrupt replay and final irq enable will reschedule if needed. Fixes: 3282a3da25bd ("powerpc/64: Implement soft interrupt replay in C") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200915114650.3980244-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit 86e76dbea6379bb272bceb36fe4217f34ff6858d Author: Kamal Heib Date: Sun Oct 4 16:29:48 2020 +0300 RDMA/ipoib: Set rtnl_link_ops for ipoib interfaces [ Upstream commit 5ce2dced8e95e76ff7439863a118a053a7fc6f91 ] Report the "ipoib pkey", "mode" and "umcast" netlink attributes for every IPoiB interface type, not just children created with 'ip link add'. After setting the rtnl_link_ops for the parent interface, implement the dellink() callback to block users from trying to remove it. Fixes: 862096a8bbf8 ("IB/ipoib: Add more rtnl_link_ops callbacks") Link: https://lore.kernel.org/r/20201004132948.26669-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 77445d8cc644b86a427083691f4bdebf357fc197 Author: Florian Fainelli Date: Tue Sep 29 10:27:21 2020 -0700 mtd: parsers: bcm63xx: Do not make it modular [ Upstream commit b597cc75f7fe76708bc6ab3f0e09bbff6f09ae4a ] With commit 91e81150d388 ("mtd: parsers: bcm63xx: simplify CFE detection"), we generate a reference to fw_arg3 which is the fourth firmware/command line argument on MIPS platforms. That symbol is not exported and would cause a linking failure. The parser is typically necessary to boot a BCM63xx-based system anyway so having it be part of the kernel image makes sense, therefore make it 'bool' instead of 'tristate'. Fixes: 91e81150d388 ("mtd: parsers: bcm63xx: simplify CFE detection") Signed-off-by: Florian Fainelli Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200929172726.30469-1-f.fainelli@gmail.com Signed-off-by: Sasha Levin commit bfd486d7e7b73f221ede9632abf8ff897752b350 Author: Leon Romanovsky Date: Sun Sep 13 13:29:28 2020 +0300 overflow: Include header file with SIZE_MAX declaration [ Upstream commit a4947e84f23474803b62a2759b5808147e4e15f9 ] The various array_size functions use SIZE_MAX define, but missed limits.h causes to failure to compile code that needs overflow.h. In file included from drivers/infiniband/core/uverbs_std_types_device.c:6: ./include/linux/overflow.h: In function 'array_size': ./include/linux/overflow.h:258:10: error: 'SIZE_MAX' undeclared (first use in this function) 258 | return SIZE_MAX; | ^~~~~~~~ Fixes: 610b15c50e86 ("overflow.h: Add allocation size calculation helpers") Link: https://lore.kernel.org/r/20200913102928.134985-1-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 863e143b6dca9662c6f579a071646c750a1449cf Author: Daniel Thompson Date: Wed Sep 9 15:17:08 2020 +0100 kdb: Fix pager search for multi-line strings [ Upstream commit d081a6e353168f15e63eb9e9334757f20343319f ] Currently using forward search doesn't handle multi-line strings correctly. The search routine replaces line breaks with \0 during the search and, for regular searches ("help | grep Common\n"), there is code after the line has been discarded or printed to replace the break character. However during a pager search ("help\n" followed by "/Common\n") when the string is matched we will immediately return to normal output and the code that should restore the \n becomes unreachable. Fix this by restoring the replaced character when we disable the search mode and update the comment accordingly. Fixes: fb6daa7520f9d ("kdb: Provide forward search at more prompt") Link: https://lore.kernel.org/r/20200909141708.338273-1-daniel.thompson@linaro.org Reviewed-by: Douglas Anderson Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin commit 3f34d6f181118f38c9c7dc3bb105819774b8d214 Author: Janusz Krzysztofik Date: Sat Sep 19 10:04:03 2020 +0200 mtd: rawnand: ams-delta: Fix non-OF build warning [ Upstream commit 6d11178762f7c8338a028b428198383b8978b280 ] Commit 7c2f66a960fc ("mtd: rawnand: ams-delta: Add module device tables") introduced an OF module device table but wrapped a reference to it with of_match_ptr() which resolves to NULL in non-OF configs. That resulted in a clang compiler warning on unused variable in non-OF builds. Fix it. drivers/mtd/nand/raw/ams-delta.c:373:34: warning: unused variable 'gpio_nand_of_id_table' [-Wunused-const-variable] static const struct of_device_id gpio_nand_of_id_table[] = { ^ 1 warning generated. Fixes: 7c2f66a960fc ("mtd: rawnand: ams-delta: Add module device tables") Reported-by: kernel test robot Signed-off-by: Janusz Krzysztofik Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200919080403.17520-1-jmkrzyszt@gmail.com Signed-off-by: Sasha Levin commit 4e8d0f237e9beafa6b86cd9a6ebbee783110f510 Author: Hauke Mehrtens Date: Thu Aug 20 18:51:20 2020 +0200 mtd: spinand: gigadevice: Add QE Bit [ Upstream commit aea7687e77bebce5b67fab9d03347bd8df7933c7 ] The following GigaDevice chips have the QE BIT in the feature flags, I checked the datasheets, but did not try this. * GD5F1GQ4xExxG * GD5F1GQ4xFxxG * GD5F1GQ4UAYIG * GD5F4GQ4UAYIG The Quad operations like 0xEB mention that the QE bit has to be set. Fixes: c93c613214ac ("mtd: spinand: add support for GigaDevice GD5FxGQ4xA") Signed-off-by: Hauke Mehrtens Tested-by: Chuanhong Guo Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200820165121.3192-3-hauke@hauke-m.de Signed-off-by: Sasha Levin commit b4fb5cb43458294f73e978f02342a9344d56a939 Author: Hauke Mehrtens Date: Thu Aug 20 18:51:19 2020 +0200 mtd: spinand: gigadevice: Only one dummy byte in QUADIO [ Upstream commit 6387ad9caf8f09747a8569e5876086b72ee9382c ] The datasheet only lists one dummy byte in the 0xEH operation for the following chips: * GD5F1GQ4xExxG * GD5F1GQ4xFxxG * GD5F1GQ4UAYIG * GD5F4GQ4UAYIG Fixes: c93c613214ac ("mtd: spinand: add support for GigaDevice GD5FxGQ4xA") Signed-off-by: Hauke Mehrtens Tested-by: Chuanhong Guo Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200820165121.3192-2-hauke@hauke-m.de Signed-off-by: Sasha Levin commit 04ca4c9528be502643dcc4dfa5ad8ae06809d24f Author: Evgeny Novikov Date: Thu Aug 6 10:26:34 2020 +0300 mtd: rawnand: vf610: disable clk on error handling path in probe [ Upstream commit cb7dc3178a9862614b1e7567d77f4679f027a074 ] vf610_nfc_probe() does not invoke clk_disable_unprepare() on one error handling path. The patch fixes that. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 6f0ce4dfc5a3 ("mtd: rawnand: vf610: Avoid a potential NULL pointer dereference") Signed-off-by: Evgeny Novikov Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200806072634.23528-1-novikov@ispras.ru Signed-off-by: Sasha Levin commit 4d14fc249c95cb38d1626f5d1154bb25a1e2690d Author: Christophe Kerello Date: Tue Jul 21 11:52:07 2020 +0200 mtd: rawnand: stm32_fmc2: fix a buffer overflow [ Upstream commit ab16f54ef3cdb6bbc06a36f636a89e6db8a6cea3 ] This patch solves following static checker warning: drivers/mtd/nand/raw/stm32_fmc2_nand.c:350 stm32_fmc2_nfc_select_chip() error: buffer overflow 'nfc->data_phys_addr' 2 <= 2 The CS value can only be 0 or 1. Signed-off-by: Christophe Kerello Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/1595325127-32693-1-git-send-email-christophe.kerello@st.com Signed-off-by: Sasha Levin commit 50415e6634613c6fb3f437dd3fd85e6401f9e8ac Author: Vignesh Raghavendra Date: Thu Sep 24 13:42:12 2020 +0530 mtd: hyperbus: hbmc-am654: Fix direct mapping setup flash access [ Upstream commit aca31ce96814c84d1a41aaa109c15abe61005af7 ] Setting up of direct mapping should be done with flash node's IO address space and not with controller's IO region. Fixes: b6fe8bc67d2d3 ("mtd: hyperbus: move direct mapping setup to AM654 HBMC driver") Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20200924081214.16934-3-vigneshr@ti.com Signed-off-by: Sasha Levin commit 2a989f2aeffd7a289ce42f747449cfa5dc2072e0 Author: Liu Shixin Date: Thu Sep 17 16:13:54 2020 +0800 RDMA/mlx5: Fix type warning of sizeof in __mlx5_ib_alloc_counters() [ Upstream commit b942fc0319a72b83146b79619eb578e989062911 ] sizeof() when applied to a pointer typed expression should give the size of the pointed data, even if the data is a pointer. Fixes: e1f24a79f424 ("IB/mlx5: Support congestion related counters") Link: https://lore.kernel.org/r/20200917081354.2083293-1-liushixin2@huawei.com Signed-off-by: Liu Shixin Acked-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b9616f405cee5d2ab1992d38a07d17c916164e47 Author: Weihang Li Date: Sat Sep 19 18:03:22 2020 +0800 RDMA/hns: Fix missing sq_sig_type when querying QP [ Upstream commit 05df49279f8926178ecb3ce88e61b63104cd6293 ] The sq_sig_type field should be filled when querying QP, or the users may get a wrong value. Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC") Link: https://lore.kernel.org/r/1600509802-44382-9-git-send-email-liweihang@huawei.com Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0aabf99b102733313bfa205899202e588903c364 Author: Weihang Li Date: Sat Sep 19 18:03:21 2020 +0800 RDMA/hns: Fix configuration of ack_req_freq in QPC [ Upstream commit fbed9d2be292504e04caa2057e3a9477a1e1d040 ] The hardware will add AckReq flag in BTH header according to the value of ack_req_freq to request ACK from responder for the packets with this flag. It should be greater than or equal to lp_pktn_ini instead of using a fixed value. Fixes: 7b9bd73ed13d ("RDMA/hns: Fix wrong assignment of lp_pktn_ini in QPC") Link: https://lore.kernel.org/r/1600509802-44382-8-git-send-email-liweihang@huawei.com Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 09ed024d7ac979025ecbd9b841f414ca59c61035 Author: Wenpeng Liang Date: Sat Sep 19 18:03:20 2020 +0800 RDMA/hns: Fix the wrong value of rnr_retry when querying qp [ Upstream commit 99fcf82521d91468ee6115a3c253aa032dc63cbc ] The rnr_retry returned to the user is not correct, it should be got from another fields in QPC. Fixes: bfe860351e31 ("RDMA/hns: Fix cast from or to restricted __le32 for driver") Link: https://lore.kernel.org/r/1600509802-44382-7-git-send-email-liweihang@huawei.com Signed-off-by: Wenpeng Liang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e66713728175b7a9c738c069129f25f80e48ce87 Author: Jiaran Zhang Date: Sat Sep 19 18:03:19 2020 +0800 RDMA/hns: Solve the overflow of the calc_pg_sz() [ Upstream commit 768202a0825d447de785e87ff1ea1d3c86a71727 ] calc_pg_sz() may gets a data calculation overflow if the PAGE_SIZE is 64 KB and hop_num is 2. It is because that all variables involved in calculation are defined in type of int. So change the type of bt_chunk_size, buf_chunk_size and obj_per_chunk_default to u64. Fixes: ba6bb7e97421 ("RDMA/hns: Add interfaces to get pf capabilities from firmware") Link: https://lore.kernel.org/r/1600509802-44382-6-git-send-email-liweihang@huawei.com Signed-off-by: Jiaran Zhang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f5d59215e4be2c7f5e6997a40708f00f7e77356a Author: Jiaran Zhang Date: Sat Sep 19 18:03:18 2020 +0800 RDMA/hns: Add check for the validity of sl configuration [ Upstream commit 172505cfa3a8ee98acaa569fd3be97697b333958 ] According to the RoCE v1 specification, the sl (service level) 0-7 are mapped directly to priorities 0-7 respectively, sl 8-15 are reserved. The driver should verify whether the the value of sl is larger than 7, if so, an exception should be returned. Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC") Link: https://lore.kernel.org/r/1600509802-44382-5-git-send-email-liweihang@huawei.com Signed-off-by: Jiaran Zhang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b347c17aa1938accaa7f6a05f58fa73b5a83007e Author: Jin Yao Date: Tue Sep 22 09:50:04 2020 +0800 perf stat: Skip duration_time in setup_system_wide [ Upstream commit 002a3d690f95804bdef6b70b26154103518e13d9 ] Some metrics (such as DRAM_BW_Use) consists of uncore events and duration_time. For uncore events, counter->core.system_wide is true. But for duration_time, counter->core.system_wide is false so target.system_wide is set to false. Then 'enable_on_exec' is set in perf_event_attr of uncore event. Kernel will return error when trying to open the uncore event. This patch skips the duration_time in setup_system_wide then target.system_wide will be set to true for the evlist of uncore events + duration_time. Before (tested on skylake desktop): # perf stat -M DRAM_BW_Use -- sleep 1 Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (arb/event=0x84,umask=0x1/). /bin/dmesg | grep -i perf may provide additional information. After: # perf stat -M DRAM_BW_Use -- sleep 1 Performance counter stats for 'system wide': 169 arb/event=0x84,umask=0x1/ # 0.00 DRAM_BW_Use 40,427 arb/event=0x81,umask=0x1/ 1,000,902,197 ns duration_time 1.000902197 seconds time elapsed Fixes: e3ba76deef23064f ("perf tools: Force uncore events to system wide monitoring") Signed-off-by: Jin Yao Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jin Yao Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200922015004.30114-1-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 136e895bb03d5ddf19cfac6f8159ccc877604bdd Author: Sindhu, Devale Date: Wed Sep 16 08:18:12 2020 -0500 i40iw: Add support to make destroy QP synchronous [ Upstream commit f2334964e969762e266a616acf9377f6046470a2 ] Occasionally ib_write_bw crash is seen due to access of a pd object in i40iw_sc_qp_destroy after it is freed. Destroy qp is not synchronous in i40iw and thus the iwqp object could be referencing a pd object that is freed by ib core as a result of successful return from i40iw_destroy_qp. Wait in i40iw_destroy_qp till all QP references are released and destroy the QP and its associated resources before returning. Switch to use the refcount API vs atomic API for lifetime management of the qp. RIP: 0010:i40iw_sc_qp_destroy+0x4b/0x120 [i40iw] [...] RSP: 0018:ffffb4a7042e3ba8 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 0000000000000001 RCX: dead000000000122 RDX: ffffb4a7042e3bac RSI: ffff8b7ef9b1e940 RDI: ffff8b7efbf09080 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 8080808080808080 R11: 0000000000000010 R12: ffff8b7efbf08050 R13: 0000000000000001 R14: ffff8b7f15042928 R15: ffff8b7ef9b1e940 FS: 0000000000000000(0000) GS:ffff8b7f2fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000400 CR3: 000000020d60a006 CR4: 00000000001606e0 Call Trace: i40iw_exec_cqp_cmd+0x4d3/0x5c0 [i40iw] ? try_to_wake_up+0x1ea/0x5d0 ? __switch_to_asm+0x40/0x70 i40iw_process_cqp_cmd+0x95/0xa0 [i40iw] i40iw_handle_cqp_op+0x42/0x1a0 [i40iw] ? cm_event_handler+0x13c/0x1f0 [iw_cm] i40iw_rem_ref+0xa0/0xf0 [i40iw] cm_work_handler+0x99c/0xd10 [iw_cm] process_one_work+0x1a1/0x360 worker_thread+0x30/0x380 ? process_one_work+0x360/0x360 kthread+0x10c/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x35/0x40 Fixes: d37498417947 ("i40iw: add files for iwarp interface") Link: https://lore.kernel.org/r/20200916131811.2077-1-shiraz.saleem@intel.com Reported-by: Kamal Heib Signed-off-by: Sindhu, Devale Signed-off-by: Shiraz, Saleem Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1b881ba7897ccf82f8112c54ea5149ae679074db Author: Jason Gunthorpe Date: Mon Sep 14 14:26:52 2020 +0300 RDMA/mlx5: Disable IB_DEVICE_MEM_MGT_EXTENSIONS if IB_WR_REG_MR can't work [ Upstream commit 0ec52f0194638e2d284ad55eba5a7aff753de1b9 ] set_reg_wr() always fails if !umr_modify_entity_size_disabled because mlx5_ib_can_use_umr() always fails. Without set_reg_wr() IB_WR_REG_MR doesn't work and that means the device should not advertise IB_DEVICE_MEM_MGT_EXTENSIONS. Fixes: 841b07f99a47 ("IB/mlx5: Block MR WR if UMR is not possible") Link: https://lore.kernel.org/r/20200914112653.345244-5-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0057c078b30f1d62a266a7d4b7bf0f28440a8b18 Author: Jason Gunthorpe Date: Mon Sep 14 14:26:51 2020 +0300 RDMA/mlx5: Make mkeys always owned by the kernel's PD when not enabled [ Upstream commit 5eb29f0d13a66502b91954597270003c90fb66c5 ] Any mkey that is not enabled and assigned to userspace should have the PD set to a kernel owned PD. When cache entries are created for the first time the PDN is set to 0, which is probably a kernel PD, but be explicit. When a MR is registered using the hybrid reg_create with UMR xlt & enable the disabled mkey is pointing at the user PD, keep it pointing at the kernel until a UMR enables it and sets the user PD. Fixes: 9ec4483a3f0f ("IB/mlx5: Move MRs to a kernel PD when freeing them to the MR cache") Link: https://lore.kernel.org/r/20200914112653.345244-4-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 05884a9826725a194b2f69cbcf2d64d2d25a951e Author: Jason Gunthorpe Date: Mon Sep 14 14:26:50 2020 +0300 RDMA/mlx5: Use set_mkc_access_pd_addr_fields() in reg_create() [ Upstream commit 1c97ca3da0d12e0156a177f48ed3184c3f202002 ] reg_create() open codes this helper, use the shared code. Link: https://lore.kernel.org/r/20200914112653.345244-3-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c752aab59c3e3fcdea30ba588f5766e3cfeb0dc6 Author: Lijun Ou Date: Thu Sep 17 21:50:15 2020 +0800 RDMA/hns: Set the unsupported wr opcode [ Upstream commit 22d3e1ed2cc837af87f76c3c8a4ccf4455e225c5 ] hip06 does not support IB_WR_LOCAL_INV, so the ps_opcode should be set to an invalid value instead of being left uninitialized. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Fixes: a2f3d4479fe9 ("RDMA/hns: Avoid unncessary initialization") Link: https://lore.kernel.org/r/1600350615-115217-1-git-send-email-oulijun@huawei.com Signed-off-by: Lijun Ou Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3fd5937477dcbdbdfc2ee5300241e729457bbfeb Author: Keita Suzuki Date: Fri Sep 11 12:51:59 2020 +0000 RDMA/qedr: Fix resource leak in qedr_create_qp [ Upstream commit 3e45410fe3c202ffb619f301beff0644f717e132 ] When xa_insert() fails, the acquired resource in qedr_create_qp should also be freed. However, current implementation does not handle the error. Fix this by adding a new goto label that calls qedr_free_qp_resources. Fixes: 1212767e23bb ("qedr: Add wrapping generic structure for qpidr and adjust idr routines.") Link: https://lore.kernel.org/r/20200911125159.4577-1-keitasuzuki.park@sslab.ics.keio.ac.jp Signed-off-by: Keita Suzuki Acked-by: Michal Kalderon  Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ce32e175101bbf61f25743f70c8346fbbf2277c7 Author: Ian Rogers Date: Thu Sep 17 13:18:07 2020 -0700 perf metricgroup: Fix uncore metric expressions [ Upstream commit dcc81be0fc4e66943041e6e19a5faf8f8704a27e ] A metric like DRAM_BW_Use has on SkylakeX events uncore_imc/cas_count_read/ and uncore_imc/case_count_write/. These events open 6 events per socket with pmu names of uncore_imc_[0-5]. The current metric setup code in find_evsel_group assumes one ID will map to 1 event to be recorded in metric_events. For events with multiple matches, the first event is recorded in metric_events (avoiding matching >1 event with the same name) and the evlist_used updated so that duplicate events aren't removed when the evlist has unused events removed. Before this change: $ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1 Performance counter stats for 'system wide': 41.14 MiB uncore_imc/cas_count_read/ 1,002,614,251 ns duration_time 1.002614251 seconds time elapsed After this change: $ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1 Performance counter stats for 'system wide': 157.47 MiB uncore_imc/cas_count_read/ # 0.00 DRAM_BW_Use 126.97 MiB uncore_imc/cas_count_write/ 1,003,019,728 ns duration_time Erroneous duplication introduced in: commit 2440689d62e9 ("perf metricgroup: Remove duped metric group events"). Fixes: ded80bda8bc9 ("perf expr: Migrate expr ids table to a hashmap"). Reported-by: Jin Yao Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Andi Kleen Cc: Andrii Nakryiko Cc: Athira Jajeev Cc: Daniel Borkmann Cc: Jiri Olsa Cc: John Fastabend Cc: KP Singh Cc: Mark Rutland Cc: Martin KaFai Lau Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Stephane Eranian Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20200917201807.4090224-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7eb5691f7a5d3d434e4ee8eb47c2340bbaf560ca Author: Adrian Hunter Date: Wed Sep 9 11:49:23 2020 +0300 perf intel-pt: Fix "context_switch event has no tid" error [ Upstream commit 7d537a8d2e76bc4fc71e34545ceaa463ac2cd928 ] A context_switch event can have no tid because pids can be detached from a task while the task is still running (in do_exit()). Note this won't happen with per-task contexts because then tracing stops at perf_event_exit_task() If a task with no tid gets preempted, or a dying task gets preempted and its parent releases it, when it subsequently gets switched back in, Intel PT will not be able to determine what task is running and prints an error "context_switch event has no tid". However, it is not really an error because the task is in kernel space and the decoder can continue to decode successfully. Fix by changing the error to be only a logged message, and make allowance for tid == -1. Example: Using 5.9-rc4 with Preemptible Kernel (Low-Latency Desktop) e.g. $ uname -r 5.9.0-rc4 $ grep PREEMPT .config # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y CONFIG_PREEMPTION=y CONFIG_PREEMPT_RCU=y CONFIG_PREEMPT_NOTIFIERS=y CONFIG_DRM_I915_PREEMPT_TIMEOUT=640 CONFIG_DEBUG_PREEMPT=y # CONFIG_PREEMPT_TRACER is not set # CONFIG_PREEMPTIRQ_DELAY_TEST is not set Before: $ cat forkit.c #include #include #include int main() { pid_t child; int status = 0; child = fork(); if (child == 0) return 123; wait(&status); return 0; } $ gcc -o forkit forkit.c $ sudo ~/bin/perf record --kcore -a -m,64M -e intel_pt/cyc/k & [1] 11016 $ taskset 2 ./forkit $ sudo pkill perf $ [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 17.262 MB perf.data ] [1]+ Terminated sudo ~/bin/perf record --kcore -a -m,64M -e intel_pt/cyc/k $ sudo ~/bin/perf script --show-task-events --show-switch-events --itrace=iqqe-o -C 1 --ns | grep -C 2 forkit context_switch event has no tid taskset 11019 [001] 66663.270045029: 1 instructions:k: ffffffffb1d9f844 strnlen_user+0xb4 ([kernel.kallsyms]) taskset 11019 [001] 66663.270201816: 1 instructions:k: ffffffffb1a83121 unmap_page_range+0x561 ([kernel.kallsyms]) forkit 11019 [001] 66663.270327553: PERF_RECORD_COMM exec: forkit:11019/11019 forkit 11019 [001] 66663.270420028: 1 instructions:k: ffffffffb1db9537 __clear_user+0x27 ([kernel.kallsyms]) forkit 11019 [001] 66663.270648704: 1 instructions:k: ffffffffb18829e6 do_user_addr_fault+0xf6 ([kernel.kallsyms]) forkit 11019 [001] 66663.270833163: 1 instructions:k: ffffffffb230a825 irqentry_exit_to_user_mode+0x15 ([kernel.kallsyms]) forkit 11019 [001] 66663.271092359: 1 instructions:k: ffffffffb1aea3d9 lock_page_memcg+0x9 ([kernel.kallsyms]) forkit 11019 [001] 66663.271207092: PERF_RECORD_FORK(11020:11020):(11019:11019) forkit 11019 [001] 66663.271234775: PERF_RECORD_SWITCH_CPU_WIDE OUT next pid/tid: 11020/11020 forkit 11020 [001] 66663.271238407: PERF_RECORD_SWITCH_CPU_WIDE IN prev pid/tid: 11019/11019 forkit 11020 [001] 66663.271312066: 1 instructions:k: ffffffffb1a88140 handle_mm_fault+0x10 ([kernel.kallsyms]) forkit 11020 [001] 66663.271476225: PERF_RECORD_EXIT(11020:11020):(11019:11019) forkit 11020 [001] 66663.271497488: PERF_RECORD_SWITCH_CPU_WIDE OUT preempt next pid/tid: 11019/11019 forkit 11019 [001] 66663.271500523: PERF_RECORD_SWITCH_CPU_WIDE IN prev pid/tid: 11020/11020 forkit 11019 [001] 66663.271517241: 1 instructions:k: ffffffffb24012cd error_entry+0x6d ([kernel.kallsyms]) forkit 11019 [001] 66663.271664080: PERF_RECORD_EXIT(11019:11019):(1386:1386) After: $ sudo ~/bin/perf script --show-task-events --show-switch-events --itrace=iqqe-o -C 1 --ns | grep -C 2 forkit taskset 11019 [001] 66663.270045029: 1 instructions:k: ffffffffb1d9f844 strnlen_user+0xb4 ([kernel.kallsyms]) taskset 11019 [001] 66663.270201816: 1 instructions:k: ffffffffb1a83121 unmap_page_range+0x561 ([kernel.kallsyms]) forkit 11019 [001] 66663.270327553: PERF_RECORD_COMM exec: forkit:11019/11019 forkit 11019 [001] 66663.270420028: 1 instructions:k: ffffffffb1db9537 __clear_user+0x27 ([kernel.kallsyms]) forkit 11019 [001] 66663.270648704: 1 instructions:k: ffffffffb18829e6 do_user_addr_fault+0xf6 ([kernel.kallsyms]) forkit 11019 [001] 66663.270833163: 1 instructions:k: ffffffffb230a825 irqentry_exit_to_user_mode+0x15 ([kernel.kallsyms]) forkit 11019 [001] 66663.271092359: 1 instructions:k: ffffffffb1aea3d9 lock_page_memcg+0x9 ([kernel.kallsyms]) forkit 11019 [001] 66663.271207092: PERF_RECORD_FORK(11020:11020):(11019:11019) forkit 11019 [001] 66663.271234775: PERF_RECORD_SWITCH_CPU_WIDE OUT next pid/tid: 11020/11020 forkit 11020 [001] 66663.271238407: PERF_RECORD_SWITCH_CPU_WIDE IN prev pid/tid: 11019/11019 forkit 11020 [001] 66663.271312066: 1 instructions:k: ffffffffb1a88140 handle_mm_fault+0x10 ([kernel.kallsyms]) forkit 11020 [001] 66663.271476225: PERF_RECORD_EXIT(11020:11020):(11019:11019) forkit 11020 [001] 66663.271497488: PERF_RECORD_SWITCH_CPU_WIDE OUT preempt next pid/tid: 11019/11019 forkit 11019 [001] 66663.271500523: PERF_RECORD_SWITCH_CPU_WIDE IN prev pid/tid: 11020/11020 forkit 11019 [001] 66663.271517241: 1 instructions:k: ffffffffb24012cd error_entry+0x6d ([kernel.kallsyms]) forkit 11019 [001] 66663.271664080: PERF_RECORD_EXIT(11019:11019):(1386:1386) forkit 11019 [001] 66663.271688752: PERF_RECORD_SWITCH_CPU_WIDE OUT next pid/tid: -1/-1 :-1 -1 [001] 66663.271692086: PERF_RECORD_SWITCH_CPU_WIDE IN prev pid/tid: 11019/11019 :-1 -1 [001] 66663.271707466: 1 instructions:k: ffffffffb18eb096 update_load_avg+0x306 ([kernel.kallsyms]) Fixes: 86c2786994bd7c ("perf intel-pt: Add support for PERF_RECORD_SWITCH") Signed-off-by: Adrian Hunter Cc: Andi Kleen Cc: Jiri Olsa Cc: Yu-cheng Yu Link: http://lore.kernel.org/lkml/20200909084923.9096-3-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit feed39c8d1282279fcb30612aa0e8d2635c11280 Author: Jason Gunthorpe Date: Wed Sep 2 11:11:22 2020 +0300 RDMA/cma: Fix use after free race in roce multicast join [ Upstream commit b5de0c60cc30c2a3513c7188c73f3f29acc29234 ] The roce path triggers a work queue that continues to touch the id_priv but doesn't hold any reference on it. Futher, unlike in the IB case, the work queue is not fenced during rdma_destroy_id(). This can trigger a use after free if a destroy is triggered in the incredibly narrow window after the queue_work and the work starting and obtaining the handler_mutex. The only purpose of this work queue is to run the ULP event callback from the standard context, so switch the design to use the existing cma_work_handler() scheme. This simplifies quite a lot of the flow: - Use the cma_work_handler() callback to launch the work for roce. This requires generating the event synchronously inside the rdma_join_multicast(), which in turn means the dummy struct ib_sa_multicast can become a simple stack variable. - cm_work_handler() used the id_priv kref, so we can entirely eliminate the kref inside struct cma_multicast. Since the cma_multicast never leaks into an unprotected work queue the kfree can be done at the same time as for IB. - Eliminating the general multicast.ib requires using cma_set_mgid() in a few places to recompute the mgid. Fixes: 3c86aa70bf67 ("RDMA/cm: Add RDMA CM support for IBoE devices") Link: https://lore.kernel.org/r/20200902081122.745412-9-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 324044dc164f43bcf17094a86d3a0abc4921c967 Author: Jason Gunthorpe Date: Wed Sep 2 11:11:21 2020 +0300 RDMA/cma: Consolidate the destruction of a cma_multicast in one place [ Upstream commit 3788d2997bc0150ea911a964d5b5a2e11808a936 ] Two places were open coding this sequence, and also pull in cma_leave_roce_mc_group() which was called only once. Link: https://lore.kernel.org/r/20200902081122.745412-8-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit cdb636585b5731e80847914191d78111aa9aba7e Author: Jason Gunthorpe Date: Wed Sep 2 11:11:20 2020 +0300 RDMA/cma: Remove dead code for kernel rdmacm multicast [ Upstream commit 1bb5091def706732c749df9aae45fbca003696f2 ] There is no kernel user of RDMA CM multicast so this code managing the multicast subscription of the kernel-only internal QP is dead. Remove it. This makes the bug fixes in the next patches much simpler. Link: https://lore.kernel.org/r/20200902081122.745412-7-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 85408e96b13074168ce2c37be9f968758179a145 Author: Jason Gunthorpe Date: Wed Sep 2 11:11:19 2020 +0300 RDMA/cma: Combine cma_ndev_work with cma_work [ Upstream commit 7e85bcda8bfe883f4244672ed79f81b7762a1a7e ] These are the same thing, except that cma_ndev_work doesn't have a state transition. Signal no state transition by setting old_state and new_state == 0. In all cases the handler function should not be called once rdma_destroy_id() has progressed passed setting the state. Link: https://lore.kernel.org/r/20200902081122.745412-6-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 71ccb8ea5bbbd6e0ac691e696ee562fd6d522c64 Author: Vaibhav Jain Date: Sat Sep 12 13:44:51 2020 +0530 powerpc/papr_scm: Fix warning triggered by perf_stats_show() [ Upstream commit ca78ef2f08ccfa29b711d644964cdf9d7ace15e5 ] A warning is reported by the kernel in case perf_stats_show() returns an error code. The warning is of the form below: papr_scm ibm,persistent-memory:ibm,pmemory@44100001: Failed to query performance stats, Err:-10 dev_attr_show: perf_stats_show+0x0/0x1c0 [papr_scm] returned bad count fill_read_buffer: dev_attr_show+0x0/0xb0 returned bad count On investigation it looks like that the compiler is silently truncating the return value of drc_pmem_query_stats() from 'long' to 'int', since the variable used to store the return code 'rc' is an 'int'. This truncated value is then returned back as a 'ssize_t' back from perf_stats_show() to 'dev_attr_show()' which thinks of it as a large unsigned number and triggers this warning.. To fix this we update the type of variable 'rc' from 'int' to 'ssize_t' that prevents the compiler from truncating the return value of drc_pmem_query_stats() and returning correct signed value back from perf_stats_show(). Fixes: 2d02bf835e57 ("powerpc/papr_scm: Fetch nvdimm performance stats from PHYP") Signed-off-by: Vaibhav Jain Reviewed-by: Ira Weiny Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200912081451.66225-1-vaibhav@linux.ibm.com Signed-off-by: Sasha Levin commit fcde058bfa98dcb804a547330f0ff46ebbf9b509 Author: Nicholas Piggin Date: Mon Sep 14 14:52:19 2020 +1000 powerpc/64s/radix: Fix mm_cpumask trimming race vs kthread_use_mm [ Upstream commit a665eec0a22e11cdde708c1c256a465ebe768047 ] Commit 0cef77c7798a7 ("powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask") added a mechanism to trim the mm_cpumask of a process under certain conditions. One of the assumptions is that mm_users would not be incremented via a reference outside the process context with mmget_not_zero() then go on to kthread_use_mm() via that reference. That invariant was broken by io_uring code (see previous sparc64 fix), but I'll point Fixes: to the original powerpc commit because we are changing that assumption going forward, so this will make backports match up. Fix this by no longer relying on that assumption, but by having each CPU check the mm is not being used, and clearing their own bit from the mask only if it hasn't been switched-to by the time the IPI is processed. This relies on commit 38cf307c1f20 ("mm: fix kthread_use_mm() vs TLB invalidate") and ARCH_WANT_IRQS_OFF_ACTIVATE_MM to disable irqs over mm switch sequences. Fixes: 0cef77c7798a7 ("powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask") Signed-off-by: Nicholas Piggin Reviewed-by: Michael Ellerman Depends-on: 38cf307c1f20 ("mm: fix kthread_use_mm() vs TLB invalidate") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200914045219.3736466-5-npiggin@gmail.com Signed-off-by: Sasha Levin commit 600b349d0fcee3d4cf7fe6bbfbc148cdd347c992 Author: Christophe Leroy Date: Fri Sep 11 05:05:38 2020 +0000 powerpc/kasan: Fix CONFIG_KASAN_VMALLOC for 8xx [ Upstream commit 4c42dc5c69a8f24c467a6c997909d2f1d4efdc7f ] Before the commit identified below, pages tables allocation was performed after the allocation of final shadow area for linear memory. But that commit switched the order, leading to page tables being already allocated at the time 8xx kasan_init_shadow_8M() is called. Due to this, kasan_init_shadow_8M() doesn't map the needed shadow entries because there are already page tables. kasan_init_shadow_8M() installs huge PMD entries instead of page tables. We could at that time free the page tables, but there is no point in creating page tables that get freed before being used. Only book3s/32 hash needs early allocation of page tables. For other variants, we can keep the initial order and create remaining page tables after the allocation of final shadow memory for linear mem. Move back the allocation of shadow page tables for CONFIG_KASAN_VMALLOC into kasan_init() after the loop which creates final shadow memory for linear mem. Fixes: 41ea93cf7ba4 ("powerpc/kasan: Fix shadow pages allocation failure") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/8ae4554357da4882612644a74387ae05525b2aaa.1599800716.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit b4fde57430d26fc3cb2016acbf2b515eebc7dd85 Author: Finn Thain Date: Sat Sep 5 09:02:20 2020 +1000 powerpc/tau: Disable TAU between measurements [ Upstream commit e63d6fb5637e92725cf143559672a34b706bca4f ] Enabling CONFIG_TAU_INT causes random crashes: Unrecoverable exception 1700 at c0009414 (msr=1000) Oops: Unrecoverable exception, sig: 6 [#1] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-pmac-00043-gd5f545e1a8593 #5 NIP: c0009414 LR: c0009414 CTR: c00116fc REGS: c0799eb8 TRAP: 1700 Not tainted (5.7.0-pmac-00043-gd5f545e1a8593) MSR: 00001000 CR: 22000228 XER: 00000100 GPR00: 00000000 c0799f70 c076e300 00800000 0291c0ac 00e00000 c076e300 00049032 GPR08: 00000001 c00116fc 00000000 dfbd3200 ffffffff 007f80a8 00000000 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c075ce04 GPR24: c075ce04 dfff8880 c07b0000 c075ce04 00080000 00000001 c079ef98 c079ef5c NIP [c0009414] arch_cpu_idle+0x24/0x6c LR [c0009414] arch_cpu_idle+0x24/0x6c Call Trace: [c0799f70] [00000001] 0x1 (unreliable) [c0799f80] [c0060990] do_idle+0xd8/0x17c [c0799fa0] [c0060ba4] cpu_startup_entry+0x20/0x28 [c0799fb0] [c072d220] start_kernel+0x434/0x44c [c0799ff0] [00003860] 0x3860 Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX 3d20c07b XXXXXXXX XXXXXXXX XXXXXXXX 7c0802a6 XXXXXXXX XXXXXXXX XXXXXXXX 4e800421 XXXXXXXX XXXXXXXX XXXXXXXX 7d2000a6 ---[ end trace 3a0c9b5cb216db6b ]--- Resolve this problem by disabling each THRMn comparator when handling the associated THRMn interrupt and by disabling the TAU entirely when updating THRMn thresholds. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain Tested-by: Stan Johnson Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/5a0ba3dc5612c7aac596727331284a3676c08472.1599260540.git.fthain@telegraphics.com.au Signed-off-by: Sasha Levin commit 7a1a068151c90dfbedfb2d9f9ebfa566a801ef4e Author: Finn Thain Date: Sat Sep 5 09:02:20 2020 +1000 powerpc/tau: Check processor type before enabling TAU interrupt [ Upstream commit 5e3119e15fed5b9a9a7e528665ff098a4a8dbdbc ] According to Freescale's documentation, MPC74XX processors have an erratum that prevents the TAU interrupt from working, so don't try to use it when running on those processors. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain Tested-by: Stan Johnson Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/c281611544768e758bd58fe812cf702a5bd2d042.1599260540.git.fthain@telegraphics.com.au Signed-off-by: Sasha Levin commit 1f8b3ec7e89f74dc5e4c00ec4aa8e547c1ef1d32 Author: Finn Thain Date: Sat Sep 5 09:02:20 2020 +1000 powerpc/tau: Remove duplicated set_thresholds() call [ Upstream commit 420ab2bc7544d978a5d0762ee736412fe9c796ab ] The commentary at the call site seems to disagree with the code. The conditional prevents calling set_thresholds() via the exception handler, which appears to crash. Perhaps that's because it immediately triggers another TAU exception. Anyway, calling set_thresholds() from TAUupdate() is redundant because tau_timeout() does so. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain Tested-by: Stan Johnson Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/d7c7ee33232cf72a6a6bbb6ef05838b2e2b113c0.1599260540.git.fthain@telegraphics.com.au Signed-off-by: Sasha Levin commit 3bd43bd1235c3bab575ae4d7eb26429b089624a0 Author: Finn Thain Date: Sat Sep 5 09:02:20 2020 +1000 powerpc/tau: Convert from timer to workqueue [ Upstream commit b1c6a0a10bfaf36ec82fde6f621da72407fa60a1 ] Since commit 19dbdcb8039cf ("smp: Warn on function calls from softirq context") the Thermal Assist Unit driver causes a warning like the following when CONFIG_SMP is enabled. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/smp.c:428 smp_call_function_many_cond+0xf4/0x38c Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-pmac #3 NIP: c00b37a8 LR: c00b3abc CTR: c001218c REGS: c0799c60 TRAP: 0700 Not tainted (5.7.0-pmac) MSR: 00029032 CR: 42000224 XER: 00000000 GPR00: c00b3abc c0799d18 c076e300 c079ef5c c0011fec 00000000 00000000 00000000 GPR08: 00000100 00000100 00008000 ffffffff 42000224 00000000 c079d040 c079d044 GPR16: 00000001 00000000 00000004 c0799da0 c079f054 c07a0000 c07a0000 00000000 GPR24: c0011fec 00000000 c079ef5c c079ef5c 00000000 00000000 00000000 00000000 NIP [c00b37a8] smp_call_function_many_cond+0xf4/0x38c LR [c00b3abc] on_each_cpu+0x38/0x68 Call Trace: [c0799d18] [ffffffff] 0xffffffff (unreliable) [c0799d68] [c00b3abc] on_each_cpu+0x38/0x68 [c0799d88] [c0096704] call_timer_fn.isra.26+0x20/0x7c [c0799d98] [c0096b40] run_timer_softirq+0x1d4/0x3fc [c0799df8] [c05b4368] __do_softirq+0x118/0x240 [c0799e58] [c0039c44] irq_exit+0xc4/0xcc [c0799e68] [c000ade8] timer_interrupt+0x1b0/0x230 [c0799ea8] [c0013520] ret_from_except+0x0/0x14 --- interrupt: 901 at arch_cpu_idle+0x24/0x6c LR = arch_cpu_idle+0x24/0x6c [c0799f70] [00000001] 0x1 (unreliable) [c0799f80] [c0060990] do_idle+0xd8/0x17c [c0799fa0] [c0060ba8] cpu_startup_entry+0x24/0x28 [c0799fb0] [c072d220] start_kernel+0x434/0x44c [c0799ff0] [00003860] 0x3860 Instruction dump: 8129f204 2f890000 40beff98 3d20c07a 8929eec4 2f890000 40beff88 0fe00000 81220000 552805de 550802ef 4182ff84 <0fe00000> 3860ffff 7f65db78 7f44d378 ---[ end trace 34a886e47819c2eb ]--- Don't call on_each_cpu() from a timer callback, call it from a worker thread instead. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/bb61650bea4f4c91fb8e24b9a6f130a1438651a7.1599260540.git.fthain@telegraphics.com.au Signed-off-by: Sasha Levin commit 2760b7aa89a70dc42d4719d42ef8e3fb2e44621d Author: Finn Thain Date: Sat Sep 5 09:02:20 2020 +1000 powerpc/tau: Use appropriate temperature sample interval [ Upstream commit 66943005cc41f48e4d05614e8f76c0ca1812f0fd ] According to the MPC750 Users Manual, the SITV value in Thermal Management Register 3 is 13 bits long. The present code calculates the SITV value as 60 * 500 cycles. This would overflow to give 10 us on a 500 MHz CPU rather than the intended 60 us. (But according to the Microprocessor Datasheet, there is also a factor of 266 that has to be applied to this value on certain parts i.e. speed sort above 266 MHz.) Always use the maximum cycle count, as recommended by the Datasheet. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain Tested-by: Stan Johnson Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/896f542e5f0f1d6cf8218524c2b67d79f3d69b3c.1599260540.git.fthain@telegraphics.com.au Signed-off-by: Sasha Levin commit c38ae2b7e57c3e7e72ada24f195fe5f53281c6a8 Author: Aneesh Kumar K.V Date: Mon Jun 8 12:39:03 2020 +0530 powerpc/book3s64/hash/4k: Support large linear mapping range with 4K [ Upstream commit 7746406baa3bc9e23fdd7b7da2f04d86e25ab837 ] With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in the same 0xc range"), we now split the 64TB address range into 4 contexts each of 16TB. That implies we can do only 16TB linear mapping. On some systems, eg. Power9, memory attached to nodes > 0 will appear above 16TB in the linear mapping. This resulted in kernel crash when we boot such systems in hash translation mode with 4K PAGE_SIZE. This patch updates the kernel mapping such that we now start supporting upto 61TB of memory with 4K. The kernel mapping now looks like below 4K PAGE_SIZE and hash translation. vmalloc start = 0xc0003d0000000000 IO start = 0xc0003e0000000000 vmemmap start = 0xc0003f0000000000 Our MAX_PHYSMEM_BITS for 4K is still 64TB even though we can only map 61TB. We prevent bolt mapping anything outside 61TB range by checking against H_VMALLOC_START. Fixes: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in the same 0xc range") Reported-by: Cameron Berkenpas Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200608070904.387440-3-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin commit 8b2da501eae721ec033a27b8fb8d883b12180b0f Author: Ravi Bangoria Date: Wed Sep 2 09:59:43 2020 +0530 powerpc/watchpoint: Add hw_len wherever missing [ Upstream commit 58da5984d2ea6d95f3f9d9e8dd9f7e1b0dddfb3c ] There are couple of places where we set len but not hw_len. For ptrace/perf watchpoints, when CONFIG_HAVE_HW_BREAKPOINT=Y, hw_len will be calculated and set internally while parsing watchpoint. But when CONFIG_HAVE_HW_BREAKPOINT=N, we need to manually set 'hw_len'. Similarly for xmon as well, hw_len needs to be set directly. Fixes: b57aeab811db ("powerpc/watchpoint: Fix length calculation for unaligned target") Signed-off-by: Ravi Bangoria Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200902042945.129369-7-ravi.bangoria@linux.ibm.com Signed-off-by: Sasha Levin commit 9abfddaa27d7eca60203af4f59a299e3c3cda2d7 Author: Ravi Bangoria Date: Wed Sep 2 09:59:39 2020 +0530 powerpc/watchpoint: Fix handling of vector instructions [ Upstream commit 4441eb02333a9b46a0d919aa7a6d3b137b5f2562 ] Vector load/store instructions are special because they are always aligned. Thus unaligned EA needs to be aligned down before comparing it with watch ranges. Otherwise we might consider valid event as invalid. Fixes: 74c6881019b7 ("powerpc/watchpoint: Prepare handler to handle more than one watchpoint") Signed-off-by: Ravi Bangoria Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200902042945.129369-3-ravi.bangoria@linux.ibm.com Signed-off-by: Sasha Levin commit 69a94e53245cea2992ba4710cde5598f30ba109e Author: Ravi Bangoria Date: Wed Sep 2 09:59:38 2020 +0530 powerpc/watchpoint: Fix quadword instruction handling on p10 predecessors [ Upstream commit 4759c11ed20454b7b36db4ec15f7d5aa1519af4a ] On p10 predecessors, watchpoint with quadword access is compared at quadword length. If the watch range is doubleword or less than that in a first half of quadword aligned 16 bytes, and if there is any unaligned quadword access which will access only the 2nd half, the handler should consider it as extraneous and emulate/single-step it before continuing. Fixes: 74c6881019b7 ("powerpc/watchpoint: Prepare handler to handle more than one watchpoint") Reported-by: Pedro Miraglia Franco de Carvalho Signed-off-by: Ravi Bangoria Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200902042945.129369-2-ravi.bangoria@linux.ibm.com Signed-off-by: Sasha Levin commit 810d23775d0efa68471199058b1ffc0bab502145 Author: Thiago Jung Bauermann Date: Tue Aug 18 19:11:26 2020 -0300 powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory [ Upstream commit eae9eec476d13fad9af6da1f44a054ee02b7b161 ] POWER secure guests (i.e., guests which use the Protected Execution Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but they don't need the SWIOTLB memory to be in low addresses since the hypervisor doesn't have any addressing limitation. This solves a SWIOTLB initialization problem we are seeing in secure guests with 128 GB of RAM: they are configured with 4 GB of crashkernel reserved memory, which leaves no space for SWIOTLB in low addresses. To do this, we use mostly the same code as swiotlb_init(), but allocate the buffer using memblock_alloc() instead of memblock_alloc_low(). Fixes: 2efbc58f157a ("powerpc/pseries/svm: Force SWIOTLB for secure guests") Signed-off-by: Thiago Jung Bauermann Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200818221126.391073-1-bauerman@linux.ibm.com Signed-off-by: Sasha Levin commit d9fbd9065a03a148318ca10b9fa2b82dc74a19f9 Author: Michal Kalderon Date: Wed Sep 2 19:57:40 2020 +0300 RDMA/qedr: Fix inline size returned for iWARP [ Upstream commit fbf58026b2256e9cd5f241a4801d79d3b2b7b89d ] commit 59e8970b3798 ("RDMA/qedr: Return max inline data in QP query result") changed query_qp max_inline size to return the max roce inline size. When iwarp was introduced, this should have been modified to return the max inline size based on protocol. This size is cached in the device attributes Fixes: 69ad0e7fe845 ("RDMA/qedr: Add support for iWARP in user space") Link: https://lore.kernel.org/r/20200902165741.8355-8-michal.kalderon@marvell.com Signed-off-by: Michal Kalderon Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 08685dcb1fce8eafac24905cad371f003a8c348d Author: Michal Kalderon Date: Wed Sep 2 19:57:37 2020 +0300 RDMA/qedr: Fix return code if accept is called on a destroyed qp [ Upstream commit 8a5a10a1a74465065c75d9de1aa6685e1f1aa117 ] In iWARP, accept could be called after a QP is already destroyed. In this case an error should be returned and not success. Fixes: 82af6d19d8d9 ("RDMA/qedr: Fix synchronization methods and memory leaks in qedr") Link: https://lore.kernel.org/r/20200902165741.8355-5-michal.kalderon@marvell.com Signed-off-by: Michal Kalderon Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3d5f2626e85380b77b14e3f6868c0fc11d08df10 Author: Michal Kalderon Date: Wed Sep 2 19:57:36 2020 +0300 RDMA/qedr: Fix use of uninitialized field [ Upstream commit a379ad54e55a12618cae7f6333fd1b3071de9606 ] dev->attr.page_size_caps was used uninitialized when setting device attributes Fixes: ec72fce401c6 ("qedr: Add support for RoCE HW init") Link: https://lore.kernel.org/r/20200902165741.8355-4-michal.kalderon@marvell.com Signed-off-by: Michal Kalderon Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 4707f2a10dab63eb0af0594c930e69bb440795e1 Author: Michal Kalderon Date: Wed Sep 2 19:57:35 2020 +0300 RDMA/qedr: Fix doorbell setting [ Upstream commit 0b1eddc1964351cd5ce57aff46853ed4ce9ebbff ] Change the doorbell setting so that the maximum value between the last and current value is set. This is to avoid doorbells being lost. Fixes: a7efd7773e31 ("qedr: Add support for PD,PKEY and CQ verbs") Link: https://lore.kernel.org/r/20200902165741.8355-3-michal.kalderon@marvell.com Signed-off-by: Michal Kalderon Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c41bd80f619920171c0c1a0435458eeada684474 Author: Michal Kalderon Date: Wed Sep 2 19:57:34 2020 +0300 RDMA/qedr: Fix qp structure memory leak [ Upstream commit 098e345a1a8faaad6e4e54d138773466cecc45d4 ] The qedr_qp structure wasn't freed when the protocol was RoCE. kmemleak output when running basic RoCE scenario. unreferenced object 0xffff927ad7e22c00 (size 1024): comm "ib_send_bw", pid 7082, jiffies 4384133693 (age 274.698s) hex dump (first 32 bytes): 00 b0 cd a2 79 92 ff ff 00 3f a1 a2 79 92 ff ff ....y....?..y... 00 ee 5c dd 80 92 ff ff 00 f6 5c dd 80 92 ff ff ..\.......\..... backtrace: [<00000000b2ba0f35>] qedr_create_qp+0xb3/0x6c0 [qedr] [<00000000e85a43dd>] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x555/0xad0 [ib_uverbs] [<00000000fee4d029>] ib_uverbs_cmd_verbs+0xa5a/0xb80 [ib_uverbs] [<000000005d622660>] ib_uverbs_ioctl+0xa4/0x110 [ib_uverbs] [<00000000eb4cdc71>] ksys_ioctl+0x87/0xc0 [<00000000abe6b23a>] __x64_sys_ioctl+0x16/0x20 [<0000000046e7cef4>] do_syscall_64+0x4d/0x90 [<00000000c6948f76>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 1212767e23bb ("qedr: Add wrapping generic structure for qpidr and adjust idr routines.") Link: https://lore.kernel.org/r/20200902165741.8355-2-michal.kalderon@marvell.com Signed-off-by: Michal Kalderon Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8d5dc2ff5e4ffdf9883279ec8a741ec0073cab10 Author: Jason Gunthorpe Date: Fri Sep 4 19:41:43 2020 -0300 RDMA/umem: Prevent small pages from being returned by ib_umem_find_best_pgsz() [ Upstream commit 10c75ccb54e4fe548cb16d7ed426d7d709e6ae76 ] rdma_for_each_block() makes assumptions about how the SGL is constructed that don't work if the block size is below the page size used to to build the SGL. The rules for umem SGL construction require that the SG's all be PAGE_SIZE aligned and we don't encode the actual byte offset of the VA range inside the SGL using offset and length. So rdma_for_each_block() has no idea where the actual starting/ending point is to compute the first/last block boundary if the starting address should be within a SGL. Fixing the SGL construction turns out to be really hard, and will be the subject of other patches. For now block smaller pages. Fixes: 4a35339958f1 ("RDMA/umem: Add API to find best driver supported page size in an MR") Link: https://lore.kernel.org/r/2-v2-270386b7e60b+28f4-umem_1_jgg@nvidia.com Reviewed-by: Leon Romanovsky Reviewed-by: Shiraz Saleem Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 488229b7729d7becf4c39c5e74fb709fb35115c2 Author: Jason Gunthorpe Date: Fri Sep 4 19:41:42 2020 -0300 RDMA/umem: Fix ib_umem_find_best_pgsz() for mappings that cross a page boundary [ Upstream commit a40c20dabdf9045270767c75918feb67f0727c89 ] It is possible for a single SGL to span an aligned boundary, eg if the SGL is 61440 -> 90112 Then the length is 28672, which currently limits the block size to 32k. With a 32k page size the two covering blocks will be: 32768->65536 and 65536->98304 However, the correct answer is a 128K block size which will span the whole 28672 bytes in a single block. Instead of limiting based on length figure out which high IOVA bits don't change between the start and end addresses. That is the highest useful page size. Fixes: 4a35339958f1 ("RDMA/umem: Add API to find best driver supported page size in an MR") Link: https://lore.kernel.org/r/1-v2-270386b7e60b+28f4-umem_1_jgg@nvidia.com Reviewed-by: Leon Romanovsky Reviewed-by: Shiraz Saleem Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 09aa2ec9dd366756eecbdfaa64f5e858e0253574 Author: Leon Romanovsky Date: Mon Sep 7 15:09:20 2020 +0300 RDMA: Restore ability to return error for destroy WQ [ Upstream commit add53535fb3033c249d9327ae3e7c36d3382bbd1 ] Make this interface symmetrical to other destroy paths. Fixes: a49b1dc7ae44 ("RDMA: Convert destroy_wq to be void") Link: https://lore.kernel.org/r/20200907120921.476363-9-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7c2f7696cf9e73062d7040607fe61063c629f9cc Author: Leon Romanovsky Date: Mon Sep 7 15:09:19 2020 +0300 RDMA: Change XRCD destroy return value [ Upstream commit d0c45c8556e57342d44c9548763609ffcc4e3866 ] Update XRCD destroy flow to allow command failure. Fixes: 28ad5f65c314 ("RDMA: Move XRCD to be under ib_core responsibility") Link: https://lore.kernel.org/r/20200907120921.476363-8-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 093f87dda065e0f618dd577985eccbe85efb9b54 Author: Leon Romanovsky Date: Mon Sep 7 15:09:18 2020 +0300 RDMA: Allow fail of destroy CQ [ Upstream commit 43d781b9fa562f0c6e50f62c870fbfeb9dc85213 ] Like any other verbs objects, CQ shouldn't fail during destroy, but mlx5_ib didn't follow this contract with mixed IB verbs objects with DEVX. Such mix causes to the situation where FW and kernel are fully interdependent on the reference counting of each side. Kernel verbs and drivers that don't have DEVX flows shouldn't fail. Fixes: e39afe3d6dbd ("RDMA: Convert CQ allocations to be under core responsibility") Link: https://lore.kernel.org/r/20200907120921.476363-7-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 590b3cc0af58f96e024100777ea1f3c9f5a3be4a Author: Leon Romanovsky Date: Mon Sep 7 15:09:17 2020 +0300 RDMA/core: Delete function indirection for alloc/free kernel CQ [ Upstream commit 7e3c66c9a989d5b53387ceebc88b9e4a9b1d6434 ] The ib_alloc_cq*() and ib_free_cq*() are solely kernel verbs to manage CQs and doesn't need extra indirection just to call same functions with constant parameter NULL as udata. Link: https://lore.kernel.org/r/20200907120921.476363-6-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit be4c05d13edb071089eae790c982292ca49dd81b Author: Md Haris Iqbal Date: Mon Sep 7 16:01:06 2020 +0530 RDMA/rtrs-srv: Incorporate ib_register_client into rtrs server init [ Upstream commit 558d52b2976b1db3098139aa83ceb9af9066a0e7 ] The rnbd_server module's communication manager (cm) initialization depends on the registration of the "network namespace subsystem" of the RDMA CM agent module. As such, when the kernel is configured to load the rnbd_server and the RDMA cma module during initialization; and if the rnbd_server module is initialized before RDMA cma module, a null ptr dereference occurs during the RDMA bind operation. Call trace: Call Trace: ? xas_load+0xd/0x80 xa_load+0x47/0x80 cma_ps_find+0x44/0x70 rdma_bind_addr+0x782/0x8b0 ? get_random_bytes+0x35/0x40 rtrs_srv_cm_init+0x50/0x80 rtrs_srv_open+0x102/0x180 ? rnbd_client_init+0x6e/0x6e rnbd_srv_init_module+0x34/0x84 ? rnbd_client_init+0x6e/0x6e do_one_initcall+0x4a/0x200 kernel_init_freeable+0x1f1/0x26e ? rest_init+0xb0/0xb0 kernel_init+0xe/0x100 ret_from_fork+0x22/0x30 Modules linked in: CR2: 0000000000000015 All this happens cause the cm init is in the call chain of the module init, which is not a preferred practice. So remove the call to rdma_create_id() from the module init call chain. Instead register rtrs-srv as an ib client, which makes sure that the rdma_create_id() is called only when an ib device is added. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20200907103106.104530-1-haris.iqbal@cloud.ionos.com Reported-by: kernel test robot Signed-off-by: Md Haris Iqbal Reviewed-by: Jack Wang Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 24b2c898028d63990df49644f056c6d5cf6bfa68 Author: Darrick J. Wong Date: Tue Oct 13 08:46:27 2020 -0700 xfs: fix high key handling in the rt allocator's query_range function [ Upstream commit d88850bd5516a77c6f727e8b6cefb64e0cc929c7 ] Fix some off-by-one errors in xfs_rtalloc_query_range. The highest key in the realtime bitmap is always one less than the number of rt extents, which means that the key clamp at the start of the function is wrong. The 4th argument to xfs_rtfind_forw is the highest rt extent that we want to probe, which means that passing 1 less than the high key is wrong. Finally, drop the rem variable that controls the loop because we can compare the iteration point (rtstart) against the high key directly. The sordid history of this function is that the original commit (fb3c3) incorrectly passed (high_rec->ar_startblock - 1) as the 'limit' parameter to xfs_rtfind_forw. This was wrong because the "high key" is supposed to be the largest key for which the caller wants result rows, not the key for the first row that could possibly be outside the range that the caller wants to see. A subsequent attempt (8ad56) to strengthen the parameter checking added incorrect clamping of the parameters to the number of rt blocks in the system (despite the bitmap functions all taking units of rt extents) to avoid querying ranges past the end of rt bitmap file but failed to fix the incorrect _rtfind_forw parameter. The original _rtfind_forw parameter error then survived the conversion of the startblock and blockcount fields to rt extents (a0e5c), and the most recent off-by-one fix (a3a37) thought it was patching a problem when the end of the rt volume is not in use, but none of these fixes actually solved the original problem that the author was confused about the "limit" argument to xfs_rtfind_forw. Sadly, all four of these patches were written by this author and even his own usage of this function and rt testing were inadequate to get this fixed quickly. Original-problem: fb3c3de2f65c ("xfs: add a couple of queries to iterate free extents in the rtbitmap") Not-fixed-by: 8ad560d2565e ("xfs: strengthen rtalloc query range checks") Not-fixed-by: a0e5c435babd ("xfs: fix xfs_rtalloc_rec units") Fixes: a3a374bf1889 ("xfs: fix off-by-one error in xfs_rtalloc_query_range") Signed-off-by: Darrick J. Wong Reviewed-by: Chandan Babu R Signed-off-by: Sasha Levin commit f184013a1178e3c4f68a6fbfd61e34a2da40133c Author: Scott Mayhew Date: Sat Oct 10 10:03:12 2020 -0400 nfs: add missing "posix" local_lock constant table definition [ Upstream commit a2d24bcb97dc7b0be1cb891e60ae133bdf36c786 ] "mount -o local_lock=posix..." was broken by the mount API conversion due to the missing constant. Fixes: e38bb238ed8c ("NFS: Convert mount option parsing to use functionality from fs_parser.h") Signed-off-by: Scott Mayhew Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit f02daaa897788e7d8173130710466cbedb313256 Author: Darrick J. Wong Date: Thu Oct 1 10:56:07 2020 -0700 xfs: fix deadlock and streamline xfs_getfsmap performance [ Upstream commit 8ffa90e1145c70c7ac47f14b59583b2296d89e72 ] Refactor xfs_getfsmap to improve its performance: instead of indirectly calling a function that copies one record to userspace at a time, create a shadow buffer in the kernel and copy the whole array once at the end. On the author's computer, this reduces the runtime on his /home by ~20%. This also eliminates a deadlock when running GETFSMAP against the realtime device. The current code locks the rtbitmap to create fsmappings and copies them into userspace, having not released the rtbitmap lock. If the userspace buffer is an mmap of a sparse file that itself resides on the realtime device, the write page fault will recurse into the fs for allocation, which will deadlock on the rtbitmap lock. Fixes: 4c934c7dd60c ("xfs: report realtime space information via the rtbitmap") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Chandan Babu R Signed-off-by: Sasha Levin commit afd372962899aa95c8a36cebf7aa75b4193e6a28 Author: Darrick J. Wong Date: Thu Oct 1 10:56:07 2020 -0700 xfs: limit entries returned when counting fsmap records [ Upstream commit acd1ac3aa22fd58803a12d26b1ab7f70232f8d8d ] If userspace asked fsmap to count the number of entries, we cannot return more than UINT_MAX entries because fmh_entries is u32. Therefore, stop counting if we hit this limit or else we will waste time to return truncated results. Fixes: e89c041338ed ("xfs: implement the GETFSMAP ioctl") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Chandan Babu R Signed-off-by: Sasha Levin commit cc3a03c9c13e7f089866c34e4fa06ffc53d5c9ec Author: Matthew Wilcox (Oracle) Date: Thu Apr 2 14:26:13 2020 -0400 ida: Free allocated bitmap in error path [ Upstream commit a219b856a2b993da234108307be772448f22b0ce ] If a bitmap needs to be allocated, and then by the time the thread is scheduled to be run again all the indices which would satisfy the allocation have been allocated then we would leak the allocation. Almost impossible to hit in practice, but a trivial fix. Found by Coverity. Fixes: f32f004cddf8 ("ida: Convert to XArray") Reported-by: coverity-bot Reviewed-by: Kees Cook Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin commit 0ee5ef9d3a5a5f2f95c92269be2473e235f8f950 Author: Necip Fazil Yildiran Date: Mon Sep 14 14:46:52 2020 +0300 arc: plat-hsdk: fix kconfig dependency warning when !RESET_CONTROLLER [ Upstream commit 63bcf87cb1c57956e1179f1a78dde625c7e3cba7 ] When ARC_SOC_HSDK is enabled and RESET_CONTROLLER is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for RESET_HSDK Depends on [n]: RESET_CONTROLLER [=n] && HAS_IOMEM [=y] && (ARC_SOC_HSDK [=y] || COMPILE_TEST [=n]) Selected by [y]: - ARC_SOC_HSDK [=y] && ISA_ARCV2 [=y] The reason is that ARC_SOC_HSDK selects RESET_HSDK without depending on or selecting RESET_CONTROLLER while RESET_HSDK is subordinate to RESET_CONTROLLER. Honor the kconfig menu hierarchy to remove kconfig dependency warnings. Fixes: a528629dfd3b ("ARC: [plat-hsdk] select CONFIG_RESET_HSDK from Kconfig") Signed-off-by: Necip Fazil Yildiran Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit e22702d31300b33fef1c6784b6d1dcd41d5ae1bd Author: Greg Ungerer Date: Mon Sep 21 12:55:20 2020 +1000 m68knommu: include SDHC support only when hardware has it [ Upstream commit 322c512f476f07e960cecd447ef22c15bed0e5f1 ] The mere fact that the kernel has the MMC subsystem enabled (CONFIG_MMC enabled) does not mean that the underlying hardware platform has the SDHC hardware present. Within the ColdFire hardware defines that is signified by MCFSDHC_BASE being defined with an address. The platform data for the ColdFire parts is including the SDHC hardware if CONFIG_MMC is enabled, instead of MCFSDHC_BASE. This means that if you are compiling for a ColdFire target that does not support SDHC but enable CONFIG_MMC you will fail to compile with errors like this: arch/m68k/coldfire/device.c:565:12: error: ‘MCFSDHC_BASE’ undeclared here (not in a function) .start = MCFSDHC_BASE, ^ arch/m68k/coldfire/device.c:566:25: error: ‘MCFSDHC_SIZE’ undeclared here (not in a function) .end = MCFSDHC_BASE + MCFSDHC_SIZE - 1, ^ arch/m68k/coldfire/device.c:569:12: error: ‘MCF_IRQ_SDHC’ undeclared here (not in a function) .start = MCF_IRQ_SDHC, ^ Make the SDHC platform support depend on MCFSDHC_BASE, that is only include it if the specific ColdFire SoC has that hardware module. Fixes: 991f5c4dd2422881 ("m68k: mcf5441x: add support for esdhc mmc controller") Signed-off-by: Greg Ungerer Reviewed-by: Geert Uytterhoeven Reviewed-by: Angelo Dureghello Tested-by: Angelo Dureghello Signed-off-by: Sasha Levin commit 2000cab283e6caccc4dad98786744c225579d2e6 Author: Dave Chinner Date: Wed Sep 30 07:28:52 2020 -0700 xfs: fix finobt btree block recovery ordering [ Upstream commit 671459676ab0e1d371c8d6b184ad1faa05b6941e ] Nathan popped up on #xfs and pointed out that we fail to handle finobt btree blocks in xlog_recover_get_buf_lsn(). This means they always fall through the entire magic number matching code to "recover immediately". Whilst most of the time this is the correct behaviour, occasionally it will be incorrect and could potentially overwrite more recent metadata because we don't check the LSN in the on disk metadata at all. This bug has been present since the finobt was first introduced, and is a potential cause of the occasional xfs_iget_check_free_state() failures we see that indicate that the inode btree state does not match the on disk inode state. Fixes: aafc3c246529 ("xfs: support the XFS_BTNUM_FINOBT free inode btree type") Reported-by: Nathan Scott Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster Signed-off-by: Sasha Levin commit 3e5b6a73c5d831ef2352feda3daf40d229f86484 Author: Guillaume Tucker Date: Tue Sep 1 16:58:06 2020 +0100 ARM: 9007/1: l2c: fix prefetch bits init in L2X0_AUX_CTRL using DT values [ Upstream commit 8e007b367a59bcdf484c81f6df9bd5a4cc179ca6 ] The L310_PREFETCH_CTRL register bits 28 and 29 to enable data and instruction prefetch respectively can also be accessed via the L2X0_AUX_CTRL register. They appear to be actually wired together in hardware between the registers. Changing them in the prefetch register only will get undone when restoring the aux control register later on. For this reason, set these bits in both registers during initialisation according to the devicetree property values. Link: https://lore.kernel.org/lkml/76f2f3ad5e77e356e0a5b99ceee1e774a2842c25.1597061474.git.guillaume.tucker@collabora.com/ Fixes: ec3bd0e68a67 ("ARM: 8391/1: l2c: add options to overwrite prefetching behavior") Signed-off-by: Guillaume Tucker Signed-off-by: Russell King Signed-off-by: Sasha Levin commit e7a9e70c49ed340de924bcc9dbfae43859b07fab Author: Arnaldo Carvalho de Melo Date: Fri Sep 4 17:20:02 2020 -0300 tools feature: Add missing -lzstd to the fast path feature detection [ Upstream commit 6c014694b1d2702cdc736d17b60746e7b95ba664 ] We were failing that due to GTK2+ and then for the ZSTD test, which made test-all.c, the fast path feature detection file to fail and thus trigger building all of the feature tests, slowing down the test. Eventually the ZSTD test would be built and would succeed, since it had the needed -lzstd, avoiding: $ cat /tmp/build/perf/feature/test-all.make.output /usr/bin/ld: /tmp/ccRRJQ4u.o: in function `main_test_libzstd': /home/acme/git/perf/tools/build/feature/test-libzstd.c:8: undefined reference to `ZSTD_createCStream' /usr/bin/ld: /home/acme/git/perf/tools/build/feature/test-libzstd.c:9: undefined reference to `ZSTD_freeCStream' collect2: error: ld returned 1 exit status $ Fix it by adding -lzstd to the test-all target. Now I need an entry to 'perf test' to make sure that /tmp/build/perf/feature/test-all.make.output is empty... Fixes: 3b1c5d9659718263 ("tools build: Implement libzstd feature check, LIBZSTD_DIR and NO_LIBZSTD defines") Reviewed-by: Alexei Budankov Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Ian Rogers Cc: Jiri Olsa Link: http://lore.kernel.org/lkml/20200904202611.GJ3753976@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 9c45b930371d086d83456c12b4c8dc1d4f35e89c Author: Arnaldo Carvalho de Melo Date: Fri Sep 4 17:11:59 2020 -0300 perf tools: Make GTK2 support opt-in [ Upstream commit 4751bddd3f983af2004ec470ca38b42d7a8a53bc ] This is bitrotting, nobody is stepping up to work on it, and since we treat warnings as errors, feature detection is failing in its main, faster test (tools/build/feature/test-all.c) because of the GTK+2 infobar check. So make this opt-in, at some point ditch this if nobody volunteers to take care of this. Cc: Adrian Hunter Cc: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 8b14c6d57e045746a9a6fdf631ae5a98cc4798e2 Author: Jordan Niethe Date: Mon Aug 24 23:12:31 2020 +1000 selftests/powerpc: Fix prefixes in alignment_handler signal handler [ Upstream commit db96221a683342fd4775fd820a4d5376cd2f2ed0 ] The signal handler in the alignment handler self test has the ability to jump over the instruction that triggered the signal. It does this by incrementing the PT_NIP in the user context by 4. If it were a prefixed instruction this will mean that the suffix is then executed which is incorrect. Instead check if the major opcode indicates a prefixed instruction (e.g. it is 1) and if so increment PT_NIP by 8. If ISA v3.1 is not available treat it as a word instruction even if the major opcode is 1. Fixes: 620a6473df36 ("selftests/powerpc: Add prefixed loads/stores to alignment_handler test") Signed-off-by: Jordan Niethe [mpe: Fix 32-bit build, rename haveprefixes to prefixes_enabled] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200824131231.14008-1-jniethe5@gmail.com Signed-off-by: Sasha Levin commit fd7460d9b07e08338d5d03da947019f3fd0ac479 Author: Mark Tomlinson Date: Thu Sep 3 15:42:17 2020 +1200 mtd: mtdoops: Don't write panic data twice [ Upstream commit c1cf1d57d1492235309111ea6a900940213a9166 ] If calling mtdoops_write, don't also schedule work to be done later. Although this appears to not be causing an issue, possibly because the scheduled work will never get done, it is confusing. Fixes: 016c1291ce70 ("mtd: mtdoops: do not use mtd->panic_write directly") Signed-off-by: Mark Tomlinson Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200903034217.23079-1-mark.tomlinson@alliedtelesis.co.nz Signed-off-by: Sasha Levin commit ee8cec0c567e134f2ac70c4b2ee63acdbb9cf226 Author: Leon Romanovsky Date: Sun Aug 30 11:40:04 2020 +0300 RDMA/mlx5: Fix potential race between destroy and CQE poll [ Upstream commit 4b916ed9f9e85f705213ca8d69771d3c1cd6ee5a ] The SRQ can be destroyed right before mlx5_cmd_get_srq is called. In such case the latter will return NULL instead of expected SRQ. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Link: https://lore.kernel.org/r/20200830084010.102381-5-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0b7a478612e2e8facb03afac0d546e8caeec73ba Author: Scott Cheloha Date: Mon Aug 10 20:51:15 2020 -0500 pseries/drmem: don't cache node id in drmem_lmb struct [ Upstream commit e5e179aa3a39c818db8fbc2dce8d2cd24adaf657 ] At memory hot-remove time we can retrieve an LMB's nid from its corresponding memory_block. There is no need to store the nid in multiple locations. Note that lmb_to_memblock() uses find_memory_block() to get the corresponding memory_block. As find_memory_block() runs in sub-linear time this approach is negligibly slower than what we do at present. In exchange for this lookup at hot-remove time we no longer need to call memory_add_physaddr_to_nid() during drmem_init() for each LMB. On powerpc, memory_add_physaddr_to_nid() is a linear search, so this spares us an O(n^2) initialization during boot. On systems with many LMBs that initialization overhead is palpable and disruptive. For example, on a box with 249854 LMBs we're seeing drmem_init() take upwards of 30 seconds to complete: [ 53.721639] drmem: initializing drmem v2 [ 80.604346] watchdog: BUG: soft lockup - CPU#65 stuck for 23s! [swapper/0:1] [ 80.604377] Modules linked in: [ 80.604389] CPU: 65 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc2+ #4 [ 80.604397] NIP: c0000000000a4980 LR: c0000000000a4940 CTR: 0000000000000000 [ 80.604407] REGS: c0002dbff8493830 TRAP: 0901 Not tainted (5.6.0-rc2+) [ 80.604412] MSR: 8000000002009033 CR: 44000248 XER: 0000000d [ 80.604431] CFAR: c0000000000a4a38 IRQMASK: 0 [ 80.604431] GPR00: c0000000000a4940 c0002dbff8493ac0 c000000001904400 c0003cfffffede30 [ 80.604431] GPR04: 0000000000000000 c000000000f4095a 000000000000002f 0000000010000000 [ 80.604431] GPR08: c0000bf7ecdb7fb8 c0000bf7ecc2d3c8 0000000000000008 c00c0002fdfb2001 [ 80.604431] GPR12: 0000000000000000 c00000001e8ec200 [ 80.604477] NIP [c0000000000a4980] hot_add_scn_to_nid+0xa0/0x3e0 [ 80.604486] LR [c0000000000a4940] hot_add_scn_to_nid+0x60/0x3e0 [ 80.604492] Call Trace: [ 80.604498] [c0002dbff8493ac0] [c0000000000a4940] hot_add_scn_to_nid+0x60/0x3e0 (unreliable) [ 80.604509] [c0002dbff8493b20] [c000000000087c10] memory_add_physaddr_to_nid+0x20/0x60 [ 80.604521] [c0002dbff8493b40] [c0000000010d4880] drmem_init+0x25c/0x2f0 [ 80.604530] [c0002dbff8493c10] [c000000000010154] do_one_initcall+0x64/0x2c0 [ 80.604540] [c0002dbff8493ce0] [c0000000010c4aa0] kernel_init_freeable+0x2d8/0x3a0 [ 80.604550] [c0002dbff8493db0] [c000000000010824] kernel_init+0x2c/0x148 [ 80.604560] [c0002dbff8493e20] [c00000000000b648] ret_from_kernel_thread+0x5c/0x74 [ 80.604567] Instruction dump: [ 80.604574] 392918e8 e9490000 e90a000a e92a0000 80ea000c 1d080018 3908ffe8 7d094214 [ 80.604586] 7fa94040 419d00dc e9490010 714a0088 <2faa0008> 409e00ac e9490000 7fbe5040 [ 89.047390] drmem: 249854 LMB(s) With a patched kernel on the same machine we're no longer seeing the soft lockup. drmem_init() now completes in negligible time, even when the LMB count is large. Fixes: b2d3b5ee66f2 ("powerpc/pseries: Track LMB nid instead of using device tree") Signed-off-by: Scott Cheloha Reviewed-by: Nathan Lynch Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200811015115.63677-1-cheloha@linux.ibm.com Signed-off-by: Sasha Levin commit 8b0d3133c43ec6e9f4027807fbad1937684d1eed Author: Nathan Lynch Date: Thu Aug 13 10:11:31 2020 -0500 powerpc/pseries: explicitly reschedule during drmem_lmb list traversal [ Upstream commit 9d6792ffe140240ae54c881cc4183f9acc24b4df ] The drmem lmb list can have hundreds of thousands of entries, and unfortunately lookups take the form of linear searches. As long as this is the case, traversals have the potential to monopolize the CPU and provoke lockup reports, workqueue stalls, and the like unless they explicitly yield. Rather than placing cond_resched() calls within various for_each_drmem_lmb() loop blocks in the code, put it in the iteration expression of the loop macro itself so users can't omit it. Introduce a drmem_lmb_next() iteration helper function which calls cond_resched() at a regular interval during array traversal. Each iteration of the loop in DLPAR code paths can involve around ten RTAS calls which can each take up to 250us, so this ensures the check is performed at worst every few milliseconds. Fixes: 6c6ea53725b3 ("powerpc/mm: Separate ibm, dynamic-memory data from DT format") Signed-off-by: Nathan Lynch Reviewed-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200813151131.2070161-1-nathanl@linux.ibm.com Signed-off-by: Sasha Levin commit a527616f5ff7c8ef762a9d9fc299964ab2615694 Author: Jason Gunthorpe Date: Tue Aug 25 15:17:08 2020 -0300 RDMA/umem: Fix signature of stub ib_umem_find_best_pgsz() [ Upstream commit 61690d01db32eb1f94adc9ac2b8bb741d34e4671 ] The original function returns unsigned long and 0 on failure. Fixes: 4a35339958f1 ("RDMA/umem: Add API to find best driver supported page size in an MR") Link: https://lore.kernel.org/r/0-v1-982a13cc5c6d+501ae-fix_best_pgsz_stub_jgg@nvidia.com Reviewed-by: Gal Pressman Acked-by: Shiraz Saleem Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3321bce35115a7a19a366b20351f3b0ad6591c52 Author: Lang Cheng Date: Tue Aug 25 19:07:54 2020 +0800 RDMA/hns: Add a check for current state before modifying QP [ Upstream commit e0ef0f68c4c0d85b1eb63f38d5d10324361280e8 ] It should be considered an illegal operation if the ULP attempts to modify a QP from another state to the current hardware state. Otherwise, the ULP can modify some fields of QPC at any time. For example, for a QP in state of RTS, modify it from RTR to RTS can change the PSN, which is always not as expected. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Link: https://lore.kernel.org/r/1598353674-24270-1-git-send-email-liweihang@huawei.com Signed-off-by: Lang Cheng Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 2772ec907249ac6f23e6e75b36117ae0edf0bf2f Author: Arnd Bergmann Date: Tue May 5 16:01:16 2020 +0200 mtd: lpddr: fix excessive stack usage with clang [ Upstream commit 3e1b6469f8324bee5927b063e2aca30d3e56b907 ] Building lpddr2_nvm with clang can result in a giant stack usage in one function: drivers/mtd/lpddr/lpddr2_nvm.c:399:12: error: stack frame size of 1144 bytes in function 'lpddr2_nvm_probe' [-Werror,-Wframe-larger-than=] The problem is that clang decides to build a copy of the mtd_info structure on the stack and then do a memcpy() into the actual version. It shouldn't really do it that way, but it's not strictly a bug either. As a workaround, use a static const version of the structure to assign most of the members upfront and then only set the few members that require runtime knowledge at probe time. Fixes: 96ba9dd65788 ("mtd: lpddr: add driver for LPDDR2-NVM PCM memories") Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Acked-by: Miquel Raynal Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200505140136.263461-1-arnd@arndb.de Signed-off-by: Sasha Levin commit 824c146219fb820c98868187f513caedf53be338 Author: Jason Gunthorpe Date: Tue Aug 18 15:05:22 2020 +0300 RDMA/ucma: Add missing locking around rdma_leave_multicast() [ Upstream commit 38e03d092699891c3237b5aee9e8029d4ede0956 ] All entry points to the rdma_cm from a ULP must be single threaded, even this error unwinds. Add the missing locking. Fixes: 7c11910783a1 ("RDMA/ucma: Put a lock around every call to the rdma_cm layer") Link: https://lore.kernel.org/r/20200818120526.702120-11-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 563b7336b72435054e79c42342a9547c423780b5 Author: Jason Gunthorpe Date: Tue Aug 18 15:05:21 2020 +0300 RDMA/ucma: Fix locking for ctx->events_reported [ Upstream commit 98837c6c3d7285f6eca86480b6f7fac6880e27a8 ] This value is locked under the file->mut, ensure it is held whenever touching it. The case in ucma_migrate_id() is a race, while in ucma_free_uctx() it is already not possible for the write side to run, the movement is just for clarity. Fixes: 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()") Link: https://lore.kernel.org/r/20200818120526.702120-10-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7db67e4c4bfa21d29cfade3337217b94543eaa82 Author: Colin Ian King Date: Thu Jul 16 15:38:56 2020 +0100 refperf: Avoid null pointer dereference when buf fails to allocate [ Upstream commit 58db5785b0d76be4582a32a7900acce88e691d36 ] Currently in the unlikely event that buf fails to be allocated it is dereferenced a few times. Use the errexit flag to determine if buf should be written to to avoid the null pointer dereferences. Addresses-Coverity: ("Dereference after null check") Fixes: f518f154ecef ("refperf: Dynamically allocate experiment-summary output buffer") Signed-off-by: Colin Ian King Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 937ec6b33f5754a1cc373c5c3267a4099e1e69d3 Author: Paul E. McKenney Date: Sun Jul 19 14:40:31 2020 -0700 rcutorture: Properly set rcu_fwds for OOM handling [ Upstream commit c8fa63714763b7795a3f5fb7ed6d000763e6dccc ] The conversion of rcu_fwds to dynamic allocation failed to actually allocate the required structure. This commit therefore allocates it, frees it, and updates rcu_fwds accordingly. While in the area, it abstracts the cleanup actions into rcu_torture_fwd_prog_cleanup(). Fixes: 5155be9994e5 ("rcutorture: Dynamically allocate rcu_fwds structure") Reported-by: kernel test robot Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 5844c57b8599c0fa15b95f4793f48987455c817b Author: Neeraj Upadhyay Date: Mon Jun 22 00:07:27 2020 +0530 rcu/tree: Force quiescent state on callback overload [ Upstream commit 9c39245382de4d52a122641952900709d4a9950b ] On callback overload, it is necessary to quickly detect idle CPUs, and rcu_gp_fqs_check_wake() checks for this condition. Unfortunately, the code following the call to this function does not repeat this check, which means that in reality no actual quiescent-state forcing, instead only a couple of quick and pointless wakeups at the beginning of the grace period. This commit therefore adds a check for the RCU_GP_FLAG_OVLD flag in the post-wakeup "if" statement in rcu_gp_fqs_loop(). Fixes: 1fca4d12f4637 ("rcu: Expedite first two FQS scans under callback-overload conditions") Reviewed-by: Joel Fernandes (Google) Signed-off-by: Neeraj Upadhyay Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit d0e231010e6c470a876e48decc9a083d57571d32 Author: Nicholas Mc Guire Date: Wed Jul 4 10:03:27 2018 +0200 powerpc/icp-hv: Fix missing of_node_put() in success path [ Upstream commit d3e669f31ec35856f5e85df9224ede5bdbf1bc7b ] Both of_find_compatible_node() and of_find_node_by_type() will return a refcounted node on success - thus for the success path the node must be explicitly released with a of_node_put(). Fixes: 0b05ac6e2480 ("powerpc/xics: Rewrite XICS driver") Signed-off-by: Nicholas Mc Guire Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1530691407-3991-1-git-send-email-hofrat@osadl.org Signed-off-by: Sasha Levin commit e16a3a250266417c70c4b2e21aae7fd81700ebf9 Author: Nicholas Mc Guire Date: Mon Jul 2 11:08:16 2018 +0200 powerpc/pseries: Fix missing of_node_put() in rng_init() [ Upstream commit 67c3e59443f5fc77be39e2ce0db75fbfa78c7965 ] The call to of_find_compatible_node() returns a node pointer with refcount incremented thus it must be explicitly decremented here before returning. Fixes: a489043f4626 ("powerpc/pseries: Implement arch_get_random_long() based on H_RANDOM") Signed-off-by: Nicholas Mc Guire Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1530522496-14816-1-git-send-email-hofrat@osadl.org Signed-off-by: Sasha Levin commit 0cfad48a00a7c2bc6de887a0b9822005eab10b6c Author: Håkon Bugge Date: Mon Aug 3 08:19:41 2020 +0200 IB/mlx4: Adjust delayed work when a dup is observed [ Upstream commit 785167a114855c5aa75efca97000e405c2cc85bf ] When scheduling delayed work to clean up the cache, if the entry already has been scheduled for deletion, we adjust the delay. Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization") Link: https://lore.kernel.org/r/20200803061941.1139994-7-haakon.bugge@oracle.com Signed-off-by: Håkon Bugge Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0625430d9f9f4e76c2395a9356a5f47c9c5aa5ac Author: Håkon Bugge Date: Mon Aug 3 08:19:39 2020 +0200 IB/mlx4: Fix starvation in paravirt mux/demux [ Upstream commit 7fd1507df7cee9c533f38152fcd1dd769fcac6ce ] The mlx4 driver will proxy MAD packets through the PF driver. A VM or an instantiated VF will send its MAD packets to the PF driver using loop-back. The PF driver will be informed by an interrupt, but defer the handling and polling of CQEs to a worker thread running on an ordered work-queue. Consider the following scenario: the VMs will in short proximity in time, for example due to a network event, send many MAD packets to the PF driver. Lets say there are K VMs, each sending N packets. The interrupt from the first VM will start the worker thread, which will poll N CQEs. A common case here is where the PF driver will multiplex the packets received from the VMs out on the wire QP. But before the wire QP has returned a send CQE and associated interrupt, the other K - 1 VMs have sent their N packets as well. The PF driver has to multiplex K * N packets out on the wire QP. But the send-queue on the wire QP has a finite capacity. So, in this scenario, if K * N is larger than the send-queue capacity of the wire QP, we will get MAD packets dropped on the floor with this dynamic debug message: mlx4_ib_multiplex_mad: failed sending GSI to wire on behalf of slave 2 (-11) and this despite the fact that the wire send-queue could have capacity, but the PF driver isn't aware, because the wire send CQEs have not yet been polled. We can also have a similar scenario inbound, with a wire recv-queue larger than the tunnel QP's send-queue. If many remote peers send MAD packets to the very same VM, the tunnel send-queue destined to the VM could allegedly be construed to be full by the PF driver. This starvation is fixed by introducing separate work queues for the wire QPs vs. the tunnel QPs. With this fix, using a dual ported HCA, 8 VFs instantiated, we could run cmtime on each of the 18 interfaces towards a similar configured peer, each cmtime instance with 800 QPs (all in all 14400 QPs) without a single CM packet getting lost. Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization") Link: https://lore.kernel.org/r/20200803061941.1139994-5-haakon.bugge@oracle.com Signed-off-by: Håkon Bugge Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 158a620c5219c16a323198e8039a6f3c5e20c5e5 Author: Parshuram Thombare Date: Thu May 21 11:32:22 2020 +0200 i3c: master add i3c_master_attach_boardinfo to preserve boardinfo [ Upstream commit 9da36a7ec42135428e1d41621e3703429bda3b2e ] Boardinfo was lost if I3C object for devices with boardinfo available are not created or not added to the I3C device list because of some failure e.g. SETDASA failed, retrieve info failed etc This patch adds i3c_master_attach_boardinfo which scan boardinfo list in the master object and 'attach' it to the I3C device object. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Parshuram Thombare Signed-off-by: Boris Brezillon Link: https://lore.kernel.org/linux-i3c/1590053542-389-1-git-send-email-pthombar@cadence.com Signed-off-by: Sasha Levin commit 9e68dd4af729d06f9ce214a0c2250c1593d2672d Author: Tom Zanussi Date: Tue Oct 13 09:17:57 2020 -0500 tracing: Handle synthetic event array field type checking correctly [ Upstream commit 10819e25799aae564005b6049a45e9808797b3bb ] Since synthetic event array types are derived from the field name, there may be a semicolon at the end of the type which should be stripped off. If there are more characters following that, normal type string checking will result in an invalid type. Without this patch, you can end up with an invalid field type string that gets displayed in both the synthetic event description and the event format: Before: # echo 'myevent char str[16]; int v' >> synthetic_events # cat synthetic_events myevent char[16]; str; int v name: myevent ID: 1936 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:char str[16];; offset:8; size:16; signed:1; field:int v; offset:40; size:4; signed:1; print fmt: "str=%s, v=%d", REC->str, REC->v After: # echo 'myevent char str[16]; int v' >> synthetic_events # cat synthetic_events myevent char[16] str; int v # cat events/synthetic/myevent/format name: myevent ID: 1936 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:char str[16]; offset:8; size:16; signed:1; field:int v; offset:40; size:4; signed:1; print fmt: "str=%s, v=%d", REC->str, REC->v Link: https://lkml.kernel.org/r/6587663b56c2d45ab9d8c8472a2110713cdec97d.1602598160.git.zanussi@kernel.org [ : wrote parse_synth_field() snippet. ] Fixes: 4b147936fa50 (tracing: Add support for 'synthetic' events) Reported-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 8413ca8e50a48dc00536881bba14258c9a5659ad Author: Tom Zanussi Date: Tue Oct 13 09:17:56 2020 -0500 selftests/ftrace: Change synthetic event name for inter-event-combined test [ Upstream commit 96378b2088faea68f1fb05ea6b9a566fc569a44c ] This test uses waking+wakeup_latency as an event name, which doesn't make sense since it includes an operator. Illegal names are now detected by the synthetic event command parsing, which causes this test to fail. Change the name to 'waking_plus_wakeup_latency' to prevent this. Link: https://lkml.kernel.org/r/a1ee2f76ff28ef7166fb788ca8be968887808920.1602598160.git.zanussi@kernel.org Fixes: f06eec4d0f2c (selftests: ftrace: Add inter-event hist triggers testcases) Acked-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 9bd6d3879f832d1fb4c01e19a63c1eaedb5a173d Author: Andrii Nakryiko Date: Wed Oct 14 13:45:28 2020 -0700 fs: fix NULL dereference due to data race in prepend_path() [ Upstream commit 09cad07547445bf3a41683e4d3abcd154c123ef5 ] Fix data race in prepend_path() with re-reading mnt->mnt_ns twice without holding the lock. is_mounted() does check for NULL, but is_anon_ns(mnt->mnt_ns) might re-read the pointer again which could be NULL already, if in between reads one of kern_unmount()/kern_unmount_array()/umount_tree() sets mnt->mnt_ns to NULL. This is seen in production with the following stack trace: BUG: kernel NULL pointer dereference, address: 0000000000000048 ... RIP: 0010:prepend_path.isra.4+0x1ce/0x2e0 Call Trace: d_path+0xe6/0x150 proc_pid_readlink+0x8f/0x100 vfs_readlink+0xf8/0x110 do_readlinkat+0xfd/0x120 __x64_sys_readlinkat+0x1a/0x20 do_syscall_64+0x42/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: f2683bd8d5bd ("[PATCH] fix d_absolute_path() interplay with fsmount()") Signed-off-by: Andrii Nakryiko Reviewed-by: Josef Bacik Cc: Alexander Viro Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c3781a532003cfe3cb8638c3e40e57d0e72b01d5 Author: Suren Baghdasaryan Date: Tue Oct 13 16:58:35 2020 -0700 mm, oom_adj: don't loop through tasks in __set_oom_adj when not necessary [ Upstream commit 67197a4f28d28d0b073ab0427b03cb2ee5382578 ] Currently __set_oom_adj loops through all processes in the system to keep oom_score_adj and oom_score_adj_min in sync between processes sharing their mm. This is done for any task with more that one mm_users, which includes processes with multiple threads (sharing mm and signals). However for such processes the loop is unnecessary because their signal structure is shared as well. Android updates oom_score_adj whenever a tasks changes its role (background/foreground/...) or binds to/unbinds from a service, making it more/less important. Such operation can happen frequently. We noticed that updates to oom_score_adj became more expensive and after further investigation found out that the patch mentioned in "Fixes" introduced a regression. Using Pixel 4 with a typical Android workload, write time to oom_score_adj increased from ~3.57us to ~362us. Moreover this regression linearly depends on the number of multi-threaded processes running on the system. Mark the mm with a new MMF_MULTIPROCESS flag bit when task is created with (CLONE_VM && !CLONE_THREAD && !CLONE_VFORK). Change __set_oom_adj to use MMF_MULTIPROCESS instead of mm_users to decide whether oom_score_adj update should be synchronized between multiple processes. To prevent races between clone() and __set_oom_adj(), when oom_score_adj of the process being cloned might be modified from userspace, we use oom_adj_mutex. Its scope is changed to global. The combination of (CLONE_VM && !CLONE_THREAD) is rarely used except for the case of vfork(). To prevent performance regressions of vfork(), we skip taking oom_adj_mutex and setting MMF_MULTIPROCESS when CLONE_VFORK is specified. Clearing the MMF_MULTIPROCESS flag (when the last process sharing the mm exits) is left out of this patch to keep it simple and because it is believed that this threading model is rare. Should there ever be a need for optimizing that case as well, it can be done by hooking into the exit path, likely following the mm_update_next_owner pattern. With the combination of (CLONE_VM && !CLONE_THREAD && !CLONE_VFORK) being quite rare, the regression is gone after the change is applied. [surenb@google.com: v3] Link: https://lkml.kernel.org/r/20200902012558.2335613-1-surenb@google.com Fixes: 44a70adec910 ("mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj") Reported-by: Tim Murray Suggested-by: Michal Hocko Signed-off-by: Suren Baghdasaryan Signed-off-by: Andrew Morton Acked-by: Christian Brauner Acked-by: Michal Hocko Acked-by: Oleg Nesterov Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Eugene Syromiatnikov Cc: Christian Kellner Cc: Adrian Reber Cc: Shakeel Butt Cc: Aleksa Sarai Cc: Alexey Dobriyan Cc: "Eric W. Biederman" Cc: Alexey Gladkov Cc: Michel Lespinasse Cc: Daniel Jordan Cc: Andrei Vagin Cc: Bernd Edlinger Cc: John Johansen Cc: Yafang Shao Link: https://lkml.kernel.org/r/20200824153036.3201505-1-surenb@google.com Debugged-by: Minchan Kim Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 830b103831a924a23af48562c4d274696e75ab4f Author: Matthew Wilcox (Oracle) Date: Tue Oct 13 16:56:04 2020 -0700 mm/page_alloc.c: fix freeing non-compound pages [ Upstream commit e320d3012d25b1fb5f3df4edb7bd44a1c362ec10 ] Here is a very rare race which leaks memory: Page P0 is allocated to the page cache. Page P1 is free. Thread A Thread B Thread C find_get_entry(): xas_load() returns P0 Removes P0 from page cache P0 finds its buddy P1 alloc_pages(GFP_KERNEL, 1) returns P0 P0 has refcount 1 page_cache_get_speculative(P0) P0 has refcount 2 __free_pages(P0) P0 has refcount 1 put_page(P0) P1 is not freed Fix this by freeing all the pages in __free_pages() that won't be freed by the call to put_page(). It's usually not a good idea to split a page, but this is a very unlikely scenario. Fixes: e286781d5f2e ("mm: speculative page references") Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Andrew Morton Acked-by: Mike Rapoport Cc: Nick Piggin Cc: Hugh Dickins Cc: Peter Zijlstra Link: https://lkml.kernel.org/r/20200926213919.26642-1-willy@infradead.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 85e9a7178dee7db805c29a85cc7fd32f00c30074 Author: Liao Pingfang Date: Tue Oct 13 16:54:18 2020 -0700 mm/mmap.c: replace do_brk with do_brk_flags in comment of insert_vm_struct() [ Upstream commit 8332326e8e47fbc35711433419c31f610153dd58 ] Replace do_brk with do_brk_flags in comment of insert_vm_struct(), since do_brk was removed in following commit. Fixes: bb177a732c4369 ("mm: do not bug_on on incorrect length in __mm_populate()") Signed-off-by: Liao Pingfang Signed-off-by: Yi Wang Signed-off-by: Andrew Morton Link: https://lkml.kernel.org/r/1600650778-43230-1-git-send-email-wang.yi59@zte.com.cn Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 039f056a67580e70364c928059ece257a653ebf1 Author: Ralph Campbell Date: Tue Oct 13 16:53:13 2020 -0700 mm/memcg: fix device private memcg accounting [ Upstream commit 9a137153fc8798a89d8fce895cd0a06ea5b8e37c ] The code in mc_handle_swap_pte() checks for non_swap_entry() and returns NULL before checking is_device_private_entry() so device private pages are never handled. Fix this by checking for non_swap_entry() after handling device private swap PTEs. I assume the memory cgroup accounting would be off somehow when moving a process to another memory cgroup. Currently, the device private page is charged like a normal anonymous page when allocated and is uncharged when the page is freed so I think that path is OK. Signed-off-by: Ralph Campbell Signed-off-by: Andrew Morton Acked-by: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Jerome Glisse Cc: Balbir Singh Cc: Ira Weiny Link: https://lkml.kernel.org/r/20201009215952.2726-1-rcampbell@nvidia.com xFixes: c733a82874a7 ("mm/memcontrol: support MEMORY_DEVICE_PRIVATE") Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2dec22a368efbc4fac45260adb72d1a99b5381bb Author: Roman Gushchin Date: Tue Oct 13 16:52:42 2020 -0700 mm: memcg/slab: fix racy access to page->mem_cgroup in mem_cgroup_from_obj() [ Upstream commit 19b629c9795bfe67bf77be8fb611b84424b56d91 ] mem_cgroup_from_obj() checks the lowest bit of the page->mem_cgroup pointer to determine if the page has an attached obj_cgroup vector instead of a regular memcg pointer. If it's not set, it simple returns the page->mem_cgroup value as a struct mem_cgroup pointer. The commit 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all allocations") changed the moment when this bit is set: if previously it was set on the allocation of the slab page, now it can be set well after, when the first accounted object is allocated on this page. It opened a race: if page->mem_cgroup is set concurrently after the first page_has_obj_cgroups(page) check, a pointer to the obj_cgroups array can be returned as a memory cgroup pointer. A simple check for page->mem_cgroup pointer for NULL before the page_has_obj_cgroups() check fixes the race. Indeed, if the pointer is not NULL, it's either a simple mem_cgroup pointer or a pointer to obj_cgroup vector. The pointer can be asynchronously changed from NULL to (obj_cgroup_vec | 0x1UL), but can't be changed from a valid memcg pointer to objcg vector or back. If the object passed to mem_cgroup_from_obj() is a slab object and page->mem_cgroup is NULL, it means that the object is not accounted, so the function must return NULL. I've discovered the race looking at the code, so far I haven't seen it in the wild. Fixes: 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all allocations") Signed-off-by: Roman Gushchin Signed-off-by: Andrew Morton Reviewed-by: Shakeel Butt Cc: Johannes Weiner Cc: Vlastimil Babka Link: https://lkml.kernel.org/r/20200910022435.2773735-1-guro@fb.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a46f479cb4bf4ea436be422b04354a963601c1a3 Author: Miaohe Lin Date: Tue Oct 13 16:52:30 2020 -0700 mm/swapfile.c: fix potential memory leak in sys_swapon [ Upstream commit 822bca52ee7eb279acfba261a423ed7ac47d6f73 ] If we failed to drain inode, we would forget to free the swap address space allocated by init_swap_address_space() above. Fixes: dc617f29dbe5 ("vfs: don't allow writes to swap files") Signed-off-by: Miaohe Lin Signed-off-by: Andrew Morton Reviewed-by: Darrick J. Wong Link: https://lkml.kernel.org/r/20200930101803.53884-1-linmiaohe@huawei.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1c84a2a57dee4581628943f16c0da5842b4960d1 Author: Pablo Neira Ayuso Date: Mon Oct 12 17:06:06 2020 +0200 netfilter: nf_log: missing vlan offload tag and proto [ Upstream commit 0d9826bc18ce356e8909919ad681ad65d0a6061e ] Dump vlan tag and proto for the usual vlan offload case if the NF_LOG_MACDECODE flag is set on. Without this information the logging is misleading as there is no reference to the VLAN header. [12716.993704] test: IN=veth0 OUT= MACSRC=86:6c:92:ea:d6:73 MACDST=0e:3b:eb:86:73:76 VPROTO=8100 VID=10 MACPROTO=0800 SRC=192.168.10.2 DST=172.217.168.163 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2548 DF PROTO=TCP SPT=55848 DPT=80 WINDOW=501 RES=0x00 ACK FIN URGP=0 [12721.157643] test: IN=veth0 OUT= MACSRC=86:6c:92:ea:d6:73 MACDST=0e:3b:eb:86:73:76 VPROTO=8100 VID=10 MACPROTO=0806 ARP HTYPE=1 PTYPE=0x0800 OPCODE=2 MACSRC=86:6c:92:ea:d6:73 IPSRC=192.168.10.2 MACDST=0e:3b:eb:86:73:76 IPDST=192.168.10.1 Fixes: 83e96d443b37 ("netfilter: log: split family specific code to nf_log_{ip,ip6,common}.c files") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 41e6d802fa94b1855b67711640bae42e49180590 Author: Valentin Vidic Date: Mon Oct 12 00:03:29 2020 +0200 net: korina: fix kfree of rx/tx descriptor array [ Upstream commit 3af5f0f5c74ecbaf757ef06c3f80d56751277637 ] kmalloc returns KSEG0 addresses so convert back from KSEG1 in kfree. Also make sure array is freed when the driver is unloaded from the kernel. Fixes: ef11291bcd5f ("Add support the Korina (IDT RC32434) Ethernet MAC") Signed-off-by: Valentin Vidic Acked-by: Willem de Bruijn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b727cbf19c243e100953f47a966db252dd68776c Author: John Fastabend Date: Fri Oct 9 11:37:35 2020 -0700 bpf, sockmap: Remove skb_orphan and let normal skb_kfree do cleanup [ Upstream commit 10d58d006356a075a7b056e0f6502db416d1a261 ] Calling skb_orphan() is unnecessary in the strp rcv handler because the skb is from a skb_clone() in __strp_recv. So it never has a destructor or a sk assigned. Plus its confusing to read because it might hint to the reader that the skb could have an sk assigned which is not true. Even if we did have an sk assigned it would be cleaner to simply wait for the upcoming kfree_skb(). Additionally, move the comment about strparser clone up so its closer to the logic it is describing and add to it so that it is more complete. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: John Fastabend Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/160226865548.5692.9098315689984599579.stgit@john-Precision-5820-Tower Signed-off-by: Sasha Levin commit a16f0f41591ecac3d57856b601a417957aee2851 Author: Julian Anastasov Date: Fri Oct 9 21:24:25 2020 +0300 ipvs: clear skb->tstamp in forwarding path [ Upstream commit 7980d2eabde82be86c5be18aa3d07e88ec13c6a1 ] fq qdisc requires tstamp to be cleared in forwarding path Reported-by: Evgeny B Link: https://bugzilla.kernel.org/show_bug.cgi?id=209427 Suggested-by: Eric Dumazet Fixes: 8203e2d844d3 ("net: clear skb->tstamp in forwarding paths") Fixes: fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC") Fixes: 80b14dee2bea ("net: Add a new socket option for a future transmit time.") Signed-off-by: Julian Anastasov Reviewed-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d9bafcae633273d52695903b7dbdb713f7f8e259 Author: Ye Bin Date: Fri Oct 9 15:42:18 2020 +0800 drm/amdgpu: Fix invalid number of character '{' in amdgpu_acpi_init [ Upstream commit 9c27bc97aff8bbe62b5b29ebf528291dd85d9c86 ] Fix follow warning: Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: ''. Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: CONFIG_ACPI... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: 'CONFIG_ACPI'. ...... Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: CONFIG_X86... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: 'CONFIG_X86'. Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: _X86_... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: '_X86_'. Checking drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: __linux__... [drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:770]: (error) Invalid number of character '{' when these macros are defined: '__linux__'. Fixes: 97d798b276e9 ("drm/amdgpu: simplify ATIF backlight handling") Reported-by: Hulk Robot Signed-off-by: Ye Bin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 98ac13920648bfa6a4c4b751206b2a5ef442ba5d Author: Christian Hewitt Date: Thu Oct 8 14:17:38 2020 +0000 drm/panfrost: increase readl_relaxed_poll_timeout values [ Upstream commit c2df75ad2a9f205820e4bc0db936d3d9af3da1ae ] Amlogic SoC devices report the following errors frequently causing excessive dmesg log spam and early log rotataion, although the errors appear to be harmless as everything works fine: [ 7.202702] panfrost ffe40000.gpu: error powering up gpu L2 [ 7.203760] panfrost ffe40000.gpu: error powering up gpu shader ARM staff have advised increasing the timeout values to eliminate the errors in most normal scenarios, and testing with several different G31/G52 devices shows 20000 to be a reliable value. Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Suggested-by: Steven Price Signed-off-by: Christian Hewitt Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20201008141738.13560-1-christianshewitt@gmail.com Signed-off-by: Sasha Levin commit 9bbb3b60905039f76aea8c2d4a515cf819bcebeb Author: Tom Rix Date: Sun Oct 4 06:19:31 2020 -0700 mwifiex: fix double free [ Upstream commit 53708f4fd9cfe389beab5c8daa763bcd0e0b4aef ] clang static analysis reports this problem: sdio.c:2403:3: warning: Attempt to free released memory kfree(card->mpa_rx.buf); ^~~~~~~~~~~~~~~~~~~~~~~ When mwifiex_init_sdio() fails in its first call to mwifiex_alloc_sdio_mpa_buffer, it falls back to calling it again. If the second alloc of mpa_tx.buf fails, the error handler will try to free the old, previously freed mpa_rx.buf. Reviewing the code, it looks like a second double free would happen with mwifiex_cleanup_sdio(). So set both pointers to NULL when they are freed. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Tom Rix Reviewed-by: Brian Norris Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201004131931.29782-1-trix@redhat.com Signed-off-by: Sasha Levin commit cf5de1f99e7d419f9187688a082a4fd98d2cac56 Author: Mike Snitzer Date: Wed Oct 7 16:41:01 2020 -0400 dm: fix request-based DM to not bounce through indirect dm_submit_bio [ Upstream commit 681cc5e8667e8579a2da8fa4090c48a2d73fc3bb ] It is unnecessary to force request-based DM to call into bio-based dm_submit_bio (via indirect disk->fops->submit_bio) only to have it then call blk_mq_submit_bio(). Fix this by establishing a request-based DM block_device_operations (dm_rq_blk_dops, which doesn't have .submit_bio) and update dm_setup_md_queue() to set md->disk->fops to it for DM_TYPE_REQUEST_BASED. Remove DM_TYPE_REQUEST_BASED conditional in dm_submit_bio and unexport blk_mq_submit_bio. Fixes: c62b37d96b6eb ("block: move ->make_request_fn to struct block_device_operations") Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 218561509bdd6cb252743ec644b33185d192ecf5 Author: Vadim Pasternak Date: Wed Sep 23 20:20:49 2020 +0300 platform/x86: mlx-platform: Remove PSU EEPROM configuration [ Upstream commit c071afcea6ecf24a3c119f25ce9f71ffd55b5dc2 ] Remove PSU EEPROM configuration for systems class equipped with Mellanox chip Spectrume-2. Till now all the systems from this class used few types of power units, all equipped with EEPROM device with address space two bytes. Thus, all these devices have been handled by EEPROM driver "24c32". There is a new requirement is to support power unit replacement by "off the shelf" device, matching electrical required parameters. Such device could be equipped with different EEPROM type, which could be one byte address space addressing or even could be not equipped with EEPROM. In such case "24c32" will not work. Fixes: 1bd42d94ccab ("platform/x86: mlx-platform: Add support for new 200G IB and Ethernet systems") Signed-off-by: Vadim Pasternak Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20200923172053.26296-2-vadimp@nvidia.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 73bd7d6496edf9cc75023b6b512d09a8d38eef00 Author: Jérôme Pouiller Date: Wed Oct 7 12:19:39 2020 +0200 staging: wfx: fix BA sessions for older firmwares [ Upstream commit 4fd1241778b08129f196605c62636a4d6d71c2c7 ] Firmwares with API < 3.6 do not forward DELBA requests. Thus, when a Block Ack session is restarted, the reordering buffer is not flushed and the received sequence number is not contiguous. Therefore, mac80211 starts to wait some missing frames that it will never receive. This patch disables the reordering buffer for old firmware. It is harmless when the network is unencrypted. When the network is encrypted, the non-contiguous frames will be thrown away by the TKIP/CCMP replay protection. So, the user will observe some packet loss with UDP and performance drop with TCP. Fixes: e5da5fbd7741 ("staging: wfx: fix CCMP/TKIP replay protection") Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20201007101943.749898-4-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 47c5823eb7eece2cb5ab3ad463d2b5ba527c275c Author: Tzung-Bi Shih Date: Tue Oct 6 18:12:52 2020 +0800 ASoC: mediatek: mt8183-da7219: fix wrong ops for I2S3 [ Upstream commit ebb11d1d9fe2d6b4a47755f7f09b2b631046e308 ] DA7219 uses I2S2 and I2S3 for input and output respectively. Commit 9e30251fb22e ("ASoC: mediatek: mt8183-da7219: support machine driver with rt1015") introduces a bug that: - If using I2S2 solely, MCLK to DA7219 is 256FS. - If using I2S3 solely, MCLK to DA7219 is 128FS. - If using I2S3 first and then I2S2, the MCLK changes from 128FS to 256FS. As a result, no sound output to the headset. Also no sound input from the headset microphone. Both I2S2 and I2S3 should set MCLK to 256FS. Fixes the wrong ops for I2S3. Fixes: 9e30251fb22e ("ASoC: mediatek: mt8183-da7219: support machine driver with rt1015") Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20201006101252.1890385-1-tzungbi@google.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fd8f1c21c07b6f513366d853d4ee03b7115f6af3 Author: Tom Zanussi Date: Sun Oct 4 17:14:04 2020 -0500 tracing: Fix parse_synth_field() error handling [ Upstream commit 8fbeb52a598c7ab5aa603d6bb083b8a8d16d607a ] synth_field_size() returns either a positive size or an error (zero or a negative value). However, the existing code assumes the only error value is 0. It doesn't handle negative error codes, as it assigns directly to field->size (a size_t; unsigned), thereby interpreting the error code as a valid size instead. Do the test before assignment to field->size. [ axelrasmussen@google.com: changelog addition, first paragraph above ] Link: https://lkml.kernel.org/r/9b6946d9776b2eeb43227678158196de1c3c6e1d.1601848695.git.zanussi@kernel.org Fixes: 4b147936fa50 (tracing: Add support for 'synthetic' events) Reviewed-by: Masami Hiramatsu Tested-by: Axel Rasmussen Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit a0c7850e7e78f38836745250512759ed5fbf00a1 Author: Tianjia Zhang Date: Mon Oct 5 22:52:12 2020 +0800 ipmi_si: Fix wrong return value in try_smi_init() [ Upstream commit 8fe7990ceda8597e407d06bffc4bdbe835a93ece ] On an error exit path, a negative error code should be returned instead of a positive return value. Fixes: 90b2d4f15ff7 ("ipmi_si: Remove hacks for adding a dummy platform devices") Cc: Corey Minyard Signed-off-by: Tianjia Zhang Message-Id: <20201005145212.84435-1-tianjia.zhang@linux.alibaba.com> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit baae5a38fe86b4f5ffe3bd7116863a66b0ac013f Author: Coiby Xu Date: Sat Oct 3 07:59:41 2020 +0800 staging: qlge: fix build breakage with dumping enabled [ Upstream commit 51c00535537018bddd4b3fb225d18c1ae049c4e9 ] This fixes commit 0107635e15ac ("staging: qlge: replace pr_err with netdev_err") which introduced an build breakage of missing `struct ql_adapter *qdev` for some functions and a warning of type mismatch with dumping enabled, i.e., $ make CFLAGS_MODULE="-DQL_ALL_DUMP -DQL_OB_DUMP -DQL_CB_DUMP \ -DQL_IB_DUMP -DQL_REG_DUMP -DQL_DEV_DUMP" M=drivers/staging/qlge qlge_dbg.c: In function ‘ql_dump_ob_mac_rsp’: qlge_dbg.c:2051:13: error: ‘qdev’ undeclared (first use in this function); did you mean ‘cdev’? 2051 | netdev_err(qdev->ndev, "%s\n", __func__); | ^~~~ qlge_dbg.c: In function ‘ql_dump_routing_entries’: qlge_dbg.c:1435:10: warning: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘int’ [-Wformat=] 1435 | "%s: Routing Mask %d = 0x%.08x\n", | ~^ | | | char * | %d 1436 | i, value); | ~ | | | int qlge_dbg.c:1435:37: warning: format ‘%x’ expects a matching ‘unsigned int’ argument [-Wformat=] 1435 | "%s: Routing Mask %d = 0x%.08x\n", | ~~~~^ | | | unsigned int Note that now ql_dump_rx_ring/ql_dump_tx_ring won't check if the passed parameter is a null pointer. Fixes: 0107635e15ac ("staging: qlge: replace pr_err with netdev_err") Reported-by: Benjamin Poirier Suggested-by: Benjamin Poirier Reviewed-by: Benjamin Poirier Signed-off-by: Coiby Xu Link: https://lore.kernel.org/r/20201002235941.77062-1-coiby.xu@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b9e116dac7c3748b1062267e2b19c9e01226caec Author: Logan Gunthorpe Date: Tue Sep 22 14:08:44 2020 -0600 dmaengine: ioat: Allocate correct size for descriptor chunk [ Upstream commit 028926e4ac8f21af343c25794117fd13c08b1712 ] dma_alloc_coherent() is called with a fixed SZ_2M size, but frees happen with IOAT_CHUNK_SIZE. Recently, IOAT_CHUNK_SIZE was reduced to 512M but the allocation did not change. To fix, change to using the IOAT_CHUNK_SIZE define. This was caught with the upcoming patchset for converting Intel platforms to the dma-iommu implementation. It has a warning when the unmapped size differs from the mapped size. Fixes: a02254f8a676 ("dmaengine: ioat: Decreasing allocation chunk size 2M->512K") Suggested-by: Robin Murphy Signed-off-by: Logan Gunthorpe Acked-by: Dave Jiang Cc: Vinod Koul Cc: Dave Jiang Cc: Dan Williams Link: https://lore.kernel.org/intel-gfx/776771a2-247a-d1be-d882-bee02d919ae0@deltatee.com/ Link: https://lore.kernel.org/r/20200922200844.2982-1-logang@deltatee.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit cb9b5eb29ae7f11f7ae7c62839937a2a79593518 Author: Dan Carpenter Date: Mon Sep 28 12:13:00 2020 +0300 scsi: be2iscsi: Fix a theoretical leak in beiscsi_create_eqs() [ Upstream commit 38b2db564d9ab7797192ef15d7aade30633ceeae ] The be_fill_queue() function can only fail when "eq_vaddress" is NULL and since it's non-NULL here that means the function call can't fail. But imagine if it could, then in that situation we would want to store the "paddr" so that dma memory can be released. Link: https://lore.kernel.org/r/20200928091300.GD377727@mwanda Fixes: bfead3b2cb46 ("[SCSI] be2iscsi: Adding msix and mcc_rings V3") Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 65353a314fb993fad3e8a0210b040d59d4193e4a Author: John Donnelly Date: Wed Sep 23 17:19:20 2020 -0700 scsi: target: tcmu: Fix warning: 'page' may be used uninitialized [ Upstream commit 61741d8699e1fc764a309ebd20211bb1cb193110 ] Corrects drivers/target/target_core_user.c:688:6: warning: 'page' may be used uninitialized. Link: https://lore.kernel.org/r/20200924001920.43594-1-john.p.donnelly@oracle.com Fixes: 3c58f737231e ("scsi: target: tcmu: Optimize use of flush_dcache_page") Cc: Mike Christie Acked-by: Mike Christie Signed-off-by: John Donnelly Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ae76fcc3a3673dff5758b38803f01438d3048731 Author: Minas Harutyunyan Date: Thu Sep 24 18:08:39 2020 +0400 usb: dwc2: Fix INTR OUT transfers in DDMA mode. [ Upstream commit b2c586eb07efab982419f32b7c3bd96829bc8bcd ] In DDMA mode if INTR OUT transfers mps not multiple of 4 then single packet corresponds to single descriptor. Descriptor limit set to mps and desc chain limit set to mps * MAX_DMA_DESC_NUM_GENERIC. On that descriptors complete, to calculate transfer size should be considered correction value for each descriptor. In start request function, if "continue" is true then dma buffer address should be incremmented by offset for all type of transfers, not only for Control DATA_OUT transfers. Fixes: cf77b5fb9b394 ("usb: dwc2: gadget: Transfer length limit checking for DDMA") Fixes: e02f9aa6119e0 ("usb: dwc2: gadget: EP 0 specific DDMA programming") Fixes: aa3e8bc81311e ("usb: dwc2: gadget: DDMA transfer start and complete") Signed-off-by: Minas Harutyunyan Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 60ef5d46745bb3b893349eb7941951e7355c25ef Author: Johannes Berg Date: Mon Sep 28 13:07:18 2020 +0200 nl80211: fix non-split wiphy information [ Upstream commit ab10c22bc3b2024f0c9eafa463899a071eac8d97 ] When dumping wiphy information, we try to split the data into many submessages, but for old userspace we still support the old mode where this doesn't happen. However, in this case we were not resetting our state correctly and dumping multiple messages for each wiphy, which would have broken such older userspace. This was broken pretty much immediately afterwards because it only worked in the original commit where non-split dumps didn't have any more data than split dumps... Fixes: fe1abafd942f ("nl80211: re-add channel width and extended capa advertising") Signed-off-by: Johannes Berg Link: https://lore.kernel.org/r/20200928130717.3e6d9c6bada2.Ie0f151a8d0d00a8e1e18f6a8c9244dd02496af67@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a9c6d4e7c94d02155c2dadf41bcfa393ee058d20 Author: Necip Fazil Yildiran Date: Fri Sep 18 12:41:49 2020 +0300 ocxl: fix kconfig dependency warning for OCXL [ Upstream commit 4b53a3c72116118d86fab4112277e1dc4edf273c ] When OCXL is enabled and HOTPLUG_PCI is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for HOTPLUG_PCI_POWERNV Depends on [n]: PCI [=y] && HOTPLUG_PCI [=n] && PPC_POWERNV [=y] && EEH [=y] Selected by [y]: - OCXL [=y] && PPC_POWERNV [=y] && PCI [=y] && EEH [=y] The reason is that OCXL selects HOTPLUG_PCI_POWERNV without depending on or selecting HOTPLUG_PCI while HOTPLUG_PCI_POWERNV is subordinate to HOTPLUG_PCI. HOTPLUG_PCI_POWERNV is a visible symbol with a set of dependencies. Selecting it will lead to overlooking its other dependencies as well. Let OCXL depend on HOTPLUG_PCI_POWERNV instead to avoid Kbuild issues. Fixes: 49ce94b8677c ("ocxl: Add PCI hotplug dependency to Kconfig") Acked-by: Frederic Barrat Signed-off-by: Necip Fazil Yildiran Link: https://lore.kernel.org/r/20200918094148.20525-1-fazilyildiran@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 61bde8606b31cdef4de4d679f4ada7d4632bc6d2 Author: Manivannan Sadhasivam Date: Tue Sep 29 23:22:17 2020 +0530 bus: mhi: core: Fix the building of MHI module [ Upstream commit 5fc4997fd9d065c98fb312ef56ffadffccc6d61d ] The Kbuild rule to build MHI should use the append operator. This fixes the below warning reported by Kbuild test bot. WARNING: modpost: missing MODULE_LICENSE() in drivers/bus/mhi/core/main.o WARNING: modpost: missing MODULE_LICENSE() in drivers/bus/mhi/core/pm.o WARNING: modpost: missing MODULE_LICENSE() in drivers/bus/mhi/core/boot.o Fixes: 0cbf260820fa ("bus: mhi: core: Add support for registering MHI controllers") Reported-by: kernel test robot Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20200929175218.8178-19-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c870551d3d1df5ef486d3e026daa6dfb31da98bb Author: Lorenzo Colitti Date: Wed Aug 19 01:19:49 2020 +0900 usb: gadget: u_ether: enable qmult on SuperSpeed Plus as well [ Upstream commit 4eea21dc67b0c6ba15ae41b1defa113a680a858e ] The u_ether driver has a qmult setting that multiplies the transmit queue length (which by default is 2). The intent is that it should be enabled at high/super speed, but because the code does not explicitly check for USB_SUPER_PLUS, it is disabled at that speed. Fix this by ensuring that the queue multiplier is enabled for any wired link at high speed or above. Using >= for USB_SPEED_* constants seems correct because it is what the gadget_is_xxxspeed functions do. The queue multiplier substantially helps performance at higher speeds. On a direct SuperSpeed Plus link to a Linux laptop, iperf3 single TCP stream: Before (qmult=1): 1.3 Gbps After (qmult=5): 3.2 Gbps Fixes: 04617db7aa68 ("usb: gadget: add SS descriptors to Ethernet gadget") Reviewed-by: Maciej Żenczykowski Signed-off-by: Lorenzo Colitti Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit c7436c5d5ed4a55f4a5138e01f7a38ed674ef1da Author: Yoshihiro Shimoda Date: Wed Sep 9 09:01:32 2020 +0900 usb: gadget: u_serial: clear suspended flag when disconnecting [ Upstream commit d98ef43bfb65b5201e1afe36aaf8c4f9d71b4307 ] The commit aba3a8d01d62 ("usb: gadget: u_serial: add suspend resume callbacks") set/cleared the suspended flag in USB bus suspend/resume only. But, when a USB cable is disconnected in the suspend, since some controllers will not detect USB bus resume, the suspended flag is not cleared. After that, user cannot send any data. To fix the issue, clears the suspended flag in the gserial_disconnect(). Fixes: aba3a8d01d62 ("usb: gadget: u_serial: add suspend resume callbacks") Signed-off-by: Yoshihiro Shimoda Tested-by: Linh Phung Tested-by: Tam Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 2f7dd308ea834017d5cc444c5207037ee0bd0b06 Author: Lorenzo Colitti Date: Tue Aug 25 14:55:03 2020 +0900 usb: gadget: f_ncm: fix ncm_bitrate for SuperSpeed and above. [ Upstream commit 986499b1569af980a819817f17238015b27793f6 ] Currently, SuperSpeed NCM gadgets report a speed of 851 Mbps in USB_CDC_NOTIFY_SPEED_CHANGE. But the calculation appears to assume 16 packets per microframe, and USB 3 and above no longer use microframes. Maximum speed is actually much higher. On a direct connection, theoretical throughput is at most 3.86 Gbps for gen1x1 and 9.36 Gbps for gen2x1, and I have seen gadget->host iperf throughput of >2 Gbps for gen1x1 and >4 Gbps for gen2x1. Unfortunately the ConnectionSpeedChange defined in the CDC spec only uses 32-bit values, so we can't report accurate numbers for 10Gbps and above. So, report 3.75Gbps for SuperSpeed (which is roughly maximum theoretical performance) and 4.25Gbps for SuperSpeed Plus (which is close to the maximum that we can report in a 32-bit unsigned integer). This results in: [50879.191272] cdc_ncm 2-2:1.0 enx228b127e050c: renamed from usb0 [50879.234778] cdc_ncm 2-2:1.0 enx228b127e050c: 3750 mbit/s downlink 3750 mbit/s uplink on SuperSpeed and: [50798.434527] cdc_ncm 8-2:1.0 enx228b127e050c: renamed from usb0 [50798.524278] cdc_ncm 8-2:1.0 enx228b127e050c: 4250 mbit/s downlink 4250 mbit/s uplink on SuperSpeed Plus. Fixes: 1650113888fe ("usb: gadget: f_ncm: add SuperSpeed descriptors for CDC NCM") Reviewed-by: Maciej Żenczykowski Signed-off-by: Lorenzo Colitti Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit d292ddfdf238f700a2af7af74a5cd832c05b0621 Author: Mordechay Goodstein Date: Wed Sep 30 16:31:21 2020 +0300 iwlwifi: dbg: run init_cfg function once per driver load [ Upstream commit 42f8a2735cc218b6b372134684d4cd3c1423f123 ] Every time we call init_cfg driver appends the enabled triggers to the active triggers while this should be done only once per driver load. Signed-off-by: Mordechay Goodstein Fixes: 14124b25780d ("iwlwifi: dbg_ini: implement monitor allocation flow") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20200930161256.79bd622e604a.Ie0f79d2ea90ca5cdf363f56194ead81b0a2c6202@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit dce2d6db85254f26d7bb1c1cb314e11c469c7267 Author: Mordechay Goodstein Date: Wed Sep 30 16:31:19 2020 +0300 iwlwifi: dbg: remove no filter condition [ Upstream commit bfdb157127dab2a85d4096a68a00ad568c9eb590 ] Currently if group-id and command-id values are zero we trigger and collect every RX frame, this is not the right behavior and zero value should be handled like any other filter. Signed-off-by: Mordechay Goodstein Fixes: 3ed34fbf9d3b ("iwlwifi: dbg_ini: support FW response/notification region type") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20200930161256.6a0aae2c0507.I7bd72968279d586af420472707d53106b35efc08@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 9f3a603694c21cac4ec568515d4631621128f42b Author: Emmanuel Grumbach Date: Wed Sep 30 10:31:20 2020 +0300 iwlwifi: mvm: split a print to avoid a WARNING in ROC [ Upstream commit 903b3f9badf1d54f77b468b96706dab679b45b14 ] A print in the remain on channel code was too long and caused a WARNING, split it. Signed-off-by: Emmanuel Grumbach Fixes: dc28e12f2125 ("iwlwifi: mvm: ROC: Extend the ROC max delay duration & limit ROC duration") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20200930102759.58d57c0bdc68.Ib06008665e7bf1199c360aa92691d9c74fb84990@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit e0372ee0a6e478dd83b72ed3a0a15c93711fe1e4 Author: Adam Brickman Date: Thu Oct 1 16:24:25 2020 +0100 ASoC: wm_adsp: Pass full name to snd_ctl_notify [ Upstream commit 20441614d89867142060d3bcd79cc111d8ba7a8e ] A call to wm_adsp_write_ctl() could cause a kernel crash if it does not retrieve a valid kcontrol from snd_soc_card_get_kcontrol(). This can happen due to a missing control name prefix. Then, snd_ctl_notify() crashes when it tries to use the id field. Modified wm_adsp_write_ctl() to incorporate the name_prefix (if applicable) such that it is able to retrieve a valid id field from the kcontrol once the platform has booted. Fixes: eb65ccdb0836 ("ASoC: wm_adsp: Expose mixer control API") Signed-off-by: Adam Brickman Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20201001152425.8590-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0a1bfab8acb09dd0236d35689cd19b26a462c3af Author: Dan Carpenter Date: Tue Sep 29 13:35:48 2020 +0300 staging: rtl8712: Fix enqueue_reorder_recvframe() [ Upstream commit 29838144f280fc03ca06a621568f34e1d0a65a4f ] The logic of this function was accidentally broken by a checkpatch inspired cleanup. I've modified the code to restore the original behavior and also make checkpatch happy. Fixes: 98fe05e21a6e ("staging: rtl8712: Remove unnecesary else after return statement.") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20200929103548.GA493135@mwanda Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit da6f9b9b4b0139e73e8c1b0b0dfbce217781b3cd Author: Drew Fustini Date: Mon Sep 14 01:03:07 2020 +0200 pinctrl: single: fix debug output when #pinctrl-cells = 2 [ Upstream commit f4a2b19c37caf40f3b8487ccb9032b974a84a3a7 ] The debug output in pcs_parse_one_pinctrl_entry() needs to be updated to print the correct pinctrl register value when #pinctrl-cells is 2. Fixes: a13395418888 ("pinctrl: single: parse #pinctrl-cells = 2") Reported-by: Trent Piepho Signed-off-by: Drew Fustini Acked-by: Tony Lindgren Link: https://lore.kernel.org/linux-omap/3139716.CMS8C0sQ7x@zen.local/ Link: https://lore.kernel.org/r/20200913230306.2061645-1-drew@beagleboard.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f1578017e6afa809a57acc6417987f7f2e7739f6 Author: Drew Fustini Date: Wed Sep 30 12:48:40 2020 -0500 pinctrl: single: fix pinctrl_spec.args_count bounds check [ Upstream commit 9b9448f39e83d8e6fdfed006c5db8c304a98c2cd ] The property #pinctrl-cells can either be 1 or 2: - if #pinctrl-cells = <1>, then pinctrl_spec.args_count = 2 - if #pinctrl-cells = <2>, then pinctrl_spec.args_count = 3 All other values of pinctrl_spec.args_count are incorrect. This fix checks the upper bound instead of just the lower bound. Fixes: a13395418888 ("pinctrl: single: parse #pinctrl-cells = 2") Reported-by: Trent Piepho Signed-off-by: Drew Fustini Acked-by: Tony Lindgren Link: https://lore.kernel.org/linux-omap/3139716.CMS8C0sQ7x@zen.local/ Link: https://lore.kernel.org/r/20200930174839.1308344-1-drew@beagleboard.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1fa6f3f695253c8b6110e215db39f0d97f05ba03 Author: Mike Snitzer Date: Mon Sep 28 13:41:36 2020 -0400 dm: fix missing imposition of queue_limits from dm_wq_work() thread [ Upstream commit 0c2915b8c6db108b1dfb240391cc5a175f97f15b ] If a DM device was suspended when bios were issued to it, those bios would be deferred using queue_io(). Once the DM device was resumed dm_process_bio() could be called by dm_wq_work() for original bio that still needs splitting. dm_process_bio()'s check for current->bio_list (meaning call chain is within ->submit_bio) as a prerequisite for calling blk_queue_split() for "abnormal IO" would result in dm_process_bio() never imposing corresponding queue_limits (e.g. discard_granularity, discard_max_bytes, etc). Fix this by always having dm_wq_work() resubmit deferred bios using submit_bio_noacct(). Side-effect is blk_queue_split() is always called for "abnormal IO" from ->submit_bio, be it from application thread or dm_wq_work() workqueue, so proper bio splitting and depth-first bio submission is performed. For sake of clarity, remove current->bio_list check before call to blk_queue_split(). Also, remove dm_wq_work()'s use of dm_{get,put}_live_table() -- no longer needed since IO will be reissued in terms of ->submit_bio. And rename bio variable from 'c' to 'bio'. Fixes: cf9c37865557 ("dm: fix comment in dm_process_bio()") Reported-by: Jeffle Xu Reviewed-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 301c037eb8b976837aa7b8d35b0e214bff1132c7 Author: Dan Carpenter Date: Fri Sep 11 14:33:26 2020 +0300 mfd: sm501: Fix leaks in probe() [ Upstream commit 8ce24f8967df2836b4557a23e74dc4bb098249f1 ] This code should clean up if sm501_init_dev() fails. Fixes: b6d6454fdb66 ("[PATCH] mfd: SM501 core driver") Signed-off-by: Dan Carpenter Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit c5efd7ad539cf6529872ea6c084352e3761d22b9 Author: Marc Zyngier Date: Thu Sep 3 17:02:37 2020 +0100 mfd: syscon: Don't free allocated name for regmap_config [ Upstream commit 529a1101212a785c5df92c314b0e718287150c3b ] The name allocated for the regmap_config structure is freed pretty early, right after the registration of the MMIO region. Unfortunately, that doesn't follow the life cycle that debugfs expects, as it can access the name field long after the free has occurred. Move the free on the error path, and keep it forever otherwise. Fixes: e15d7f2b81d2 ("mfd: syscon: Use a unique name with regmap_config") Signed-off-by: Marc Zyngier Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 35a3cb9120fbc80aae1c388f9164506d19d3a653 Author: Serge Semin Date: Wed Sep 23 19:19:50 2020 +0300 serial: 8250_dw: Fix clk-notifier/port suspend deadlock [ Upstream commit 85985a3dcd7415dd849cf62ec14f931cd905099a ] It has been discovered that there is a potential deadlock between the clock-change-notifier thread and the UART port suspending one: CPU0 (suspend CPU/UART) CPU1 (update clock) ---- ---- lock(&port->mutex); lock((work_completion)(&data->clk_work)); lock(&port->mutex); lock((work_completion)(&data->clk_work)); *** DEADLOCK *** The best way to fix this is to eliminate the CPU0 port->mutex/work-completion scenario. So we suggest to register and unregister the clock-notifier during the DW APB UART port probe/remove procedures, instead of doing that at the points of the port startup/shutdown. Link: https://lore.kernel.org/linux-serial/f1cd5c75-9cda-6896-a4e2-42c5bfc3f5c3@redhat.com Fixes: cc816969d7b5 ("serial: 8250_dw: Fix common clocks usage race condition") Reported-by: Hans de Goede Tested-by: Hans de Goede Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20200923161950.6237-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit caecce8e15169ce3355e4c29779c903bcf4f7e47 Author: Serge Semin Date: Wed Sep 23 19:19:49 2020 +0300 serial: 8250: Skip uninitialized TTY port baud rate update [ Upstream commit c8dff3aa824177013d90967687f09f713a55d13f ] It is erroneous to update the TTY port baud rate if it hasn't been initialized yet, because in that case the TTY struct isn't set. So there is no termios structure to get and re-calculate the baud if the current baud can't be reached. Let's skip the baud rate update then until the port is fully initialized. Note the update UART clock method still sets the uartclk member with a new ref clock value even if the port is turned off. The new UART ref clock rate will be used later on the port starting up procedure. Fixes: 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method") Tested-by: Hans de Goede Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20200923161950.6237-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e78c19340b5dd45627837c74e47de9e7377080b1 Author: Serge Semin Date: Wed Sep 23 19:19:48 2020 +0300 serial: 8250: Discard RTS/DTS setting from clock update method [ Upstream commit 7718453e36960dadb8dc46f2b514b309659e1270 ] It has been a mistake to add the MCR register RTS/DTS fields setting in the generic method of the UART reference clock update. There is no point in asserting these lines at that procedure. Just discard the serial8250_out_MCR() mathod invocation from there then. Fixes: 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method") Tested-by: Hans de Goede Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20200923161950.6237-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ba6df7707f27350d37b0f27801e4e71f7cb9ac72 Author: Andy Shevchenko Date: Tue Sep 29 14:03:04 2020 +0300 pinctrl: tigerlake: Fix register offsets for TGL-H variant [ Upstream commit cb8cc18508fb0cad74929ffd080bebafe91609e2 ] It appears that almost traditionally the H variants have some deviations in the register offsets in comparison to LP ones. This is the case for Intel Tiger Lake as well. Fix register offsets for TGL-H variant. Fixes: 653d96455e1e ("pinctrl: tigerlake: Add support for Tiger Lake-H") Reported-by: Pierre-Louis Bossart Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Link: https://lore.kernel.org/r/20200929110306.40852-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c7527723c6014d02188c2726a85686d9c88a4eaf Author: Ilya Leoshkevich Date: Tue Sep 29 22:18:14 2020 +0200 selftests/bpf: Fix endianness issues in sk_lookup/ctx_narrow_access [ Upstream commit 6458bde368cee77e798d05cccd2316db4d748c41 ] This test makes a lot of narrow load checks while assuming little endian architecture, and therefore fails on s390. Fix by introducing LSB and LSW macros and using them to perform narrow loads. Fixes: 0ab5539f8584 ("selftests/bpf: Tests for BPF_SK_LOOKUP attach point") Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200929201814.44360-1-iii@linux.ibm.com Signed-off-by: Sasha Levin commit 9230bc38af9619aa0821639bc2a4f7fb22d32e90 Author: Thomas Gleixner Date: Tue Sep 29 22:25:10 2020 +0200 net: enic: Cure the enic api locking trainwreck [ Upstream commit a53b59ece86c86d16d12ccdaa1ad0c78250a9d96 ] enic_dev_wait() has a BUG_ON(in_interrupt()). Chasing the callers of enic_dev_wait() revealed the gems of enic_reset() and enic_tx_hang_reset() which are both invoked through work queues in order to be able to call rtnl_lock(). So far so good. After locking rtnl both functions acquire enic::enic_api_lock which serializes against the (ab)use from infiniband. This is where the trainwreck starts. enic::enic_api_lock is a spin_lock() which implicitly disables preemption, but both functions invoke a ton of functions under that lock which can sleep. The BUG_ON(in_interrupt()) does not trigger in that case because it can't detect the preempt disabled condition. This clearly has never been tested with any of the mandatory debug options for 7+ years, which would have caught that for sure. Cure it by adding a enic_api_busy member to struct enic, which is modified and evaluated with enic::enic_api_lock held. If enic_api_devcmd_proxy_by_index() observes enic::enic_api_busy as true, it drops enic::enic_api_lock and busy waits for enic::enic_api_busy to become false. It would be smarter to wait for a completion of that busy period, but enic_api_devcmd_proxy_by_index() is called with other spin locks held which obviously can't sleep. Remove the BUG_ON(in_interrupt()) check as well because it's incomplete and with proper debugging enabled the problem would have been caught from the debug checks in schedule_timeout(). Fixes: 0b038566c0ea ("drivers/net: enic: Add an interface for USNIC to interact with firmware") Signed-off-by: Thomas Gleixner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dd5c3f9cdbf7614ae04f618b17c595c78131a131 Author: Fabrice Gasnier Date: Wed Jul 1 16:55:28 2020 +0200 iio: adc: stm32-adc: fix runtime autosuspend delay when slow polling [ Upstream commit c537d3457542a398caa1fe58e0976c5f83cf7281 ] When the ADC is runtime suspended and starting a conversion, the stm32-adc driver calls pm_runtime_get_sync() that gets cascaded to the parent (e.g. runtime resume of stm32-adc-core driver). This also kicks the autosuspend delay (e.g. 2s) of the parent. Once the ADC is active, calling pm_runtime_get_sync() again (upon a new capture) won't kick the autosuspend delay for the parent (stm32-adc-core driver) as already active. Currently, this makes the stm32-adc-core driver go in suspend state every 2s when doing slow polling. As an example, doing a capture, e.g. cat in_voltageY_raw at a 0.2s rate, the auto suspend delay for the parent isn't refreshed. Once it expires, the parent immediately falls into runtime suspended state, in between two captures, as soon as the child driver falls into runtime suspend state: - e.g. after 2s, + child calls pm_runtime_put_autosuspend() + 100ms autosuspend delay of the child. - stm32-adc-core switches off regulators, clocks and so on. - They get switched on back again 100ms later in this example (at 2.2s). So, use runtime_idle() callback in stm32-adc-core driver to call pm_runtime_mark_last_busy() for the parent driver (stm32-adc-core), to avoid this. Fixes: 9bdbb1139ca1 ("iio: adc: stm32-adc: add power management support") Signed-off-by: Fabrice Gasnier Reviewed-by: Ulf Hansson Link: https://lore.kernel.org/r/1593615328-5180-1-git-send-email-fabrice.gasnier@st.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7b52a295b30162ef6937e3cfea1e4d2ada135edb Author: Yu Kuai Date: Tue Sep 29 09:40:37 2020 +0800 iommu/qcom: add missing put_device() call in qcom_iommu_of_xlate() [ Upstream commit e2eae09939a89e0994f7965ba3c676a5eac8b4b0 ] if of_find_device_by_node() succeed, qcom_iommu_of_xlate() doesn't have a corresponding put_device(). Thus add put_device() to fix the exception handling for this function implementation. Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu") Acked-by: Rob Clark Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20200929014037.2436663-1-yukuai3@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 13e0fb06a8509f21dd3d8545694587fcdb16e010 Author: Andrew Jeffery Date: Thu Sep 10 12:26:30 2020 +0930 pinctrl: aspeed: Use the right pinconf mask [ Upstream commit 1d6db5ae6b090d1a8edfcb36b9bf47c5f4fe27f6 ] The Aspeed pinconf data structures are split into 'conf' and 'map' types, where the 'conf' struct defines which register and bitfield to manipulate, while the 'map' struct defines what value to write to the register and bitfield. Both structs have a mask member, and the wrong mask was being used to tell the regmap which bits to update. A todo is to look at whether we can remove the mask from the 'map' struct. Fixes: 5f52c853847f ("pinctrl: aspeed: Use masks to describe pinconf bitfields") Signed-off-by: Andrew Jeffery Reviewed-by: Joel Stanley Cc: Johnny Huang Link: https://lore.kernel.org/r/20200910025631.2996342-3-andrew@aj.id.au Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6dbd3dd8c42677d74d50307c906bfe6496d2ab74 Author: Colin Ian King Date: Fri Sep 25 14:22:24 2020 +0100 qtnfmac: fix resource leaks on unsupported iftype error return path [ Upstream commit 63f6982075d890d7563e2469643f05a37d193f01 ] Currently if an unsupported iftype is detected the error return path does not free the cmd_skb leading to a resource leak. Fix this by free'ing cmd_skb. Addresses-Coverity: ("Resource leak") Fixes: 805b28c05c8e ("qtnfmac: prepare for AP_VLAN interface type support") Signed-off-by: Colin Ian King Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200925132224.21638-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit 94b4f6df020bd2b925654cb047146504a3f728cf Author: Toke Høiland-Jørgensen Date: Fri Sep 25 23:25:11 2020 +0200 selftests: Remove fmod_ret from test_overhead [ Upstream commit b000def2e052fc8ddea31a18019f6ebe044defb3 ] The test_overhead prog_test included an fmod_ret program that attached to __set_task_comm() in the kernel. However, this function was never listed as allowed for return modification, so this only worked because of the verifier skipping tests when a trampoline already existed for the attach point. Now that the verifier checks have been fixed, remove fmod_ret from the test so it works again. Fixes: 4eaf0b5c5e04 ("selftest/bpf: Fmod_ret prog and implement test_overhead as part of bench") Acked-by: Andrii Nakryiko Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 9d6b33d27c250eb381d97297e40eb15f5586913d Author: Toke Høiland-Jørgensen Date: Fri Sep 25 23:25:00 2020 +0200 bpf: disallow attaching modify_return tracing functions to other BPF programs [ Upstream commit 1af9270e908cd50a4f5d815c9b6f794c7d57ed07 ] From the checks and commit messages for modify_return, it seems it was never the intention that it should be possible to attach a tracing program with expected_attach_type == BPF_MODIFY_RETURN to another BPF program. However, check_attach_modify_return() will only look at the function name, so if the target function starts with "security_", the attach will be allowed even for bpf2bpf attachment. Fix this oversight by also blocking the modification if a target program is supplied. Fixes: 18644cec714a ("bpf: Fix use-after-free in fmod_ret check") Fixes: 6ba43b761c41 ("bpf: Attachment verification for BPF_MODIFY_RETURN") Acked-by: Andrii Nakryiko Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 05ad722863103b860fcfea25827cbb9b68868ae2 Author: Lijun Pan Date: Sun Sep 27 19:06:25 2020 -0500 ibmvnic: set up 200GBPS speed [ Upstream commit b9cd795b0e4860f482bf3741d12e1c8f3ec1cfc9 ] Set up the speed according to crq->query_phys_parms.rsp.speed. Fix IBMVNIC_10GBPS typo. Fixes: f8d6ae0d27ec ("ibmvnic: Report actual backing device speed and duplex values") Signed-off-by: Lijun Pan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5be629ce1ef347ed3fbe343afb14cfefefba4d99 Author: Sai Prakash Ranjan Date: Mon Sep 28 10:35:13 2020 -0600 coresight: etm4x: Fix save and restore of TRCVMIDCCTLR1 register [ Upstream commit 3477326277451000bc667dfcc4fd0774c039184c ] In commit f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states"), mistakenly TRCVMIDCCTLR1 register value was saved in trcvmidcctlr0 state variable which is used to store TRCVMIDCCTLR0 register value in etm4x_cpu_save() and then same value is written back to both TRCVMIDCCTLR0 and TRCVMIDCCTLR1 in etm4x_cpu_restore(). There is already a trcvmidcctlr1 state variable available for TRCVMIDCCTLR1, so use it. Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states") Reviewed-by: Suzuki K Poulose Signed-off-by: Sai Prakash Ranjan Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200928163513.70169-26-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e2af80366f6e53f689cca7c6df6e10e953389375 Author: Mike Leach Date: Mon Sep 28 10:35:06 2020 -0600 coresight: cti: Fix bug clearing sysfs links on callback [ Upstream commit cab280bf3533c72f95ebdb65ce534b5cdc4729dc ] During module unload, a coresight driver module will call back into the CTI driver to remove any links between the two devices. The current code has 2 issues:- 1) in the CTI driver the matching code is matching to the wrong device so misses all the links. 2) The callback is called too late in the unload process resulting in a crash. This fixes both the issues. Fixes: 177af8285b59 ("coresight: cti: Enable CTI associated with devices") Reported-by: Tingwei Zhang Acked-by: Suzuki K Poulose Signed-off-by: Mike Leach Signed-off-by: Tingwei Zhang Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200928163513.70169-19-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d318b76363d11fcf19fcaa963378648f0e88c0fe Author: Mike Leach Date: Mon Sep 28 10:35:05 2020 -0600 coresight: cti: Fix remove sysfs link error [ Upstream commit 1cce921bce7dcf6fef9bdfa4dcc9406383274408 ] CTI code to remove sysfs link to other devices on shutdown, incorrectly tries to remove a single ended link when these are all double ended. This implementation leaves elements in the link info structure undefined which results in a crash in recent tests for driver module unload. This patch corrects the link removal code. Fixes: 73274abb6557 ("coresight: cti: Add in sysfs links to other coresight devices") Reported-by: Tingwei Zhang Signed-off-by: Mike Leach Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200928163513.70169-18-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f889e09760b92179fcb5d18b776f73a7c50d7f92 Author: Tingwei Zhang Date: Mon Sep 28 10:34:56 2020 -0600 coresight: etm: perf: Fix warning caused by etm_setup_aux failure [ Upstream commit 716f5652a13122364a65e694386b9b26f5e98c51 ] When coresight_build_path() fails on all the cpus, etm_setup_aux calls etm_free_aux() to free allocated event_data. WARN_ON(cpumask_empty(mask) will be triggered since cpu mask is empty. Check event_data->snk_config is not NULL first to avoid this warning. Fixes: f5200aa9831f38 ("coresight: perf: Refactor function free_event_data()") Reviewed-by: Mike Leach Reviewed-by: Suzuki K Poulose Signed-off-by: Tingwei Zhang Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200928163513.70169-9-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0a09fe26ff4ac222765ea290a3079c8dce5b85eb Author: Matthew Wilcox (Oracle) Date: Mon Sep 21 08:58:39 2020 -0700 iomap: Use kzalloc to allocate iomap_page [ Upstream commit a6901d4d148dcbad7efb3174afbdf68c995618c2 ] We can skip most of the initialisation, although spinlocks still need explicit initialisation as architectures may use a non-zero value to indicate unlocked. The comment is no longer useful as attach_page_private() handles the refcount now. Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Christoph Hellwig Reviewed-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 96ff0eff6b8c3fad45dea7a0a2f291d8c57fc0fe Author: Rajkumar Manoharan Date: Mon Sep 28 00:28:10 2020 -0700 nl80211: fix OBSS PD min and max offset validation [ Upstream commit 6c8b6e4a5f745ec49286ac0a3f1d591a34818f82 ] The SRG min and max offset won't present when SRG Information Present of SR control field of Spatial Reuse Parameter Set element set to 0. Per spec. IEEE802.11ax D7.0, SRG OBSS PD Min Offset ≤ SRG OBSS PD Max Offset. Hence fix the constrain check to allow same values in both offset and also call appropriate nla_get function to read the values. Fixes: 796e90f42b7e ("cfg80211: add support for parsing OBBS_PD attributes") Signed-off-by: Rajkumar Manoharan Link: https://lore.kernel.org/r/1601278091-20313-1-git-send-email-rmanohar@codeaurora.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0fd19be98a2679d41d711fc324f5ce8a1e85d780 Author: Mohammed Gamal Date: Thu Sep 24 17:11:17 2020 +0200 hv: clocksource: Add notrace attribute to read_hv_sched_clock_*() functions [ Upstream commit 1f3aed01473c41c9f896fbf4c30d330655e8aa7c ] When selecting function_graph tracer with the command: # echo function_graph > /sys/kernel/debug/tracing/current_tracer The kernel crashes with the following stack trace: [69703.122389] BUG: stack guard page was hit at 000000001056545c (stack is 00000000fa3f8fed..0000000005d39503) [69703.122403] kernel stack overflow (double-fault): 0000 [#1] SMP PTI [69703.122413] CPU: 0 PID: 16982 Comm: bash Kdump: loaded Not tainted 4.18.0-236.el8.x86_64 #1 [69703.122420] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019 [69703.122433] RIP: 0010repare_ftrace_return+0xa/0x110 [69703.122458] Code: 05 00 0f 0b 48 c7 c7 10 ca 69 ae 0f b6 f0 e8 4b 52 0c 00 31 c0 eb ca 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 56 41 55 41 54 <53> 48 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 45 d8 31 c0 48 85 [69703.122467] RSP: 0018:ffffbd6d01118000 EFLAGS: 00010086 [69703.122476] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000003 [69703.122484] RDX: 0000000000000000 RSI: ffffbd6d011180d8 RDI: ffffffffadce7550 [69703.122491] RBP: ffffbd6d01118018 R08: 0000000000000000 R09: ffff9d4b09266000 [69703.122498] R10: ffff9d4b0fc04540 R11: ffff9d4b0fc20a00 R12: ffff9d4b6e42aa90 [69703.122506] R13: ffff9d4b0fc20ab8 R14: 00000000000003e8 R15: ffffbd6d0111837c [69703.122514] FS: 00007fd5f2588740(0000) GS:ffff9d4b6e400000(0000) knlGS:0000000000000000 [69703.122521] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [69703.122528] CR2: ffffbd6d01117ff8 CR3: 00000000565d8001 CR4: 00000000003606f0 [69703.122538] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [69703.122545] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [69703.122552] Call Trace: [69703.122568] ftrace_graph_caller+0x6b/0xa0 [69703.122589] ? read_hv_sched_clock_tsc+0x5/0x20 [69703.122599] read_hv_sched_clock_tsc+0x5/0x20 [69703.122611] sched_clock+0x5/0x10 [69703.122621] sched_clock_local+0x12/0x80 [69703.122631] sched_clock_cpu+0x8c/0xb0 [69703.122644] trace_clock_global+0x21/0x90 [69703.122655] ring_buffer_lock_reserve+0x100/0x3c0 [69703.122671] trace_buffer_lock_reserve+0x16/0x50 [69703.122683] __trace_graph_entry+0x28/0x90 [69703.122695] trace_graph_entry+0xfd/0x1a0 [69703.122705] ? read_hv_clock_tsc_cs+0x10/0x10 [69703.122714] ? sched_clock+0x5/0x10 [69703.122723] prepare_ftrace_return+0x99/0x110 [69703.122734] ? read_hv_clock_tsc_cs+0x10/0x10 [69703.122743] ? sched_clock+0x5/0x10 [69703.122752] ftrace_graph_caller+0x6b/0xa0 [69703.122768] ? read_hv_clock_tsc_cs+0x10/0x10 [69703.122777] ? sched_clock+0x5/0x10 [69703.122786] ? read_hv_sched_clock_tsc+0x5/0x20 [69703.122796] ? ring_buffer_unlock_commit+0x1d/0xa0 [69703.122805] read_hv_sched_clock_tsc+0x5/0x20 [69703.122814] ftrace_graph_caller+0xa0/0xa0 [ ... recursion snipped ... ] Setting the notrace attribute for read_hv_sched_clock_msr() and read_hv_sched_clock_tsc() fixes it. Fixes: bd00cd52d5be ("clocksource/drivers/hyperv: Add Hyper-V specific sched clock function") Signed-off-by: Vitaly Kuznetsov Signed-off-by: Mohammed Gamal Link: https://lore.kernel.org/r/20200924151117.767442-1-mgamal@redhat.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 723fb52475df79404839d189ff8a83ecafd1acd0 Author: Vadym Kochan Date: Wed Sep 23 23:44:56 2020 +0300 nvmem: core: fix possibly memleak when use nvmem_cell_info_to_nvmem_cell() [ Upstream commit fc9eec4d643597cf4cb2fef17d48110e677610da ] Fix missing 'kfree_const(cell->name)' when call to nvmem_cell_info_to_nvmem_cell() in several places: * after nvmem_cell_info_to_nvmem_cell() failed during nvmem_add_cells() * during nvmem_device_cell_{read,write} when cell->name is kstrdup'ed() without calling kfree_const() at the end, but really there is no reason to do that 'dup, because the cell instance is allocated on the stack for some short period to be read/write without exposing it to the caller. So the new nvmem_cell_info_to_nvmem_cell_nodup() helper is introduced which is used to convert cell_info -> cell without name duplication as a lighweight version of nvmem_cell_info_to_nvmem_cell(). Fixes: e2a5402ec7c6 ("nvmem: Add nvmem_device based consumer apis.") Reviewed-by: Srinivas Kandagatla Acked-by: Srinivas Kandagatla Signed-off-by: Vadym Kochan Link: https://lore.kernel.org/r/20200923204456.14032-1-vadym.kochan@plvision.eu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 527902423237c81644c601397a86533e6fc14617 Author: Yang Yingliang Date: Sat Sep 19 14:32:40 2020 +0800 tty: serial: imx: fix link error with CONFIG_SERIAL_CORE_CONSOLE=n [ Upstream commit 24c796926e2f88b383a76ddc871a7cdd62484f3a ] aarch64-linux-gnu-ld: drivers/tty/serial/imx_earlycon.o: in function `imx_uart_console_early_write': imx_earlycon.c:(.text+0x84): undefined reference to `uart_console_write' The driver uses the uart_console_write(), but SERIAL_CORE_CONSOLE is not selected, so uart_console_write is not defined, then we get the error. Fix this by selecting SERIAL_CORE_CONSOLE. Fixes: 699cc4dfd140 ("tty: serial: imx: add imx earlycon driver") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20200919063240.2754965-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8f5fffaf173086942437b0714c2eccc0d8611800 Author: Yang Yingliang Date: Sat Sep 19 14:35:35 2020 +0800 tty: hvc: fix link error with CONFIG_SERIAL_CORE_CONSOLE=n [ Upstream commit 75fc65079d8253e1c25a5f8348111a85d71e0f01 ] aarch64-linux-gnu-ld: drivers/tty/hvc/hvc_dcc.o: in function `dcc_early_write': hvc_dcc.c:(.text+0x164): undefined reference to `uart_console_write' The driver uses the uart_console_write(), but SERIAL_CORE_CONSOLE is not selected, so uart_console_write is not defined, then we get the error. Fix this by selecting SERIAL_CORE_CONSOLE. Fixes: d1a1af2cdf19 ("hvc: dcc: Add earlycon support") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20200919063535.2809707-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e6bf3809aca54306a9c41e8e2da557ab2f590cd3 Author: Dmitry Torokhov Date: Fri Sep 25 16:35:52 2020 -0700 HID: hid-input: fix stylus battery reporting [ Upstream commit 505f394fa239cecb76d916aa858f87ed7ea7fde4 ] With commit 4f3882177240 hid-input started clearing of "ignored" usages to avoid using garbage that might have been left in them. However "battery strength" usages should not be ignored, as we do want to use them. Fixes: 4f3882177240 ("HID: hid-input: clear unmapped usages") Reported-by: Kenneth Albanowski Tested-by: Kenneth Albanowski Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 967c6d3f586cb46eac6f04402e0866ddfb99d1b3 Author: Shengjiu Wang Date: Fri Sep 18 18:26:00 2020 +0800 ASoC: fsl_sai: Instantiate snd_soc_dai_driver [ Upstream commit 22a16145af824f91014d07f8664114859900b9e6 ] Instantiate snd_soc_dai_driver for independent symmetric control. Otherwise the symmetric setting may be overwritten by other instance. Fixes: 08fdf65e37d5 ("ASoC: fsl_sai: Add asynchronous mode support") Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1600424760-32071-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 78c062b09723b1df9fe4793f18e90b69056df056 Author: Maxime Ripard Date: Wed Sep 23 10:40:31 2020 +0200 drm/vc4: crtc: Rework a bit the CRTC state code [ Upstream commit 427c4a0680a28f87bb9c7bbfeac26b39ef8682ad ] The current CRTC state reset hook in vc4 allocates a vc4_crtc_state structure as a drm_crtc_state, and relies on the fact that vc4_crtc_state embeds drm_crtc_state as its first member, and therefore can be safely cast. However, this is pretty fragile especially since there's no check for this in place, and we're going to need to access vc4_crtc_state member at reset so this looks like a good occasion to make it more robust. Fixes: 6d6e50039187 ("drm/vc4: Allocate the right amount of space for boot-time CRTC state.") Signed-off-by: Maxime Ripard Tested-by: Dave Stevenson Reviewed-by: Dave Stevenson Link: https://patchwork.freedesktop.org/patch/msgid/20200923084032.218619-1-maxime@cerno.tech Signed-off-by: Sasha Levin commit dd6fbde266a546e48a0e48fdab6b92c86a498ddb Author: Srinivas Kandagatla Date: Fri Sep 25 10:55:20 2020 +0100 slimbus: qcom-ngd-ctrl: disable ngd in qmi server down callback [ Upstream commit 709ec3f7fc5773ac4aa6fb22c3f0ac8103c674db ] In QMI new server notification we enable the NGD however during delete server notification we do not disable the NGD. This can lead to multiple instances of NGD being enabled, so make sure that we disable NGD in delete server callback to fix this issue! Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200925095520.27316-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4c8b92bc2fb9f5e4b146a849be343f7cfb58f6d1 Author: Srinivas Kandagatla Date: Fri Sep 25 10:55:19 2020 +0100 slimbus: core: do not enter to clock pause mode in core [ Upstream commit df2c471c4ae07e18a0396db670dca2ef867c5153 ] Let the controller logic decide when to enter into clock pause mode! Entering in to pause mode during unregistration does not really make sense as the controller is totally going down at that point in time. Fixes: 4b14e62ad3c9e ("slimbus: Add support for 'clock-pause' feature") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200925095520.27316-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d30259a6883beda8a18a7c68001d87d4d32a8c0f Author: Srinivas Kandagatla Date: Fri Sep 25 10:55:18 2020 +0100 slimbus: core: check get_addr before removing laddr ida [ Upstream commit f97769fde678e111a1b7b165b380d8a3dfe54f4e ] logical address can be either assigned by the SLIMBus controller or the core. Core uses IDA in cases where get_addr callback is not provided by the controller. Core already has this check while allocating IDR, however during absence reporting this is not checked. This patch fixes this issue. Fixes: 46a2bb5a7f7e ("slimbus: core: Add slim controllers support") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200925095520.27316-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 77a2a7e358d64c86f7e6a58258da14411db4aab0 Author: Eric Dumazet Date: Thu Sep 24 11:36:19 2020 -0700 quota: clear padding in v2r1_mem2diskdqb() [ Upstream commit 3d3dc274ce736227e3197868ff749cff2f175f63 ] Freshly allocated memory contains garbage, better make sure to init all struct v2r1_disk_dqblk fields to avoid KMSAN report: BUG: KMSAN: uninit-value in qtree_entry_unused+0x137/0x1b0 fs/quota/quota_tree.c:218 CPU: 0 PID: 23373 Comm: syz-executor.1 Not tainted 5.9.0-rc4-syzkaller #0 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+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:122 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:219 qtree_entry_unused+0x137/0x1b0 fs/quota/quota_tree.c:218 v2r1_mem2diskdqb+0x43d/0x710 fs/quota/quota_v2.c:285 qtree_write_dquot+0x226/0x870 fs/quota/quota_tree.c:394 v2_write_dquot+0x1ad/0x280 fs/quota/quota_v2.c:333 dquot_commit+0x4af/0x600 fs/quota/dquot.c:482 ext4_write_dquot fs/ext4/super.c:5934 [inline] ext4_mark_dquot_dirty+0x4d8/0x6a0 fs/ext4/super.c:5985 mark_dquot_dirty fs/quota/dquot.c:347 [inline] mark_all_dquot_dirty fs/quota/dquot.c:385 [inline] dquot_alloc_inode+0xc05/0x12b0 fs/quota/dquot.c:1755 __ext4_new_inode+0x8204/0x9d70 fs/ext4/ialloc.c:1155 ext4_tmpfile+0x41a/0x850 fs/ext4/namei.c:2686 vfs_tmpfile+0x2a2/0x570 fs/namei.c:3283 do_tmpfile fs/namei.c:3316 [inline] path_openat+0x4035/0x6a90 fs/namei.c:3359 do_filp_open+0x2b8/0x710 fs/namei.c:3395 do_sys_openat2+0xa88/0x1140 fs/open.c:1168 do_sys_open fs/open.c:1184 [inline] __do_compat_sys_openat fs/open.c:1242 [inline] __se_compat_sys_openat+0x2a4/0x310 fs/open.c:1240 __ia32_compat_sys_openat+0x56/0x70 fs/open.c:1240 do_syscall_32_irqs_on arch/x86/entry/common.c:80 [inline] __do_fast_syscall_32+0x129/0x180 arch/x86/entry/common.c:139 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:162 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:205 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c RIP: 0023:0xf7ff4549 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 002b:00000000f55cd0cc EFLAGS: 00000296 ORIG_RAX: 0000000000000127 RAX: ffffffffffffffda RBX: 00000000ffffff9c RCX: 0000000020000000 RDX: 0000000000410481 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:143 [inline] kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:126 kmsan_slab_alloc+0x8a/0xe0 mm/kmsan/kmsan_hooks.c:80 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2916 [inline] __kmalloc+0x2bb/0x4b0 mm/slub.c:3982 kmalloc include/linux/slab.h:559 [inline] getdqbuf+0x56/0x150 fs/quota/quota_tree.c:52 qtree_write_dquot+0xf2/0x870 fs/quota/quota_tree.c:378 v2_write_dquot+0x1ad/0x280 fs/quota/quota_v2.c:333 dquot_commit+0x4af/0x600 fs/quota/dquot.c:482 ext4_write_dquot fs/ext4/super.c:5934 [inline] ext4_mark_dquot_dirty+0x4d8/0x6a0 fs/ext4/super.c:5985 mark_dquot_dirty fs/quota/dquot.c:347 [inline] mark_all_dquot_dirty fs/quota/dquot.c:385 [inline] dquot_alloc_inode+0xc05/0x12b0 fs/quota/dquot.c:1755 __ext4_new_inode+0x8204/0x9d70 fs/ext4/ialloc.c:1155 ext4_tmpfile+0x41a/0x850 fs/ext4/namei.c:2686 vfs_tmpfile+0x2a2/0x570 fs/namei.c:3283 do_tmpfile fs/namei.c:3316 [inline] path_openat+0x4035/0x6a90 fs/namei.c:3359 do_filp_open+0x2b8/0x710 fs/namei.c:3395 do_sys_openat2+0xa88/0x1140 fs/open.c:1168 do_sys_open fs/open.c:1184 [inline] __do_compat_sys_openat fs/open.c:1242 [inline] __se_compat_sys_openat+0x2a4/0x310 fs/open.c:1240 __ia32_compat_sys_openat+0x56/0x70 fs/open.c:1240 do_syscall_32_irqs_on arch/x86/entry/common.c:80 [inline] __do_fast_syscall_32+0x129/0x180 arch/x86/entry/common.c:139 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:162 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:205 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c Fixes: 498c60153ebb ("quota: Implement quota format with 64-bit space and inode limits") Link: https://lore.kernel.org/r/20200924183619.4176790-1-edumazet@google.com Signed-off-by: Eric Dumazet Cc: Jan Kara Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit ff48dd85f701c798cfb1d3971ef454f012603d3b Author: Lorenzo Bianconi Date: Mon Sep 14 20:29:01 2020 +0200 mt76: mt7915: fix possible memory leak in mt7915_mcu_add_beacon [ Upstream commit 071c8ce8e92a86b8bf78678e78eb4b79fdc16768 ] Release mcu message memory in case of failure in mt7915_mcu_add_beacon routine Fixes: e57b7901469fc ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c5053ffe3e2457dc046c65739c69516417c62595 Author: Lorenzo Bianconi Date: Tue Sep 8 13:54:03 2020 +0200 mt76: mt7622: fix fw hang on mt7622 [ Upstream commit 6892555dbe71ed551d3779aa20747484dc9b6ad5 ] Set poll timeout to 3s for mt7622 devices in order to avoid fw hangs. Swap mt7622_trigger_hif_int and doorbell configuration order in mt7615_mcu_drv_pmctrl routine. Introduce mt7615_mcu_lp_drv_pmctrl routine to take care of drv_own configuration for runtime-pm. Fixes: 08523a2a1db5 ("mt76: mt7615: add mt7615_pm_wake utility routine") Fixes: 894b7767ec2f ("mt76: mt7615: improve mt7615_driver_own reliability") Fixes: 757b0e7fd6f4 ("mt76: mt7615: avoid polling in fw_own for mt7663") Co-developed-by: Shayne Chen Signed-off-by: Shayne Chen Co-developed-by: Ryder Lee Signed-off-by: Ryder Lee Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 94331b4e6729d395b4951eaeaacb504b2378f6f4 Author: Lorenzo Bianconi Date: Mon Jul 20 17:41:19 2020 +0200 mt76: mt7615: move drv_own/fw_own in mt7615_mcu_ops [ Upstream commit 186b659c0859704ef3b2fb634a659724f020889a ] Introduce set_drv_ctrl and set_fw_ctrl function pointers in mt7615_mcu_ops data structure. This is a preliminary patch to enable runtime-pm for non-pci chipsets Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4ec09b924debdf6528fde42105314b674fe19055 Author: Lorenzo Bianconi Date: Mon Aug 24 20:55:12 2020 +0200 mt76: mt7663u: fix dma header initialization [ Upstream commit 8da40d698111ad27b03afc40d67843e3073395e7 ] Fix length field corruption in usb dma header introduced adding sdio support Fixes: 75b10f0cbd0b ("mt76: mt76u: add mt76_skb_adjust_pad utility routine") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0f39a2f66b43787b5cea46bbc0f18475032da488 Author: Lorenzo Bianconi Date: Fri Aug 21 12:52:15 2020 +0200 mt76: fix a possible NULL pointer dereference in mt76_testmode_dump [ Upstream commit ce8463a726a5669b200a1c2c17f95bc1394cc6bf ] Fix a possible NULL pointer dereference in mt76_testmode_dump() since nla_nest_start returns NULL in case of error Fixes: f0efa8621550e ("mt76: add API for testmode support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3d20d6f29da1e4b4c919c6138170ec6b71e79554 Author: Lorenzo Bianconi Date: Fri Aug 21 12:09:54 2020 +0200 mt76: mt7615: fix a possible NULL pointer dereference in mt7615_pm_wake_work [ Upstream commit a081de174d11b12db9a94eb748041c2732f14c10 ] Initialize wcid to global_wcid if msta is NULL in mt7615_pm_wake_work routine since wcid will be dereferenced running mt76_tx() Fixes: 2b8cdfb28d340 ("mt76: mt7615: wake device before pushing frames in mt7615_tx") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6fd4769145cf5af2d7c488a2b396549c755927ff Author: Lorenzo Bianconi Date: Fri Aug 21 11:19:51 2020 +0200 mt76: mt7615: fix possible memory leak in mt7615_tm_set_tx_power [ Upstream commit e862825dcf74203c5ab60335c341766808f47507 ] Fix a memory leak in mt7615_tm_set_tx_power routine if mt7615_eeprom_get_target_power_index fails. Moreover do not account req_header twice in mcu skb allocation. Fixes: 4f0bce1c88882 ("mt76: mt7615: implement testmode support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 91774817d7996dc241b5cc232681fdda3b7427f9 Author: Sean Wang Date: Fri Aug 14 05:49:47 2020 +0800 mt76: mt7663s: fix resume failure [ Upstream commit 8b7c6e1cb2cb1d4e2ee94556695d80dde6ccdcc6 ] MT7663s have to rely on MMC_PM_KEEP_POWER in pm_flags for to avoid SDIO power is being shut off. To fix sdio access failure like "mt7663s mmc1:0001:1: sdio write failed: -22" for the first sdio command to access the bus in the resume handler. Fixes: a66cbdd6573d ("mt76: mt7615: introduce mt7663s support") Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 93dd7ab890f456b5f15a7c8f144f85ba01d5c61f Author: Lorenzo Bianconi Date: Sat Aug 8 20:25:41 2020 +0200 mt76: mt7615: release mutex in mt7615_reset_test_set [ Upstream commit 346f810e22428cdf73ee5cf2e0ce1b79d5671de5 ] Reduce scope of mutex_acquire/mutex_release in mt7615_reset_test_set routine in order to fix the following static checker warning: drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c:179 mt7615_reset_test_set() warn: inconsistent returns 'dev->mt76.mutex'. Reported-by: Dan Carpenter Fixes: ea4906c4be49 ("mt76: mt7615: wake device before accessing regmap in debugfs") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 254f44a6cd724fb23489a921fa57fd8b6e756b59 Author: Lorenzo Bianconi Date: Thu Jul 30 11:21:31 2020 +0200 mt76: mt7615: hold mt76 lock queueing wd in mt7615_queue_key_update [ Upstream commit cddaaa56375615c256eb6960d3092ddb8a7a9154 ] wq queue is always updated holding mt76 spinlock. Grab mt76 lock in mt7615_queue_key_update() before putting a new element at the end of the queue. Fixes: eb99cc95c3b65 ("mt76: mt7615: introduce mt7663u support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9fa6d800605709cf7b16a751b4aa8e5fda5cf2d9 Author: Andreas Färber Date: Sun Sep 20 15:26:21 2020 +0200 rtw88: Fix potential probe error handling race with wow firmware loading [ Upstream commit ac4bac99161e8f7a7a9faef70d8ca8f69d5493a9 ] If rtw_core_init() fails to load the wow firmware, rtw_core_deinit() will not get called to clean up the regular firmware. Ensure that an error loading the wow firmware does not produce an oops for the regular firmware by waiting on its completion to be signalled before returning. Also release the loaded firmware. Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported") Cc: Chin-Yen Lee Cc: Yan-Hsuan Chuang Signed-off-by: Andreas Färber Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200920132621.26468-3-afaerber@suse.de Signed-off-by: Sasha Levin commit 5f131bd7f0a27bbf22394ba565259021188c4e99 Author: Andreas Färber Date: Sun Sep 20 15:26:20 2020 +0200 rtw88: Fix probe error handling race with firmware loading [ Upstream commit ecda9cda3338b594a1b82d62018c247132a39e57 ] In case of rtw8822be, a probe failure after successful rtw_core_init() has been observed to occasionally lead to an oops from rtw_load_firmware_cb(): [ 3.924268] pci 0001:01:00.0: [10ec:b822] type 00 class 0xff0000 [ 3.930531] pci 0001:01:00.0: reg 0x10: [io 0x0000-0x00ff] [ 3.936360] pci 0001:01:00.0: reg 0x18: [mem 0x00000000-0x0000ffff 64bit] [ 3.944042] pci 0001:01:00.0: supports D1 D2 [ 3.948438] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 3.957312] pci 0001:01:00.0: BAR 2: no space for [mem size 0x00010000 64bit] [ 3.964645] pci 0001:01:00.0: BAR 2: failed to assign [mem size 0x00010000 64bit] [ 3.972332] pci 0001:01:00.0: BAR 0: assigned [io 0x10000-0x100ff] [ 3.986240] rtw_8822be 0001:01:00.0: enabling device (0000 -> 0001) [ 3.992735] rtw_8822be 0001:01:00.0: failed to map pci memory [ 3.998638] rtw_8822be 0001:01:00.0: failed to request pci io region [ 4.005166] rtw_8822be 0001:01:00.0: failed to setup pci resources [ 4.011580] rtw_8822be: probe of 0001:01:00.0 failed with error -12 [ 4.018827] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 4.029121] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 4.050828] Unable to handle kernel paging request at virtual address edafeaac9607952c [ 4.058975] Mem abort info: [ 4.058980] ESR = 0x96000004 [ 4.058990] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.070353] SET = 0, FnV = 0 [ 4.073487] EA = 0, S1PTW = 0 [ 4.073501] dw-apb-uart 98007800.serial: forbid DMA for kernel console [ 4.076723] Data abort info: [ 4.086415] ISV = 0, ISS = 0x00000004 [ 4.087731] Freeing unused kernel memory: 1792K [ 4.090391] CM = 0, WnR = 0 [ 4.098091] [edafeaac9607952c] address between user and kernel address ranges [ 4.105418] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 4.111129] Modules linked in: [ 4.114275] CPU: 1 PID: 31 Comm: kworker/1:1 Not tainted 5.9.0-rc5-next-20200915+ #700 [ 4.122386] Hardware name: Realtek Saola EVB (DT) [ 4.127223] Workqueue: events request_firmware_work_func [ 4.132676] pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--) [ 4.138393] pc : rtw_load_firmware_cb+0x54/0xbc [ 4.143040] lr : request_firmware_work_func+0x44/0xb4 [ 4.148217] sp : ffff800010133d70 [ 4.151616] x29: ffff800010133d70 x28: 0000000000000000 [ 4.157069] x27: 0000000000000000 x26: 0000000000000000 [ 4.162520] x25: 0000000000000000 x24: 0000000000000000 [ 4.167971] x23: ffff00007ac21908 x22: ffff00007ebb2100 [ 4.173424] x21: ffff00007ad35880 x20: edafeaac96079504 [ 4.178877] x19: ffff00007ad35870 x18: 0000000000000000 [ 4.184328] x17: 00000000000044d8 x16: 0000000000004310 [ 4.189780] x15: 0000000000000800 x14: 00000000ef006305 [ 4.195231] x13: ffffffff00000000 x12: ffffffffffffffff [ 4.200682] x11: 0000000000000020 x10: 0000000000000003 [ 4.206135] x9 : 0000000000000000 x8 : ffff00007e73f680 [ 4.211585] x7 : 0000000000000000 x6 : ffff80001119b588 [ 4.217036] x5 : ffff00007e649c80 x4 : ffff00007e649c80 [ 4.222487] x3 : ffff80001119b588 x2 : ffff8000108d1718 [ 4.227940] x1 : ffff800011bd5000 x0 : ffff00007ac21600 [ 4.233391] Call trace: [ 4.235906] rtw_load_firmware_cb+0x54/0xbc [ 4.240198] request_firmware_work_func+0x44/0xb4 [ 4.245027] process_one_work+0x178/0x1e4 [ 4.249142] worker_thread+0x1d0/0x268 [ 4.252989] kthread+0xe8/0xf8 [ 4.256127] ret_from_fork+0x10/0x18 [ 4.259800] Code: f94013f5 a8c37bfd d65f03c0 f9000260 (f9401681) [ 4.266049] ---[ end trace f822ebae1a8545c2 ]--- To avoid this, wait on the completion callbacks in rtw_core_deinit() before releasing firmware and continuing teardown. Note that rtw_wait_firmware_completion() was introduced with c8e5695eae9959fc5774c0f490f2450be8bad3de ("rtw88: load wowlan firmware if wowlan is supported"), so backports to earlier branches may need to inline wait_for_completion(&rtwdev->fw.completion) instead. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported") Cc: Yan-Hsuan Chuang Signed-off-by: Andreas Färber Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200920132621.26468-2-afaerber@suse.de Signed-off-by: Sasha Levin commit 070f4562512ec4fd3ef9dc0cb0dbb5b24924cd3c Author: Martin Blumenstingl Date: Sat Jul 4 00:50:43 2020 +0200 usb: dwc2: Add missing cleanups when usb_add_gadget_udc() fails [ Upstream commit e1c08cf23172ed6fb228d75efc9f4c80a6812116 ] Call dwc2_debugfs_exit() and dwc2_hcd_remove() (if the HCD was enabled earlier) when usb_add_gadget_udc() has failed. This ensures that the debugfs entries created by dwc2_debugfs_init() as well as the HCD are cleaned up in the error path. Fixes: 207324a321a866 ("usb: dwc2: Postponed gadget registration to the udc class driver") Acked-by: Minas Harutyunyan Signed-off-by: Martin Blumenstingl Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 71db1c299091773c7f84d37c5fba7cce9e7f2d85 Author: Thinh Nguyen Date: Fri Jul 24 14:01:02 2020 -0700 usb: dwc3: core: Properly default unspecified speed [ Upstream commit b574ce3ee45937f4a01edc98c59213bfc7effe50 ] If the maximum_speed is not specified, default the device speed base on its HW capability. Don't prematurely check HW capability before validating the maximum_speed device property. The device property takes precedence in dwc->maximum_speed. Fixes: 0e1e5c47f7a9 ("usb: dwc3: add support for USB 2.0-only core configuration") Reported-by: Chunfeng Yun Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 47b571f572af8d9681fae7cfc50294a403c03e1a Author: Nathan Chancellor Date: Fri Jul 24 23:03:54 2020 -0700 usb: dwc2: Fix parameter type in function pointer prototype [ Upstream commit 362b9398c962c9ec563653444e15ef9032ef3a90 ] When booting up on a Raspberry Pi 4 with Control Flow Integrity checking enabled, the following warning/panic happens: [ 1.626435] CFI failure (target: dwc2_set_bcm_params+0x0/0x4): [ 1.632408] WARNING: CPU: 0 PID: 32 at kernel/cfi.c:30 __cfi_check_fail+0x54/0x5c [ 1.640021] Modules linked in: [ 1.643137] CPU: 0 PID: 32 Comm: kworker/0:1 Not tainted 5.8.0-rc6-next-20200724-00051-g89ba619726de #1 [ 1.652693] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT) [ 1.658637] Workqueue: events deferred_probe_work_func [ 1.663870] pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--) [ 1.669542] pc : __cfi_check_fail+0x54/0x5c [ 1.673798] lr : __cfi_check_fail+0x54/0x5c [ 1.678050] sp : ffff8000102bbaa0 [ 1.681419] x29: ffff8000102bbaa0 x28: ffffab09e21c7000 [ 1.686829] x27: 0000000000000402 x26: ffff0000f6e7c228 [ 1.692238] x25: 00000000fb7cdb0d x24: 0000000000000005 [ 1.697647] x23: ffffab09e2515000 x22: ffffab09e069a000 [ 1.703055] x21: 4c550309df1cf4c1 x20: ffffab09e2433c60 [ 1.708462] x19: ffffab09e160dc50 x18: ffff0000f6e8cc78 [ 1.713870] x17: 0000000000000041 x16: ffffab09e0bce6f8 [ 1.719278] x15: ffffab09e1c819b7 x14: 0000000000000003 [ 1.724686] x13: 00000000ffffefff x12: 0000000000000000 [ 1.730094] x11: 0000000000000000 x10: 00000000ffffffff [ 1.735501] x9 : c932f7abfc4bc600 x8 : c932f7abfc4bc600 [ 1.740910] x7 : 077207610770075f x6 : ffff0000f6c38f00 [ 1.746317] x5 : 0000000000000000 x4 : 0000000000000000 [ 1.751723] x3 : 0000000000000000 x2 : 0000000000000000 [ 1.757129] x1 : ffff8000102bb7d8 x0 : 0000000000000032 [ 1.762539] Call trace: [ 1.765030] __cfi_check_fail+0x54/0x5c [ 1.768938] __cfi_check+0x5fa6c/0x66afc [ 1.772932] dwc2_init_params+0xd74/0xd78 [ 1.777012] dwc2_driver_probe+0x484/0x6ec [ 1.781180] platform_drv_probe+0xb4/0x100 [ 1.785350] really_probe+0x228/0x63c [ 1.789076] driver_probe_device+0x80/0xc0 [ 1.793247] __device_attach_driver+0x114/0x160 [ 1.797857] bus_for_each_drv+0xa8/0x128 [ 1.801851] __device_attach.llvm.14901095709067289134+0xc0/0x170 [ 1.808050] bus_probe_device+0x44/0x100 [ 1.812044] deferred_probe_work_func+0x78/0xb8 [ 1.816656] process_one_work+0x204/0x3c4 [ 1.820736] worker_thread+0x2f0/0x4c4 [ 1.824552] kthread+0x174/0x184 [ 1.827837] ret_from_fork+0x10/0x18 CFI validates that all indirect calls go to a function with the same exact function pointer prototype. In this case, dwc2_set_bcm_params is the target, which has a parameter of type 'struct dwc2_hsotg *', but it is being implicitly cast to have a parameter of type 'void *' because that is the set_params function pointer prototype. Make the function pointer protoype match the definitions so that there is no more violation. Fixes: 7de1debcd2de ("usb: dwc2: Remove platform static params") Link: https://github.com/ClangBuiltLinux/linux/issues/1107 Signed-off-by: Nathan Chancellor Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit a0b5dbb0effc5d98e93911891b98041193760466 Author: Denis Efremov Date: Mon Sep 21 19:23:44 2020 +0300 net/mlx5e: IPsec: Use kvfree() for memory allocated with kvzalloc() [ Upstream commit 22db4c24452a6681c7e99c6a06b38b5418395bec ] Variables flow_group_in, spec in rx_fs_create() are allocated with kvzalloc(). It's incorrect to free them with kfree(). Use kvfree() instead. Fixes: 5e466345291a ("net/mlx5e: IPsec: Add IPsec steering in local NIC RX") Signed-off-by: Denis Efremov Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 1a0025211cfabbc89cd272ab57791f0c1eff0721 Author: Takashi Iwai Date: Tue Sep 22 10:38:56 2020 +0200 ALSA: seq: oss: Avoid mutex lock for a long-time ioctl [ Upstream commit 2759caad2600d503c3b0ed800e7e03d2cd7a4c05 ] Recently we applied a fix to cover the whole OSS sequencer ioctls with the mutex for dealing with the possible races. This works fine in general, but in theory, this may lead to unexpectedly long stall if an ioctl like SNDCTL_SEQ_SYNC is issued and an event with the far future timestamp was queued. For fixing such a potential stall, this patch changes the mutex lock applied conditionally excluding such an ioctl command. Also, change the mutex_lock() with the interruptible version for user to allow escaping from the big-hammer mutex. Fixes: 80982c7e834e ("ALSA: seq: oss: Serialize ioctls") Suggested-by: Pavel Machek Link: https://lore.kernel.org/r/20200922083856.28572-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2e6601d77a14e55252f7b52306a9de119adfc4d7 Author: Souptick Joarder Date: Sun Sep 20 08:21:35 2020 +0530 misc: mic: scif: Fix error handling path [ Upstream commit a81072a9c0ae734b7889929b0bc070fe3f353f0e ] Inside __scif_pin_pages(), when map_flags != SCIF_MAP_KERNEL it will call pin_user_pages_fast() to map nr_pages. However, pin_user_pages_fast() might fail with a return value -ERRNO. The return value is stored in pinned_pages->nr_pages. which in turn is passed to unpin_user_pages(), which expects pinned_pages->nr_pages >=0, else disaster. Fix this by assigning pinned_pages->nr_pages to 0 if pin_user_pages_fast() returns -ERRNO. Fixes: ba612aa8b487 ("misc: mic: SCIF memory registration and unregistration") Cc: John Hubbard Cc: Ira Weiny Cc: Dan Carpenter Reviewed-by: John Hubbard Signed-off-by: Souptick Joarder Link: https://lore.kernel.org/r/1600570295-29546-1-git-send-email-jrdr.linux@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ee306f90975bdbdd1ca6709f08516015c4246df6 Author: Necip Fazil Yildiran Date: Thu Sep 17 17:18:04 2020 +0300 ASoC: cros_ec_codec: fix kconfig dependency warning for SND_SOC_CROS_EC_CODEC [ Upstream commit 50b18e4a2608e3897f3787eaa7dfa869b40d9923 ] When SND_SOC_CROS_EC_CODEC is enabled and CRYPTO is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for CRYPTO_LIB_SHA256 Depends on [n]: CRYPTO [=n] Selected by [y]: - SND_SOC_CROS_EC_CODEC [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && CROS_EC [=y] The reason is that SND_SOC_CROS_EC_CODEC selects CRYPTO_LIB_SHA256 without depending on or selecting CRYPTO while CRYPTO_LIB_SHA256 is subordinate to CRYPTO. Honor the kconfig menu hierarchy to remove kconfig dependency warnings. Fixes: 93fa0af4790a ("ASoC: cros_ec_codec: switch to library API for SHA-256") Signed-off-by: Necip Fazil Yildiran Link: https://lore.kernel.org/r/20200917141803.92889-1-fazilyildiran@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit de2c2211d48f57efbabb03373019894e7a188924 Author: Andy Shevchenko Date: Tue Sep 22 14:58:46 2020 +0300 dmaengine: dmatest: Check list for emptiness before access its last entry [ Upstream commit b28de385b71abf31ce68ec0387638bee26ae9024 ] After writing a garbage to the channel we get an Oops in dmatest_chan_set() due to access to last entry in the empty list. [ 212.670672] BUG: unable to handle page fault for address: fffffff000000020 [ 212.677562] #PF: supervisor read access in kernel mode [ 212.682702] #PF: error_code(0x0000) - not-present page ... [ 212.710074] RIP: 0010:dmatest_chan_set+0x149/0x2d0 [dmatest] [ 212.715739] Code: e8 cc f9 ff ff 48 8b 1d 0d 55 00 00 48 83 7b 10 00 0f 84 63 01 00 00 48 c7 c7 d0 65 4d c0 e8 ee 4a f5 e1 48 89 c6 48 8b 43 10 <48> 8b 40 20 48 8b 78 58 48 85 ff 0f 84 f5 00 00 00 e8 b1 41 f5 e1 Fix this by checking list for emptiness before accessing its last entry. Fixes: d53513d5dc28 ("dmaengine: dmatest: Add support for multi channel testing") Cc: Vladimir Murzin Signed-off-by: Andy Shevchenko Tested-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20200922115847.30100-2-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d019791669abdbee2898a1ec1d52cba26bfd1532 Author: Tomasz Figa Date: Mon Sep 21 22:56:18 2020 +0000 phy: rockchip-dphy-rx0: Include linux/delay.h [ Upstream commit 488e3f52a82775bf9a4826a9eb59f10336c3f012 ] Fix an implicit declaration of usleep_range(): drivers/phy/rockchip/phy-rockchip-dphy-rx0.c: In function 'rk_dphy_enable': drivers/phy/rockchip/phy-rockchip-dphy-rx0.c:203:2: error: implicit declaration of function 'usleep_range' [-Werror=implicit-function-declaration] Fixes: 32abcc4491c62 ("media: staging: phy-rockchip-dphy-rx0: add Rockchip MIPI Synopsys DPHY RX0 driver") Signed-off-by: Tomasz Figa Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20200921225618.52529-1-tfiga@chromium.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 51b3ce36c34ef958691914f153d31dddf075a331 Author: Laurent Pinchart Date: Wed Sep 16 02:23:47 2020 +0300 drm: rcar-du: Put reference to VSP device [ Upstream commit 2a32dbdc2c7db5463483fa01fb220fd1b770c6bc ] The reference to the VSP device acquired with of_find_device_by_node() in rcar_du_vsp_init() is never released. Fix it with a drmm action, which gets run both in the probe error path and in the remove path. Fixes: 6d62ef3ac30b ("drm: rcar-du: Expose the VSP1 compositor through KMS planes") Reported-by: Yu Kuai Reviewed-by: Kieran Bingham Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit af4eadafa88506d3c4a4465b8af613f34e629c15 Author: Dan Carpenter Date: Fri Sep 18 17:27:32 2020 +0300 ath6kl: wmi: prevent a shift wrapping bug in ath6kl_wmi_delete_pstream_cmd() [ Upstream commit 6a950755cec1a90ddaaff3e4acb5333617441c32 ] The "tsid" is a user controlled u8 which comes from debugfs. Values more than 15 are invalid because "active_tsids" is a 16 bit variable. If the value of "tsid" is more than 31 then that leads to a shift wrapping bug. Fixes: 8fffd9e5ec9e ("ath6kl: Implement support for QOS-enable and QOS-disable from userspace") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200918142732.GA909725@mwanda Signed-off-by: Sasha Levin commit b35530d37faf15fad1306b37a2ac8fc190a89249 Author: Bo YU Date: Mon Sep 21 16:21:22 2020 +0300 ath11k: Add checked value for ath11k_ahb_remove [ Upstream commit 80b892fc8a90e91498babf0f6817139e5ec64b5c ] Return value form wait_for_completion_timeout should to be checked. This is detected by Coverity: #CID:1464479 (CHECKED_RETURN) Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Bo YU Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200621095136.7xdbzkthoxuw2qow@debian.debian-2 Signed-off-by: Sasha Levin commit b9ef3f32de06a7bc881b96aedea16bb75c62b1e4 Author: Aswath Govindraju Date: Thu Sep 10 17:56:24 2020 +0530 spi: omap2-mcspi: Improve performance waiting for CHSTAT [ Upstream commit 7b1d96813317358312440d0d07abbfbeb0ef8d22 ] This reverts commit 13d515c796 (spi: omap2-mcspi: Switch to readl_poll_timeout()). The amount of time spent polling for the MCSPI_CHSTAT bits to be set on AM335x-icev2 platform is less than 1us (about 0.6us) in most cases, with or without using DMA. So, in most cases the function need not sleep. Also, setting the sleep_usecs to zero would not be optimal here because ktime_add_us() used in readl_poll_timeout() is slower compared to the direct addition used after the revert. So, it is sub-optimal to use readl_poll_timeout in this case. When DMA is not enabled, this revert results in an increase of about 27% in throughput and decrease of about 20% in CPU usage. However, the CPU usage and throughput are almost the same when used with DMA. Therefore, fix this by reverting the commit which switched to using readl_poll_timeout(). Fixes: 13d515c796ad ("spi: omap2-mcspi: Switch to readl_poll_timeout()") Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20200910122624.8769-1-a-govindraju@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit de7d94b911655936e27e67d631282c28a393b0e5 Author: Dan Murphy Date: Fri Sep 18 14:05:44 2020 -0500 ASoC: tas2770: Fix unbalanced calls to pm_runtime [ Upstream commit d3d71c99b541040da198f43da3bbd85d8e9598cb ] Fix the unbalanced call to the pm_runtime_disable when removing the module. pm_runtime_enable is not called nor is the pm_runtime setup in the code. Remove the i2c_remove function and the pm_runtime_disable. Fixes: 1a476abc723e6 ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by: Dan Murphy Link: https://lore.kernel.org/r/20200918190548.12598-5-dmurphy@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9f83ae2e34110cf155f7e199cff60a9fcce058ab Author: Pierre-Louis Bossart Date: Mon Sep 21 14:08:12 2020 +0300 ASoC: SOF: control: add size checks for ext_bytes control .put() [ Upstream commit 2ca210112ad91880d2d5a3f85fecc838600afbce ] Make sure the TLV header and size are consistent before copying from userspace. Fixes: c3078f5397046 ('ASoC: SOF: Add Sound Open Firmware KControl support') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Guennadi Liakhovetski Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20200921110814.2910477-4-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 119eafcae390cbbbcfefb6d8763670ff421c57a2 Author: Linus Walleij Date: Sun Sep 20 22:37:33 2020 +0200 net: dsa: rtl8366rb: Support all 4096 VLANs [ Upstream commit a7920efdd86d8a0d74402dbc80ead03b023294ba ] There is an off-by-one error in rtl8366rb_is_vlan_valid() making VLANs 0..4094 valid while it should be 1..4095. Fix it. Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver") Signed-off-by: Linus Walleij Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f0e113225aa1d17b70653e8219d291856cefc9f0 Author: Miquel Raynal Date: Fri Sep 11 19:31:39 2020 +0200 ASoC: tlv320aic32x4: Fix bdiv clock rate derivation [ Upstream commit 40b37136287ba6b34aa2f1f6123f3d6d205dc2f0 ] Current code expects a single channel to be always used. Fix this situation by forwarding the number of channels used. Then fix the derivation of the bdiv clock rate. Fixes: 96c3bb00239d ("ASoC: tlv320aic32x4: Dynamically Determine Clocking") Suggested-by: Alexandre Belloni Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20200911173140.29984-3-miquel.raynal@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e2287628ff47207cdd3f8b0cfe8b6990b7562054 Author: Dan Murphy Date: Fri Sep 18 14:05:46 2020 -0500 ASoC: tas2770: Fix error handling with update_bits [ Upstream commit cadab0aefcbadf488b16caf2770430e69f4d7839 ] snd_soc_update_bits returns a 1 when the bit was successfully updated, returns a 0 is no update was needed and a negative if the call failed. The code is currently failing the case of a successful update by just checking for a non-zero number. Modify these checks and return the error code only if there is a negative. Fixes: 1a476abc723e6 ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by: Dan Murphy Link: https://lore.kernel.org/r/20200918190548.12598-7-dmurphy@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 31489948857876c702651c044b9a74ca5ee2fd16 Author: Dan Murphy Date: Fri Sep 18 14:05:43 2020 -0500 ASoC: tas2770: Fix required DT properties in the code [ Upstream commit 4b8ab8a7761fe2ba1c4e741703a848cb8f390f79 ] The devicetree binding indicates that the ti,asi-format, ti,imon-slot-no and ti,vmon-slot-no are not required but the driver requires them or it fails to probe. Honor the binding and allow these entries to be optional and set the corresponding values to the default values for each as defined in the data sheet. Fixes: 1a476abc723e6 ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by: Dan Murphy Link: https://lore.kernel.org/r/20200918190548.12598-4-dmurphy@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d746393cbff2f61cd24ad54c2baebda7c857af44 Author: Dan Murphy Date: Fri Sep 18 14:05:41 2020 -0500 ASoC: tas2770: Add missing bias level power states [ Upstream commit 4272caf34aa4699eca8e6e7f4a8e5ea2bde275c9 ] Add the BIAS_STANDBY and BIAS_PREPARE to the set_bias_level or else the driver will return -EINVAL which is not correct as they are valid states. Fixes: 1a476abc723e6 ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by: Dan Murphy Link: https://lore.kernel.org/r/20200918190548.12598-2-dmurphy@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e3e9401cdd76831c4f6c0509c2cda312c5bdc244 Author: Dan Murphy Date: Fri Sep 18 14:05:40 2020 -0500 ASoC: tas2770: Fix calling reset in probe [ Upstream commit b0bcbe615756d5923eec4e95996e4041627e5741 ] tas2770_reset is called during i2c probe. The reset calls the snd_soc_component_write which depends on the tas2770->component being available. The component pointer is not set until codec_probe so move the reset to the codec_probe after the pointer is set. Fixes: 1a476abc723e6 ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by: Dan Murphy Link: https://lore.kernel.org/r/20200918190548.12598-1-dmurphy@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2466d91f910133c83a4bf3b949d410e6b5c3b74c Author: Huang Guobin Date: Thu Sep 17 08:30:19 2020 -0400 net: wilc1000: clean up resource in error path of init mon interface [ Upstream commit 55bd149978679742374c800e56e8f6bc74378bbe ] The wilc_wfi_init_mon_int() forgets to clean up resource when register_netdevice() failed. Add the missed call to fix it. And the return value of netdev_priv can't be NULL, so remove the unnecessary error handling. Fixes: 588713006ea4 ("staging: wilc1000: avoid the use of 'wilc_wfi_mon' static variable") Reported-by: Hulk Robot Signed-off-by: Huang Guobin Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200917123019.206382-1-huangguobin4@huawei.com Signed-off-by: Sasha Levin commit fba1d6e97bf969ddf3c2f1e5aecb092a0970b9b6 Author: Linus Walleij Date: Sat Sep 19 00:29:54 2020 +0200 net: dsa: rtl8366: Skip PVID setting if not requested [ Upstream commit 3dfe8dde093a07e82fa472c0f8c29a7f6a2006a5 ] We go to lengths to determine whether the PVID should be set for this port or not, and then fail to take it into account. Fix this oversight. Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver") Signed-off-by: Linus Walleij Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dfa4a0fbfa05ca10bed1ce93d87a489bcdedb9e0 Author: Linus Walleij Date: Wed Sep 2 00:09:35 2020 +0200 net: dsa: rtl8366: Refactor VLAN/PVID init [ Upstream commit 7e1301ed1881447d2a25f9c6423738c33cbca133 ] The VLANs and PVIDs on the RTL8366 utilizes a "member configuration" (MC) which is largely unexplained in the code. This set-up requires a special ordering: rtl8366_set_pvid() must be called first, followed by rtl8366_set_vlan(), else the MC will not be properly allocated. Relax this by factoring out the code obtaining an MC and reuse the helper in both rtl8366_set_pvid() and rtl8366_set_vlan() so we remove this strict ordering requirement. In the process, add some better comments and debug prints so people who read the code understand what is going on. Reviewed-by: Florian Fainelli Signed-off-by: Linus Walleij Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c4e790dd5fdfcba657df3460418b6df7f9284520 Author: Linus Walleij Date: Wed Sep 2 00:09:34 2020 +0200 net: dsa: rtl8366: Check validity of passed VLANs [ Upstream commit 6641a2c42b0a307b7638d10e5d4b90debc61389d ] The rtl8366_set_vlan() and rtl8366_set_pvid() get invalid VLANs tossed at it, especially VLAN0, something the hardware and driver cannot handle. Check validity and bail out like we do in the other callbacks. Reviewed-by: Florian Fainelli Signed-off-by: Linus Walleij Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9fdd3a243c929e0420901f89d83645275093d4dc Author: Jordan Crouse Date: Tue Sep 15 10:35:51 2020 -0600 drm/msm: Fix the a650 hw_apriv check [ Upstream commit e9ba8d550dd1e28870a0bdc7c11af026c2a94702 ] Commit 604234f33658 ("drm/msm: Enable expanded apriv support for a650") was checking the result of adreno_is_a650() before the gpu revision got probed in adreno_gpu_init() so it was always coming across as false. Snoop into the revision ID ahead of time to correctly set the hw_apriv flag so that it can be used by msm_gpu to properly setup global buffers. Fixes: 604234f33658 ("drm/msm: Enable expanded apriv support for a650") Reported-by: Jonathan Marek Signed-off-by: Jordan Crouse Tested-by: Jonathan Marek Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit b9f538199ad2d45063ea2ac0ebb2b1691262f839 Author: Mathias Nyman Date: Fri Sep 18 16:17:51 2020 +0300 xhci: don't create endpoint debugfs entry before ring buffer is set. [ Upstream commit 167657a1bb5fcde53ac304ce6c564bd90a2f9185 ] Make sure xHC completes the configure endpoint command and xhci driver sets the ring pointers correctly before we create the user readable debugfs file. In theory there was a small gap where a user could have read the debugfs file and cause a NULL pointer dereference error as ring pointer was not yet set, in practise we want this change to simplify the upcoming streams debugfs support. Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver") Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200918131752.16488-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8ca3ea4167c844d7219460f54513f68fbc4bb727 Author: Sonny Sasaka Date: Fri Aug 14 12:09:09 2020 -0700 Bluetooth: Fix auto-creation of hci_conn at Conn Complete event [ Upstream commit a46b7ed4d52d09bd6c7ab53b2217d04fc2f02c65 ] Currently the code auto-creates hci_conn only if the remote address has been discovered before. This may not be the case. For example, the remote device may trigger connection after reboot at already-paired state so there is no inquiry result found, but it is still correct to create the hci_conn when Connection Complete event is received. A better guard is to check against bredr allowlist. Devices in the allowlist have been given permission to auto-connect. Fixes: 4f40afc6c764 ("Bluetooth: Handle BR/EDR devices during suspend") Signed-off-by: Sonny Sasaka Reviewed-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit c48c1447c88800afa2345b1942549806fb5916a4 Author: Ilya Leoshkevich Date: Tue Sep 15 13:39:28 2020 +0200 selftests/bpf: Fix endianness issue in test_sockopt_sk [ Upstream commit fec47bbc10b243690f5d0ee484a0bbdee273e71b ] getsetsockopt() calls getsockopt() with optlen == 1, but then checks the resulting int. It is ok on little endian, but not on big endian. Fix by checking char instead. Fixes: 8a027dc0d8f5 ("selftests/bpf: add sockopt test that exercises sk helpers") Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200915113928.3768496-1-iii@linux.ibm.com Signed-off-by: Sasha Levin commit 48e6cb8ef1db950894f8a0616c527c5c858b8b82 Author: Ilya Leoshkevich Date: Tue Sep 15 13:38:15 2020 +0200 selftests/bpf: Fix endianness issue in sk_assign [ Upstream commit b6ed6cf4a3acdeab9aed8e0a524850761ec9b152 ] server_map's value size is 8, but the test tries to put an int there. This sort of works on x86 (unless followed by non-0), but hard fails on s390. Fix by using __s64 instead of int. Fixes: 2d7824ffd25c ("selftests: bpf: Add test for sk_assign") Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200915113815.3768217-1-iii@linux.ibm.com Signed-off-by: Sasha Levin commit b608ffaee130d18525a3669d7cc382cf5bbe15b6 Author: Grygorii Strashko Date: Wed Sep 16 15:09:55 2020 +0300 dmaengine: ti: k3-udma-glue: fix channel enable functions [ Upstream commit 52c74d3d356b60f3c53dc69e5109752347e144e8 ] Now the K3 UDMA glue layer enable functions perform RMW operation on UDMA RX/TX RT_CTL registers to set EN bit and enable channel, which is incorrect, because only EN bit has to be set in those registers to enable channel (all other bits should be cleared 0). More over, this causes issues when bootloader leaves UDMA channel RX/TX RT_CTL registers in incorrect state - TDOWN bit set, for example. As result, UDMA channel will just perform teardown right after it's enabled. Hence, fix it by writing correct values (EN=1) directly in UDMA channel RX/TX RT_CTL registers in k3_udma_glue_enable_tx/rx_chn() functions. Fixes: d70241913413 ("dmaengine: ti: k3-udma: Add glue layer for non DMAengine users") Signed-off-by: Grygorii Strashko Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20200916120955.7963-1-grygorii.strashko@ti.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 2a269a394e75ba646bdc681cd1bca74031317796 Author: Matthieu Baerts Date: Wed Sep 16 15:13:51 2020 +0200 selftests: mptcp: interpret \n as a new line [ Upstream commit 8b974778f998ab1be23eca7436fc13d2d8c6bd59 ] In case of errors, this message was printed: (...) # read: Resource temporarily unavailable # client exit code 0, server 3 # \nnetns ns1-0-BJlt5D socket stat for 10003: (...) Obviously, the idea was to add a new line before the socket stat and not print "\nnetns". Fixes: b08fbf241064 ("selftests: add test-cases for MPTCP MP_JOIN") Fixes: 048d19d444be ("mptcp: add basic kselftest for mptcp") Signed-off-by: Matthieu Baerts Acked-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4215a33649f180de7de8dd1b4cfe31c9b1450915 Author: Vadym Kochan Date: Thu Sep 17 14:44:37 2020 +0100 nvmem: core: fix missing of_node_put() in of_nvmem_device_get() [ Upstream commit b1c194dcdb1425fa59eec61ab927cfff33096149 ] of_parse_phandle() returns device_node with incremented ref count which needs to be decremented by of_node_put() when device_node is not used. Fixes: e2a5402ec7c6 ("nvmem: Add nvmem_device based consumer apis.") Signed-off-by: Vadym Kochan Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200917134437.16637-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b29069aa8778528c6fe0b1c3e0b80b06363d1ed3 Author: Jonathan Zhou Date: Wed Sep 16 13:17:32 2020 -0600 coresight: etm4x: Fix issues on trcseqevr access [ Upstream commit 4cd83037cd957ad97756055355ab4ee63f259380 ] The TRCSEQEVR(3) is reserved, using '@nrseqstate - 1' instead to avoid accessing the reserved register. Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states") Cc: Mathieu Poirier Cc: Suzuki K Poulose Cc: Mike Leach Cc: Shaokun Zhang Signed-off-by: Jonathan Zhou [Fixed capital letter in title] Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200916191737.4001561-12-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ab333be05ffb166c840cbdbc13f62413fffcafd6 Author: Suzuki K Poulose Date: Wed Sep 16 13:17:31 2020 -0600 coresight: etm4x: Handle unreachable sink in perf mode [ Upstream commit 859d510e58dac94f0b204b7b5cccafbc130d2291 ] If the specified/hinted sink is not reachable from a subset of the CPUs, we could end up unable to trace the event on those CPUs. This is the best effort we could do until we support 1:1 configurations. Fail gracefully in such cases avoiding a WARN_ON, which can be easily triggered by the user on certain platforms (Arm N1SDP), with the following trace paths : CPU0 \ -- Funnel0 --> ETF0 --> / \ CPU1 \ MainFunnel CPU2 / \ / -- Funnel1 --> ETF1 --> / CPU1 $ perf record --per-thread -e cs_etm/@ETF0/u -- could trigger the following WARNING, when the event is scheduled on CPU2. [10919.513250] ------------[ cut here ]------------ [10919.517861] WARNING: CPU: 2 PID: 24021 at drivers/hwtracing/coresight/coresight-etm-perf.c:316 etm_event_start+0xf8/0x100 ... [10919.564403] CPU: 2 PID: 24021 Comm: perf Not tainted 5.8.0+ #24 [10919.570308] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--) [10919.575865] pc : etm_event_start+0xf8/0x100 [10919.580034] lr : etm_event_start+0x80/0x100 [10919.584202] sp : fffffe001932f940 [10919.587502] x29: fffffe001932f940 x28: fffffc834995f800 [10919.592799] x27: 0000000000000000 x26: fffffe0011f3ced0 [10919.598095] x25: fffffc837fce244c x24: fffffc837fce2448 [10919.603391] x23: 0000000000000002 x22: fffffc8353529c00 [10919.608688] x21: fffffc835bb31000 x20: 0000000000000000 [10919.613984] x19: fffffc837fcdcc70 x18: 0000000000000000 [10919.619281] x17: 0000000000000000 x16: 0000000000000000 [10919.624577] x15: 0000000000000000 x14: 00000000000009f8 [10919.629874] x13: 00000000000009f8 x12: 0000000000000018 [10919.635170] x11: 0000000000000000 x10: 0000000000000000 [10919.640467] x9 : fffffe00108cd168 x8 : 0000000000000000 [10919.645763] x7 : 0000000000000020 x6 : 0000000000000001 [10919.651059] x5 : 0000000000000002 x4 : 0000000000000001 [10919.656356] x3 : 0000000000000000 x2 : 0000000000000000 [10919.661652] x1 : fffffe836eb40000 x0 : 0000000000000000 [10919.666949] Call trace: [10919.669382] etm_event_start+0xf8/0x100 [10919.673203] etm_event_add+0x40/0x60 [10919.676765] event_sched_in.isra.134+0xcc/0x210 [10919.681281] merge_sched_in+0xb0/0x2a8 [10919.685017] visit_groups_merge.constprop.140+0x15c/0x4b8 [10919.690400] ctx_sched_in+0x15c/0x170 [10919.694048] perf_event_sched_in+0x6c/0xa0 [10919.698130] ctx_resched+0x60/0xa0 [10919.701517] perf_event_exec+0x288/0x2f0 [10919.705425] begin_new_exec+0x4c8/0xf58 [10919.709247] load_elf_binary+0x66c/0xf30 [10919.713155] exec_binprm+0x15c/0x450 [10919.716716] __do_execve_file+0x508/0x748 [10919.720711] __arm64_sys_execve+0x40/0x50 [10919.724707] do_el0_svc+0xf4/0x1b8 [10919.728095] el0_sync_handler+0xf8/0x124 [10919.732003] el0_sync+0x140/0x180 Even though we don't support using separate sinks for the ETMs yet (e.g, for 1:1 configurations), we should at least honor the user's choice and handle the limitations gracefully, by simply skipping the tracing on ETMs which can't reach the requested sink. Fixes: f9d81a657bb8 ("coresight: perf: Allow tracing on hotplugged CPUs") Cc: Mathieu Poirier Cc: Mike Leach Reported-by: Jeremy Linton Tested-by: Jeremy Linton Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200916191737.4001561-11-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1fc969438325ef70db18f81895673f544d6673f5 Author: Tingwei Zhang Date: Wed Sep 16 13:17:30 2020 -0600 coresight: cti: Write regsiters directly in cti_enable_hw() [ Upstream commit 984f37efa3857dcefa649fbdf64abb94591935c3 ] Deadlock as below is triggered by one CPU holds drvdata->spinlock and calls cti_enable_hw(). Smp_call_function_single() is called in cti_enable_hw() and tries to let another CPU write CTI registers. That CPU is trying to get drvdata->spinlock in cti_cpu_pm_notify() and doesn't response to IPI from smp_call_function_single(). [ 988.335937] CPU: 6 PID: 10258 Comm: sh Tainted: G W L 5.8.0-rc6-mainline-16783-gc38daa79b26b-dirty #1 [ 988.346364] Hardware name: Thundercomm Dragonboard 845c (DT) [ 988.352073] pstate: 20400005 (nzCv daif +PAN -UAO BTYPE=--) [ 988.357689] pc : smp_call_function_single+0x158/0x1b8 [ 988.362782] lr : smp_call_function_single+0x124/0x1b8 ... [ 988.451638] Call trace: [ 988.454119] smp_call_function_single+0x158/0x1b8 [ 988.458866] cti_enable+0xb4/0xf8 [coresight_cti] [ 988.463618] coresight_control_assoc_ectdev+0x6c/0x128 [coresight] [ 988.469855] coresight_enable+0x1f0/0x364 [coresight] [ 988.474957] enable_source_store+0x5c/0x9c [coresight] [ 988.480140] dev_attr_store+0x14/0x28 [ 988.483839] sysfs_kf_write+0x38/0x4c [ 988.487532] kernfs_fop_write+0x1c0/0x2b0 [ 988.491585] vfs_write+0xfc/0x300 [ 988.494931] ksys_write+0x78/0xe0 [ 988.498283] __arm64_sys_write+0x18/0x20 [ 988.502240] el0_svc_common+0x98/0x160 [ 988.506024] do_el0_svc+0x78/0x80 [ 988.509377] el0_sync_handler+0xd4/0x270 [ 988.513337] el0_sync+0x164/0x180 This change write CTI registers directly in cti_enable_hw(). Config->hw_powered has been checked to be true with spinlock holded. CTI is powered and can be programmed until spinlock is released. Fixes: 6a0953ce7de9 ("coresight: cti: Add CPU idle pm notifer to CTI devices") Signed-off-by: Tingwei Zhang [Re-ordered variable declaration] Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200916191737.4001561-10-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d2c3f2bf79af8fecbb6c75d754f8da42d89ec305 Author: Jonathan Zhou Date: Wed Sep 16 13:17:29 2020 -0600 coresight: etm4x: Fix issues within reset interface of sysfs [ Upstream commit 4020fc8d4658dc1dbc27c5644bcb6254caa05e5e ] The member @nr_addr_cmp is not a bool value, using operator '>' instead to avoid unexpected failure. Fixes: a77de2637c9e ("coresight: etm4x: moving sysFS entries to a dedicated file") Cc: Mathieu Poirier Cc: Suzuki K Poulose Cc: Mike Leach Cc: Shaokun Zhang Signed-off-by: Jonathan Zhou Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200916191737.4001561-9-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a74c97591079a734d958a4ad2b9e0d0f059870e7 Author: Mike Leach Date: Wed Sep 16 13:17:28 2020 -0600 coresight: etm4x: Ensure default perf settings filter user/kernel [ Upstream commit 096dcfb9cd6fefa7c03884b50c247593dc5f7dd3 ] Moving from using an address filter to trace the default "all addresses" range to no filtering to acheive the same result, has caused the perf filtering of kernel/user address spaces from not working unless an explicit address filter was used. This is due to the original code using a side-effect of the address filtering rather than setting the global TRCVICTLR exception level filtering. The use of the mode sysfs file is also similarly affected. A helper function is added to fix both instances. Fixes: ae2041510d5d ("coresight: etmv4: Update default filter and initialisation") Reported-by: Leo Yan Tested-by: Leo Yan Reviewed-by: Leo Yan Signed-off-by: Mike Leach Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200916191737.4001561-8-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8a988434456f0d6bac04377906d936a9b21837c8 Author: Tingwei Zhang Date: Wed Sep 16 13:17:27 2020 -0600 coresight: cti: remove pm_runtime_get_sync() from CPU hotplug [ Upstream commit 6e8836c6df5327bdb24211424f1ad1411d1ed64a ] Below BUG is triggered by call pm_runtime_get_sync() in cti_cpuhp_enable_hw(). It's in CPU hotplug callback with interrupt disabled. Pm_runtime_get_sync() calls clock driver to enable clock which could sleep. Remove pm_runtime_get_sync() in cti_cpuhp_enable_hw() since pm_runtime_get_sync() is called in cti_enabld and pm_runtime_put() is called in cti_disabled. No need to increase pm count when CPU gets online since it's not decreased when CPU is offline. [ 105.800279] BUG: scheduling while atomic: swapper/1/0/0x00000002 [ 105.800290] Modules linked in: [ 105.800327] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G W 5.9.0-rc1-gff1304be0a05-dirty #21 [ 105.800337] Hardware name: Thundercomm Dragonboard 845c (DT) [ 105.800353] Call trace: [ 105.800414] dump_backtrace+0x0/0x1d4 [ 105.800439] show_stack+0x14/0x1c [ 105.800462] dump_stack+0xc0/0x100 [ 105.800490] __schedule_bug+0x58/0x74 [ 105.800523] __schedule+0x590/0x65c [ 105.800538] schedule+0x78/0x10c [ 105.800553] schedule_timeout+0x188/0x250 [ 105.800585] qmp_send.constprop.10+0x12c/0x1b0 [ 105.800599] qmp_qdss_clk_prepare+0x18/0x20 [ 105.800622] clk_core_prepare+0x48/0xd4 [ 105.800639] clk_prepare+0x20/0x34 [ 105.800663] amba_pm_runtime_resume+0x54/0x90 [ 105.800695] __rpm_callback+0xdc/0x138 [ 105.800709] rpm_callback+0x24/0x78 [ 105.800724] rpm_resume+0x328/0x47c [ 105.800739] __pm_runtime_resume+0x50/0x74 [ 105.800768] cti_starting_cpu+0x40/0xa4 [ 105.800795] cpuhp_invoke_callback+0x84/0x1e0 [ 105.800814] notify_cpu_starting+0x9c/0xb8 [ 105.800834] secondary_start_kernel+0xd8/0x164 [ 105.800933] CPU1: Booted secondary processor 0x0000000100 [0x517f803c] Fixes: e9b880581d55 ("coresight: cti: Add CPU Hotplug handling to CTI driver") Reviewed-by: Mike Leach Signed-off-by: Tingwei Zhang Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200916191737.4001561-7-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6e95d6f1277e3dd8572cd991165a92b90eec6623 Author: Tingwei Zhang Date: Wed Sep 16 13:17:26 2020 -0600 coresight: cti: disclaim device only when it's claimed [ Upstream commit 0dee28268ddbe53a981d4d87faf5dc0f1700e698 ] Coresight_claim_device() is called in cti_starting_cpu() only when CTI is enabled while coresight_disclaim_device() is called uncontionally in cti_dying_cpu(). This triggered below WARNING. Only call disclaim device when CTI device is enabled to fix it. [ 75.989643] WARNING: CPU: 1 PID: 14 at kernel/drivers/hwtracing/coresight/coresight.c:209 coresight_disclaim_device_unlocked+0x10/0x24 [ 75.989697] CPU: 1 PID: 14 Comm: migration/1 Not tainted 5.9.0-rc1-gff1304be0a05-dirty #21 [ 75.989709] Hardware name: Thundercomm Dragonboard 845c (DT) [ 75.989737] pstate: 80c00085 (Nzcv daIf +PAN +UAO BTYPE=--) [ 75.989758] pc : coresight_disclaim_device_unlocked+0x10/0x24 [ 75.989775] lr : coresight_disclaim_device+0x24/0x38 [ 75.989783] sp : ffff800011cd3c90 . [ 75.990018] Call trace: [ 75.990041] coresight_disclaim_device_unlocked+0x10/0x24 [ 75.990066] cti_dying_cpu+0x34/0x4c [ 75.990101] cpuhp_invoke_callback+0x84/0x1e0 [ 75.990121] take_cpu_down+0x90/0xe0 [ 75.990154] multi_cpu_stop+0x134/0x160 [ 75.990171] cpu_stopper_thread+0xb0/0x13c [ 75.990196] smpboot_thread_fn+0x1c4/0x270 [ 75.990222] kthread+0x128/0x154 [ 75.990251] ret_from_fork+0x10/0x18 Fixes: e9b880581d55 ("coresight: cti: Add CPU Hotplug handling to CTI driver") Reviewed-by: Mike Leach Signed-off-by: Tingwei Zhang Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200916191737.4001561-6-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3a36c8709f1674368c4a1ccb95c9f66665f10ee5 Author: Mian Yousaf Kaukab Date: Wed Sep 16 13:17:24 2020 -0600 coresight: fix offset by one error in counting ports [ Upstream commit 9554c3551ed35d79b029e5e69383ae33117d9765 ] Since port-numbers start from 0, add 1 to port-number to get the port count. Fix following crash when Coresight is enabled on ACPI based systems: [ 61.061736] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... [ 61.135494] pc : acpi_coresight_parse_graph+0x1c4/0x37c [ 61.140705] lr : acpi_coresight_parse_graph+0x160/0x37c [ 61.145915] sp : ffff800012f4ba40 [ 61.145917] x29: ffff800012f4ba40 x28: ffff00becce62f98 [ 61.159896] x27: 0000000000000005 x26: ffff00becd8a7c88 [ 61.165195] x25: ffff00becd8a7d88 x24: ffff00becce62f80 [ 61.170492] x23: ffff800011ef99c0 x22: ffff009efb8bc010 [ 61.175790] x21: 0000000000000018 x20: 0000000000000005 [ 61.181087] x19: ffff00becce62e80 x18: 0000000000000020 [ 61.186385] x17: 0000000000000001 x16: 00000000000002a8 [ 61.191682] x15: ffff000838648550 x14: ffffffffffffffff [ 61.196980] x13: 0000000000000000 x12: ffff00becce62d87 [ 61.202277] x11: 00000000ffffff76 x10: 000000000000002e [ 61.207575] x9 : ffff8000107e1a68 x8 : ffff00becce63000 [ 61.212873] x7 : 0000000000000018 x6 : 000000000000003f [ 61.218170] x5 : 0000000000000000 x4 : 0000000000000000 [ 61.223467] x3 : 0000000000000000 x2 : 0000000000000000 [ 61.228764] x1 : ffff00becce62f80 x0 : 0000000000000000 [ 61.234062] Call trace: [ 61.236497] acpi_coresight_parse_graph+0x1c4/0x37c [ 61.241361] coresight_get_platform_data+0xdc/0x130 [ 61.246225] tmc_probe+0x138/0x2dc [ 61.246227] amba_probe+0xdc/0x220 [ 61.255779] really_probe+0xe8/0x49c [ 61.255781] driver_probe_device+0xec/0x140 [ 61.255782] device_driver_attach+0xc8/0xd0 [ 61.255785] __driver_attach+0xac/0x180 [ 61.265857] bus_for_each_dev+0x78/0xcc [ 61.265859] driver_attach+0x2c/0x40 [ 61.265861] bus_add_driver+0x150/0x244 [ 61.265863] driver_register+0x80/0x13c [ 61.273591] amba_driver_register+0x60/0x70 [ 61.273594] tmc_driver_init+0x20/0x2c [ 61.281582] do_one_initcall+0x50/0x230 [ 61.281585] do_initcalls+0x104/0x144 [ 61.291831] kernel_init_freeable+0x168/0x1dc [ 61.291834] kernel_init+0x1c/0x120 [ 61.299215] ret_from_fork+0x10/0x18 [ 61.299219] Code: b9400022 f9400660 9b277c42 8b020000 (f9400404) [ 61.307381] ---[ end trace 63c6c3d7ec6a9b7c ]--- [ 61.315225] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Fixes: d375b356e687 ("coresight: Fix support for sparsely populated ports") Reported-by: Ruediger Oertel Tested-by: Jeremy Linton Reviewed-by: Suzuki K Poulose Reviewed-by: Jeremy Linton Signed-off-by: Mian Yousaf Kaukab Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200916191737.4001561-4-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit edee28ac30e1f1aa760a433198f54533272b9245 Author: Sai Prakash Ranjan Date: Wed Sep 16 13:17:22 2020 -0600 coresight: etm4x: Fix etm4_count race by moving cpuhp callbacks to init [ Upstream commit 2d1a8bfb61ec0177343e99ebd745e3e4ceb0d0d5 ] etm4_count keeps track of number of ETMv4 registered and on some systems, a race is observed on etm4_count variable which can lead to multiple calls to cpuhp_setup_state_nocalls_cpuslocked(). This function internally calls cpuhp_store_callbacks() which prevents multiple registrations of callbacks for a given state and due to this race, it returns -EBUSY leading to ETM probe failures like below. coresight-etm4x: probe of 7040000.etm failed with error -16 This race can easily be triggered with async probe by setting probe type as PROBE_PREFER_ASYNCHRONOUS and with ETM power management property "arm,coresight-loses-context-with-cpu". Prevent this race by moving cpuhp callbacks to etm driver init since the cpuhp callbacks doesn't have to depend on the etm4_count and can be once setup during driver init. Similarly we move cpu_pm notifier registration to driver init and completely remove etm4_count usage. Also now we can use non cpuslocked version of cpuhp callbacks with this movement. Fixes: 9b6a3f3633a5 ("coresight: etmv4: Fix CPU power management setup in probe() function") Fixes: 58eb457be028 ("hwtracing/coresight-etm4x: Convert to hotplug state machine") Suggested-by: Suzuki K Poulose Tested-by: Stephen Boyd Reviewed-by: Stephen Boyd Reviewed-by: Suzuki K Poulose Signed-off-by: Sai Prakash Ranjan Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200916191737.4001561-2-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b56101a2fd7a27231d2ed6609e767fdc4ed9601b Author: Camel Guo Date: Tue Sep 8 11:04:17 2020 +0200 ASoC: tlv320adcx140: Fix digital gain range [ Upstream commit 73154aca4a03a2ab4833fd36683feb884af06d4b ] According to its datasheet, the digital gain should be -100 dB when CHx_DVOL is 1 and 27 dB when CHx_DVOL is 255. But with the current dig_vol_tlv, "Digital CHx Out Volume" shows 27.5 dB if CHx_DVOL is 255 and -95.5 dB if CHx_DVOL is 1. This commit fixes this bug. Fixes: 689c7655b50c ("ASoC: tlv320adcx140: Add the tlv320adcx140 codec driver family") Signed-off-by: Camel Guo Link: https://lore.kernel.org/r/20200908090417.16695-1-camel.guo@axis.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8592003afa46f4cc4550a66f6b15376d74d5f716 Author: Pierre-Louis Bossart Date: Thu Sep 17 13:39:12 2020 +0300 ASoC: topology: disable size checks for bytes_ext controls if needed [ Upstream commit 6788fc1a66a0c1d1cec7a0f84f94b517eae8611c ] When CONFIG_SND_CTL_VALIDATION is set, accesses to extended bytes control generate spurious error messages when the size exceeds 512 bytes, such as [ 11.224223] sof_sdw sof_sdw: control 2:0:0:EQIIR5.0 eqiir_coef_5:0: invalid count 1024 In addition the error check returns -EINVAL which has the nasty side effect of preventing applications accessing controls from working, e.g. root@plb:~# alsamixer cannot load mixer controls: Invalid argument It's agreed that the control interface has been abused since 2014, but forcing a check should not prevent existing solutions from working. This patch skips the checks conditionally if CONFIG_SND_CTL_VALIDATION is set and the byte array provided by topology is > 512. This preserves the checks for all other cases. Fixes: 1a3232d2f61d2 ('ASoC: topology: Add support for TLV bytes controls') BugLink: https://github.com/thesofproject/linux/issues/2430 Reported-by: Takashi Iwai Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Jaska Uimonen Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20200917103912.2565907-1-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 226af1832b2bfd3145576a50f39d5c9dcdfd16d9 Author: KP Singh Date: Wed Sep 16 18:02:42 2020 +0000 ima: Fix NULL pointer dereference in ima_file_hash [ Upstream commit aa662fc04f5b290b3979332588bf8d812b189962 ] ima_file_hash can be called when there is no iint->ima_hash available even though the inode exists in the integrity cache. It is fairly common for a file to not have a hash. (e.g. an mknodat, prior to the file being closed). Another example where this can happen (suggested by Jann Horn): Process A does: while(1) { unlink("/tmp/imafoo"); fd = open("/tmp/imafoo", O_RDWR|O_CREAT|O_TRUNC, 0700); if (fd == -1) { perror("open"); continue; } write(fd, "A", 1); close(fd); } and Process B does: while (1) { int fd = open("/tmp/imafoo", O_RDONLY); if (fd == -1) continue; char *mapping = mmap(NULL, 0x1000, PROT_READ|PROT_EXEC, MAP_PRIVATE, fd, 0); if (mapping != MAP_FAILED) munmap(mapping, 0x1000); close(fd); } Due to the race to get the iint->mutex between ima_file_hash and process_measurement iint->ima_hash could still be NULL. Fixes: 6beea7afcc72 ("ima: add the ability to query the cached hash of a given file") Signed-off-by: KP Singh Reviewed-by: Florent Revest Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 11a647dc4bf9696e49bb1952c14f17bcea3e17ba Author: Matthias Kaehlcke Date: Tue Sep 15 10:10:54 2020 -0700 cpufreq: qcom: Don't add frequencies without an OPP [ Upstream commit bc9b9c5ab9d8d16157737db539929d57562926e9 ] The driver currently adds all frequencies from the hardware LUT to the cpufreq table, regardless of whether the corresponding OPP exists. This prevents devices from disabling certain OPPs through the device tree and can result in CPU frequencies for which the interconnect bandwidth can't be adjusted. Only add frequencies with an OPP entry. Fixes: 55538fbc79e9 ("cpufreq: qcom: Read voltage LUT and populate OPP") Signed-off-by: Matthias Kaehlcke Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 52e4b2461fec4ce7b08f09d3eda21db88a9cdc2a Author: Stefan Agner Date: Tue Sep 8 16:16:54 2020 +0200 drm: mxsfb: check framebuffer pitch [ Upstream commit d5a0c816900419105a12e7471bf074319dfa34be ] The lcdif IP does not support a framebuffer pitch (stride) other than framebuffer width. Check for equality and reject the framebuffer otherwise. This prevents a distorted picture when using 640x800 and running the Mesa graphics stack. Mesa tries to use a cache aligned stride, which leads at that particular resolution to width != stride. Currently Mesa has no fallback behavior, but rejecting this configuration allows userspace to handle the issue correctly. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Stefan Agner Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20200908141654.266836-1-stefan@agner.ch Signed-off-by: Sasha Levin commit ca0b8604f355ad26a1bc901b103c65d8b64e8a78 Author: Pali Rohár Date: Mon Sep 7 15:27:16 2020 +0200 cpufreq: armada-37xx: Add missing MODULE_DEVICE_TABLE [ Upstream commit c942d1542f1bc5001216fabce9cb8ffbe515777e ] CONFIG_ARM_ARMADA_37XX_CPUFREQ is tristate option and therefore this cpufreq driver can be compiled as a module. This patch adds missing MODULE_DEVICE_TABLE which generates correct modalias for automatic loading of this cpufreq driver when is compiled as an external module. Reviewed-by: Andrew Lunn Signed-off-by: Pali Rohár Fixes: 92ce45fb875d7 ("cpufreq: Add DVFS support for Armada 37xx") [ Viresh: Added __maybe_unused ] Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 1c37441fbd67deed04dcb5161b4a02a0b4e31261 Author: Darrick J. Wong Date: Fri Sep 4 10:20:16 2020 -0700 xfs: force the log after remapping a synchronous-writes file [ Upstream commit 5ffce3cc22a0e89813ed0c7162a68b639aef9ab6 ] Commit 5833112df7e9 tried to make it so that a remap operation would force the log out to disk if the filesystem is mounted with mandatory synchronous writes. Unfortunately, that commit failed to handle the case where the inode or the file descriptor require mandatory synchronous writes. Refactor the check into into a helper that will look for all three conditions, and now we can treat reflink just like any other synchronous write. Fixes: 5833112df7e9 ("xfs: reflink should force the log out if mounted with wsync") Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2826999af28843c28a61564f31a319318e1ce76f Author: Ong Boon Leong Date: Tue Sep 15 09:28:40 2020 +0800 net: stmmac: use netif_tx_start|stop_all_queues() function [ Upstream commit 9f19306d166688a73356aa636c62e698bf2063cc ] The current implementation of stmmac_stop_all_queues() and stmmac_start_all_queues() will not work correctly when the value of tx_queues_to_use is changed through ethtool -L DEVNAME rx N tx M command. Also, netif_tx_start|stop_all_queues() are only needed in driver open() and close() only. Fixes: c22a3f48 net: stmmac: adding multiple napi mechanism Signed-off-by: Ong Boon Leong Signed-off-by: Voon Weifeng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 00cce96d6b5755436704e2721c9cdb0f7291dd1d Author: Aashish Verma Date: Tue Sep 15 09:28:39 2020 +0800 net: stmmac: Fix incorrect location to set real_num_rx|tx_queues [ Upstream commit 686cff3d7022ddf35d7e38bc80191eb92de5989a ] netif_set_real_num_tx_queues() & netif_set_real_num_rx_queues() should be used to inform network stack about the real Tx & Rx queue (active) number in both stmmac_open() and stmmac_resume(), therefore, we move the code from stmmac_dvr_probe() to stmmac_hw_setup(). Fixes: c02b7a914551 net: stmmac: use netif_set_real_num_{rx,tx}_queues Signed-off-by: Aashish Verma Signed-off-by: Ong Boon Leong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4a59ba934a50b1a11266e0825f221de843b48add Author: Tomas Henzl Date: Thu Sep 10 16:21:26 2020 +0200 scsi: mpt3sas: Fix sync irqs [ Upstream commit 45181eab8ba79ed7a41b549f00500c0093828521 ] _base_process_reply_queue() called from _base_interrupt() may schedule a new irq poll. Fix this by calling synchronize_irq() first. Also ensure that enable_irq() is called only when necessary to avoid "Unbalanced enable for IRQ..." errors. Link: https://lore.kernel.org/r/20200910142126.8147-1-thenzl@redhat.com Fixes: 320e77acb327 ("scsi: mpt3sas: Irq poll to avoid CPU hard lockups") Acked-by: Sreekanth Reddy Signed-off-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f24c986f0bbbdbfcf29a3ec729b6c5865d71db5e Author: Eran Ben Elisha Date: Tue Jun 16 12:07:10 2020 +0300 net/mlx5: Don't call timecounter cyc2time directly from 1PPS flow [ Upstream commit 0d2ffdc8d4002a62de31ff7aa3bef28c843c3cbe ] Before calling timecounter_cyc2time(), clock->lock must be taken. Use mlx5_timecounter_cyc2time instead which guarantees a safe access. Fixes: afc98a0b46d8 ("net/mlx5: Update ptp_clock_event foreach PPS event") Signed-off-by: Eran Ben Elisha Signed-off-by: Sasha Levin commit dddf90da126ffd1a1642a7c0c0dff604cdcb2609 Author: Moshe Tal Date: Thu Jul 16 14:59:30 2020 +0300 net/mlx5: Fix uninitialized variable warning [ Upstream commit 19f5b63bc9932d51292d72c9dc3ec95e5dfa2289 ] Add variable initialization to eliminate the warning "variable may be used uninitialized". Fixes: 5f29458b77d5 ("net/mlx5e: Support dump callback in TX reporter") Signed-off-by: Moshe Tal Reviewed-by: Aya Levin Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 10b6983089da208705d30c91d39da05393c75a25 Author: Ilya Leoshkevich Date: Thu Sep 10 01:21:41 2020 +0200 s390/bpf: Fix multiple tail calls [ Upstream commit d72714c1da138e6755d3bd14662dc5b7f17fae7f ] In order to branch around tail calls (due to out-of-bounds index, exceeding tail call count or missing tail call target), JIT uses label[0] field, which contains the address of the instruction following the tail call. When there are multiple tail calls, label[0] value comes from handling of a previous tail call, which is incorrect. Fix by getting rid of label array and resolving the label address locally: for all 3 branches that jump to it, emit 0 offsets at the beginning, and then backpatch them with the correct value. Also, do not use the long jump infrastructure: the tail call sequence is known to be short, so make all 3 jumps short. Fixes: 6651ee070b31 ("s390/bpf: implement bpf_tail_call() helper") Signed-off-by: Ilya Leoshkevich Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200909232141.3099367-1-iii@linux.ibm.com Signed-off-by: Sasha Levin commit 656cca4554068d4e000ff809cbb0cd382116ff3f Author: Luca Weiss Date: Fri Sep 11 18:08:53 2020 +0200 drm/msm/adreno: fix probe without iommu [ Upstream commit 0a48db562c6264da2ae8013491efd6e8dc780520 ] The function iommu_domain_alloc returns NULL on platforms without IOMMU such as msm8974. This resulted in PTR_ERR(-ENODEV) being assigned to gpu->aspace so the correct code path wasn't taken. Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization") Signed-off-by: Luca Weiss Reviewed-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 893e4a8ba9e09dfbe8389901f6c11413cda775b3 Author: Thierry Reding Date: Tue Aug 25 16:33:48 2020 +0200 pinctrl: devicetree: Keep deferring even on timeout [ Upstream commit 84f28fc38d2ff99e2ac623325ba37809da611b8e ] driver_deferred_probe_check_state() may return -ETIMEDOUT instead of -EPROBE_DEFER after all built-in drivers have been probed. This can cause issues for built-in drivers that depend on resources provided by loadable modules. One such case happens on Tegra where I2C controllers are used during early boot to set up the system PMIC, so the I2C driver needs to be a built-in driver. At the same time, some instances of the I2C controller depend on the DPAUX hardware for pinmuxing. Since the DPAUX is handled by the display driver, which is usually not built-in, the pin control states will not become available until after the root filesystem has been mounted and the display driver loaded from it. Fixes: bec6c0ecb243 ("pinctrl: Remove use of driver_deferred_probe_check_state_continue()") Suggested-by: John Stultz Signed-off-by: Thierry Reding Link: https://lore.kernel.org/r/20200825143348.1358679-1-thierry.reding@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 8cee225c097ce6e19cf4961155b5ab18ca5e0212 Author: Thomas Preston Date: Fri Aug 28 22:32:26 2020 +0100 pinctrl: mcp23s08: Fix mcp23x17 precious range [ Upstream commit b9b7fb29433b906635231d0a111224efa009198c ] On page 23 of the datasheet [0] it says "The register remains unchanged until the interrupt is cleared via a read of INTCAP or GPIO." Include INTCAPA and INTCAPB registers in precious range, so that they aren't accidentally cleared when we read via debugfs. [0] https://ww1.microchip.com/downloads/en/DeviceDoc/20001952C.pdf Fixes: 8f38910ba4f6 ("pinctrl: mcp23s08: switch to regmap caching") Signed-off-by: Thomas Preston Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200828213226.1734264-3-thomas.preston@codethink.co.uk Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ace60da23e06187cdd885495843366e878d92a06 Author: Thomas Preston Date: Fri Aug 28 22:32:25 2020 +0100 pinctrl: mcp23s08: Fix mcp23x17_regmap initialiser [ Upstream commit b445f6237744df5e8d4f56f8733b2108c611220a ] The mcp23x17_regmap is initialised with structs named "mcp23x16". However, the mcp23s08 driver doesn't support the MCP23016 device yet, so this appears to be a typo. Fixes: 8f38910ba4f6 ("pinctrl: mcp23s08: switch to regmap caching") Signed-off-by: Thomas Preston Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200828213226.1734264-2-thomas.preston@codethink.co.uk Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit dc68c0060f363e8d4a74d6d74a3f3fc75ab0a255 Author: Abhishek Pandit-Subedi Date: Wed Sep 9 16:53:59 2020 -0700 Bluetooth: Re-order clearing suspend tasks [ Upstream commit 3eec158d5eca7dd455118d9e00568aad2371219f ] Unregister_pm_notifier is a blocking call so suspend tasks should be cleared beforehand. Otherwise, the notifier will wait for completion before returning (and we encounter a 2s timeout on resume). Fixes: 0e9952804ec9c8 (Bluetooth: Clear suspend tasks on unregister) Signed-off-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit e7114c3ae3ddb7d359c9053c888d4c18b2ba7963 Author: Peilin Ye Date: Wed Sep 9 03:25:51 2020 -0400 Bluetooth: Fix memory leak in read_adv_mon_features() [ Upstream commit cafd472a10ff3bccd8afd25a69f20a491cd8d7b8 ] read_adv_mon_features() is leaking memory. Free `rp` before returning. Fixes: e5e1e7fd470c ("Bluetooth: Add handler of MGMT_OP_READ_ADV_MONITOR_FEATURES") Reported-and-tested-by: syzbot+f7f6e564f4202d8601c6@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=f7f6e564f4202d8601c6 Signed-off-by: Peilin Ye Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit ba187d7785b447403c9c4ddfe7de7574f2e545ab Author: Kees Cook Date: Wed Sep 9 14:17:00 2020 -0700 selftests/lkdtm: Use "comm" instead of "diff" for dmesg [ Upstream commit d00451c8118f8f7ab8e057bc6ee2f8b7d70b6a1c ] Instead of full GNU diff (which smaller boot environments may not have), use "comm" which is more available. Reported-by: Naresh Kamboju Cc: linux-kselftest@vger.kernel.org Fixes: f131d9edc29d ("selftests/lkdtm: Don't clear dmesg when running tests") Signed-off-by: Kees Cook Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20200909211700.2399399-1-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6b1a6db844f7db64d88ad6f3e484b9c2ededfccb Author: Matthew Wilcox (Oracle) Date: Thu Sep 10 08:26:18 2020 -0700 iomap: Mark read blocks uptodate in write_begin [ Upstream commit 14284fedf59f1647264f4603d64418cf1fcd3eb0 ] When bringing (portions of) a page uptodate, we were marking blocks that were zeroed as being uptodate, but not blocks that were read from storage. Like the previous commit, this problem was found with generic/127 and a kernel which failed readahead I/Os. This bug causes writes to be silently lost when working with flaky storage. Fixes: 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads") Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c7eea62406817c884fcc331d69aa049d23dfb72d Author: Matthew Wilcox (Oracle) Date: Thu Sep 10 08:26:17 2020 -0700 iomap: Clear page error before beginning a write [ Upstream commit e6e7ca92623a43156100306861272e04d46385fc ] If we find a page in write_begin which is !Uptodate, we need to clear any error on the page before starting to read data into it. This matches how filemap_fault(), do_read_cache_page() and generic_file_buffered_read() handle PageError on !Uptodate pages. When calling iomap_set_range_uptodate() in __iomap_write_begin(), blocks were not being marked as uptodate. This was found with generic/127 and a specially modified kernel which would fail (some) readahead I/Os. The test read some bytes in a prior page which caused readahead to extend into page 0x34. There was a subsequent write to page 0x34, followed by a read to page 0x34. Because the blocks were still marked as !Uptodate, the read caused all blocks to be re-read, overwriting the write. With this change, and the next one, the bytes which were written are marked as being Uptodate, so even though the page is still marked as !Uptodate, the blocks containing the written data are not re-read from storage. Fixes: 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads") Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 3536daa689aacf1b0a96c8e14225d098d72c04a8 Author: Steven Price Date: Wed Sep 9 13:29:57 2020 +0100 drm/panfrost: Ensure GPU quirks are always initialised [ Upstream commit 8c3c818c23a5bbce6ff180dd2ee04415241df77c ] The GPU 'CONFIG' registers used to work around hardware issues are cleared on reset so need to be programmed every time the GPU is reset. However panfrost_device_reset() failed to do this. To avoid this in future instead move the call to panfrost_gpu_init_quirks() to panfrost_gpu_power_on() so that the regsiters are always programmed just before the cores are powered. Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Signed-off-by: Steven Price Reviewed-by: Alyssa Rosenzweig Link: https://patchwork.freedesktop.org/patch/msgid/20200909122957.51667-1-steven.price@arm.com Signed-off-by: Sasha Levin commit 583d8e6b25abe775da68f922204a5d9bb7af4694 Author: Stephen Boyd Date: Tue Sep 1 14:59:41 2020 -0700 drm/msm: Avoid div-by-zero in dpu_crtc_atomic_check() [ Upstream commit 22f760941844dbcee6ee446e1896532f6dff01ef ] The cstate->num_mixers member is only set to a non-zero value once dpu_encoder_virt_mode_set() is called, but the atomic check function can be called by userspace before that. Let's avoid the div-by-zero here and inside _dpu_crtc_setup_lm_bounds() by skipping this part of the atomic check if dpu_encoder_virt_mode_set() hasn't been called yet. This fixes an UBSAN warning: UBSAN: Undefined behaviour in drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:860:31 division by zero CPU: 7 PID: 409 Comm: frecon Tainted: G S 5.4.31 #128 Hardware name: Google Trogdor (rev0) (DT) Call trace: dump_backtrace+0x0/0x14c show_stack+0x20/0x2c dump_stack+0xa0/0xd8 __ubsan_handle_divrem_overflow+0xec/0x110 dpu_crtc_atomic_check+0x97c/0x9d4 drm_atomic_helper_check_planes+0x160/0x1c8 drm_atomic_helper_check+0x54/0xbc drm_atomic_check_only+0x6a8/0x880 drm_atomic_commit+0x20/0x5c drm_atomic_helper_set_config+0x98/0xa0 drm_mode_setcrtc+0x308/0x5dc drm_ioctl_kernel+0x9c/0x114 drm_ioctl+0x2ac/0x4b0 drm_compat_ioctl+0xe8/0x13c __arm64_compat_sys_ioctl+0x184/0x324 el0_svc_common+0xa4/0x154 el0_svc_compat_handler+0x Cc: Abhinav Kumar Cc: Jeykumar Sankaran Cc: Jordan Crouse Cc: Sean Paul Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Stephen Boyd Reviewed-by: Abhinav Kumar Tested-by: Sai Prakash Ranjan Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit a7fb88ef8f0afbbe4b11043ed4e40fa4142347d2 Author: Dan Carpenter Date: Tue Sep 8 09:22:03 2020 +0300 ath11k: fix uninitialized return in ath11k_spectral_process_data() [ Upstream commit c7187acc3cd08a17e7b506b2b5277f42d1504d29 ] There is a success path where "ret" isn't initialized where we never have a ATH11K_SPECTRAL_TAG_SCAN_SEARCH and then ret isn't initialized. Fixes: 9d11b7bff950 ("ath11k: add support for spectral scan") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200619142922.GA267142@mwanda Signed-off-by: Sasha Levin commit 50932d25f94586f553d684950a69d45722f8af52 Author: Dan Carpenter Date: Mon Aug 24 11:57:35 2020 +0300 HID: roccat: add bounds checking in kone_sysfs_write_settings() [ Upstream commit d4f98dbfe717490e771b6e701904bfcf4b4557f0 ] This code doesn't check if "settings->startup_profile" is within bounds and that could result in an out of bounds array access. What the code does do is it checks if the settings can be written to the firmware, so it's possible that the firmware has a bounds check? It's safer and easier to verify when the bounds checking is done in the kernel. Fixes: 14bf62cde794 ("HID: add driver for Roccat Kone gaming mouse") Signed-off-by: Dan Carpenter Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 53f52983f0a16dab7e0548f0d5d4b72308a0f021 Author: Stanley Chu Date: Tue Sep 8 14:45:05 2020 +0800 scsi: ufs: ufs-mediatek: Fix HOST_PA_TACTIVATE quirk [ Upstream commit a3e40b80dc951057033dce86f0e675b2b822b513 ] Simply add HOST_PA_TACTIVATE quirk back since it was incorrectly removed before. Link: https://lore.kernel.org/r/20200908064507.30774-3-stanley.chu@mediatek.com Fixes: 47d054580a75 ("scsi: ufs-mediatek: fix HOST_PA_TACTIVATE quirk for Samsung UFS Devices") Signed-off-by: Stanley Chu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9bef57ce32a13141d817527dceebd932faa146fb Author: Stanley Chu Date: Tue Sep 8 14:45:04 2020 +0800 scsi: ufs: ufs-mediatek: Eliminate error message for unbound mphy [ Upstream commit 30a90782c105fe498df74161392aa143796b6886 ] Some MediaTek platforms does not have to bind MPHY so users shall not see any unnecessary logs. Simply remove logs for this case. Link: https://lore.kernel.org/r/20200908064507.30774-2-stanley.chu@mediatek.com Fixes: fc4983018fea ("scsi: ufs-mediatek: Allow unbound mphy") Signed-off-by: Stanley Chu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4a935335dd48dfbfa79f72013dd7023b02156622 Author: Yu Kuai Date: Tue Aug 25 21:02:24 2020 +0800 ASoC: fsl: imx-es8328: add missing put_device() call in imx_es8328_probe() [ Upstream commit e525db7e4b44c5b2b5aac0dad24e23cb58c54d22 ] if of_find_device_by_node() succeed, imx_es8328_probe() doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation. Fixes: 7e7292dba215 ("ASoC: fsl: add imx-es8328 machine driver") Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20200825130224.1488694-1-yukuai3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9306704dd32804ba87982bd4e3faeabe9beb41c4 Author: Dinghao Liu Date: Tue Aug 25 14:29:00 2020 +0800 video: fbdev: radeon: Fix memleak in radeonfb_pci_register [ Upstream commit fe6c6a4af2be8c15bac77f7ea160f947c04840d1 ] When radeon_kick_out_firmware_fb() fails, info should be freed just like the subsequent error paths. Fixes: 069ee21a82344 ("fbdev: Fix loading of module radeonfb on PowerMac") Signed-off-by: Dinghao Liu Reviewed-by: Mathieu Malaterre Cc: Kangjie Lu Cc: Benjamin Herrenschmidt Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20200825062900.11210-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin commit 86ac1d9ae05a41ee8afeaffeca5f1643439f0390 Author: Tom Rix Date: Wed Aug 5 07:52:08 2020 -0700 video: fbdev: sis: fix null ptr dereference [ Upstream commit ad6f93e9cd56f0b10e9b22e3e137d17a1a035242 ] Clang static analysis reports this representative error init.c:2501:18: warning: Array access (from variable 'queuedata') results in a null pointer dereference templ |= ((queuedata[i] & 0xc0) << 3); This is the problem block of code if(ModeNo > 0x13) { ... if(SiS_Pr->ChipType == SIS_730) { queuedata = &FQBQData730[0]; } else { queuedata = &FQBQData[0]; } } else { } queuedata is not set in the else block Reviewing the old code, the arrays FQBQData730 and FQBQData were used directly. So hoist the setting of queuedata out of the if-else block. Fixes: 544393fe584d ("[PATCH] sisfb update") Signed-off-by: Tom Rix Cc: Thomas Winischhofer Cc: Andrew Morton Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20200805145208.17727-1-trix@redhat.com Signed-off-by: Sasha Levin commit f96074dfd3f2bb93445cc276ecc9816cd7b4989d Author: Colin Ian King Date: Thu Jul 23 18:02:27 2020 +0100 video: fbdev: vga16fb: fix setting of pixclock because a pass-by-value error [ Upstream commit c72fab81ceaa54408b827a2f0486d9a0f4be34cf ] The pixclock is being set locally because it is being passed as a pass-by-value argument rather than pass-by-reference, so the computed pixclock is never being set in var->pixclock. Fix this by passing by reference. [This dates back to 2002, I found the offending commit from the git history git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git ] Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King Cc: Daniel Vetter Cc: Jani Nikula [b.zolnierkie: minor patch summary fixup] [b.zolnierkie: removed "Fixes:" tag (not in upstream tree)] Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20200723170227.996229-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit c2382e48a626334197b98ec7ee7c873d888b6cf7 Author: Tom Rix Date: Sun Sep 6 14:26:25 2020 -0700 ath11k: fix a double free and a memory leak [ Upstream commit 7e8453e35e406981d7c529ff8f804285bc894ba3 ] clang static analyzer reports this problem mac.c:6204:2: warning: Attempt to free released memory kfree(ar->mac.sbands[NL80211_BAND_2GHZ].channels); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The channels pointer is allocated in ath11k_mac_setup_channels_rates() When it fails midway, it cleans up the memory it has already allocated. So the error handling needs to skip freeing the memory. There is a second problem. ath11k_mac_setup_channels_rates(), allocates 3 channels. err_free misses releasing ar->mac.sbands[NL80211_BAND_6GHZ].channels Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Tom Rix Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200906212625.17059-1-trix@redhat.com Signed-off-by: Sasha Levin commit 7400fb6c4697bfc86f6ad9e70045687ad20cc970 Author: Edward Cree Date: Mon Sep 7 17:14:20 2020 +0100 sfc: don't double-down() filters in ef100_reset() [ Upstream commit 7dcc9d8a40f85cbd76acdebcc45ccdfe4a84337f ] dev_close(), by way of ef100_net_stop(), already brings down the filter table, so there's no need to do it again (which just causes lots of WARN_ONs). Similarly, don't bring it up ourselves, as dev_open() -> ef100_net_open() will do it, and will fail if it's already been brought up. Fixes: a9dc3d5612ce ("sfc_ef100: RX filter table management and related gubbins") Signed-off-by: Edward Cree Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a2cab4bc080e0663696603189ed4f4231045df60 Author: Souptick Joarder Date: Wed Sep 2 02:51:11 2020 +0530 drivers/virt/fsl_hypervisor: Fix error handling path [ Upstream commit 7f360bec37857bfd5a48cef21d86f58a09a3df63 ] First, when memory allocation for sg_list_unaligned failed, there is a bug of calling put_pages() as we haven't pinned any pages. Second, if get_user_pages_fast() failed we should unpin num_pinned pages. This will address both. As part of these changes, minor update in documentation. Fixes: 6db7199407ca ("drivers/virt: introduce Freescale hypervisor management driver") Signed-off-by: Souptick Joarder Reviewed-by: Dan Carpenter Reviewed-by: John Hubbard Link: https://lore.kernel.org/r/1598995271-6755-1-git-send-email-jrdr.linux@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 371faba94a4809ab17d7f31e1393a757214e9f24 Author: Hans de Goede Date: Thu Sep 3 13:23:24 2020 +0200 pwm: lpss: Add range limit check for the base_unit register value [ Upstream commit ef9f60daab309558c8bb3e086a9a11ee40bd6061 ] When the user requests a high enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value of 0. But according to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency. Adding 0 to the counter is a no-op. The data-sheet even explicitly states that writing 0 to the base_unit bits will result in the PWM outputting a continuous 0 signal. When the user requestes a low enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value which is bigger then base_unit_range - 1. Currently the codes for this deals with this by applying a mask: base_unit &= (base_unit_range - 1); But this means that we let the value overflow the range, we throw away the higher bits and store whatever value is left in the lower bits into the register leading to a random output frequency, rather then clamping the output frequency to the highest frequency which the hardware can do. This commit fixes both issues by clamping the base_unit value to be between 1 and (base_unit_range - 1). Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit") Reviewed-by: Andy Shevchenko Acked-by: Thierry Reding Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-5-hdegoede@redhat.com Signed-off-by: Sasha Levin commit ffbd23acd003de1bc5d89b0265cbc68b23f5ef24 Author: Hans de Goede Date: Thu Sep 3 13:23:23 2020 +0200 pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare() [ Upstream commit 181f4d2f44463fe09fe4df02e03095cb87151c29 ] According to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency. So assuming e.g. a 16 bit counter this means that if base_unit is set to 1, after 65535 input clock-cycles the counter has been increased from 0 to 65535 and it will overflow on the next cycle, so it will overflow after every 65536 clock cycles and thus the calculations done in pwm_lpss_prepare() should use 65536 and not 65535. This commit fixes this. Note this also aligns the calculations in pwm_lpss_prepare() with those in pwm_lpss_get_state(). Note this effectively reverts commit 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit"). The next patch in this series really fixes the potential overflow of the base_unit value. Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit") Reviewed-by: Andy Shevchenko Acked-by: Uwe Kleine-König Acked-by: Thierry Reding Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-4-hdegoede@redhat.com Signed-off-by: Sasha Levin commit e9ec11432a7f75bde9f5889b3fd03d7029884764 Author: Artem Savkov Date: Wed Sep 2 14:00:45 2020 +0200 pty: do tty_flip_buffer_push without port->lock in pty_write [ Upstream commit 71a174b39f10b4b93223d374722aa894b5d8a82e ] b6da31b2c07c "tty: Fix data race in tty_insert_flip_string_fixed_flag" puts tty_flip_buffer_push under port->lock introducing the following possible circular locking dependency: [30129.876566] ====================================================== [30129.876566] WARNING: possible circular locking dependency detected [30129.876567] 5.9.0-rc2+ #3 Tainted: G S W [30129.876568] ------------------------------------------------------ [30129.876568] sysrq.sh/1222 is trying to acquire lock: [30129.876569] ffffffff92c39480 (console_owner){....}-{0:0}, at: console_unlock+0x3fe/0xa90 [30129.876572] but task is already holding lock: [30129.876572] ffff888107cb9018 (&pool->lock/1){-.-.}-{2:2}, at: show_workqueue_state.cold.55+0x15b/0x6ca [30129.876576] which lock already depends on the new lock. [30129.876577] the existing dependency chain (in reverse order) is: [30129.876578] -> #3 (&pool->lock/1){-.-.}-{2:2}: [30129.876581] _raw_spin_lock+0x30/0x70 [30129.876581] __queue_work+0x1a3/0x10f0 [30129.876582] queue_work_on+0x78/0x80 [30129.876582] pty_write+0x165/0x1e0 [30129.876583] n_tty_write+0x47f/0xf00 [30129.876583] tty_write+0x3d6/0x8d0 [30129.876584] vfs_write+0x1a8/0x650 [30129.876588] -> #2 (&port->lock#2){-.-.}-{2:2}: [30129.876590] _raw_spin_lock_irqsave+0x3b/0x80 [30129.876591] tty_port_tty_get+0x1d/0xb0 [30129.876592] tty_port_default_wakeup+0xb/0x30 [30129.876592] serial8250_tx_chars+0x3d6/0x970 [30129.876593] serial8250_handle_irq.part.12+0x216/0x380 [30129.876593] serial8250_default_handle_irq+0x82/0xe0 [30129.876594] serial8250_interrupt+0xdd/0x1b0 [30129.876595] __handle_irq_event_percpu+0xfc/0x850 [30129.876602] -> #1 (&port->lock){-.-.}-{2:2}: [30129.876605] _raw_spin_lock_irqsave+0x3b/0x80 [30129.876605] serial8250_console_write+0x12d/0x900 [30129.876606] console_unlock+0x679/0xa90 [30129.876606] register_console+0x371/0x6e0 [30129.876607] univ8250_console_init+0x24/0x27 [30129.876607] console_init+0x2f9/0x45e [30129.876609] -> #0 (console_owner){....}-{0:0}: [30129.876611] __lock_acquire+0x2f70/0x4e90 [30129.876612] lock_acquire+0x1ac/0xad0 [30129.876612] console_unlock+0x460/0xa90 [30129.876613] vprintk_emit+0x130/0x420 [30129.876613] printk+0x9f/0xc5 [30129.876614] show_pwq+0x154/0x618 [30129.876615] show_workqueue_state.cold.55+0x193/0x6ca [30129.876615] __handle_sysrq+0x244/0x460 [30129.876616] write_sysrq_trigger+0x48/0x4a [30129.876616] proc_reg_write+0x1a6/0x240 [30129.876617] vfs_write+0x1a8/0x650 [30129.876619] other info that might help us debug this: [30129.876620] Chain exists of: [30129.876621] console_owner --> &port->lock#2 --> &pool->lock/1 [30129.876625] Possible unsafe locking scenario: [30129.876626] CPU0 CPU1 [30129.876626] ---- ---- [30129.876627] lock(&pool->lock/1); [30129.876628] lock(&port->lock#2); [30129.876630] lock(&pool->lock/1); [30129.876631] lock(console_owner); [30129.876633] *** DEADLOCK *** [30129.876634] 5 locks held by sysrq.sh/1222: [30129.876634] #0: ffff8881d3ce0470 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x359/0x650 [30129.876637] #1: ffffffff92c612c0 (rcu_read_lock){....}-{1:2}, at: __handle_sysrq+0x4d/0x460 [30129.876640] #2: ffffffff92c612c0 (rcu_read_lock){....}-{1:2}, at: show_workqueue_state+0x5/0xf0 [30129.876642] #3: ffff888107cb9018 (&pool->lock/1){-.-.}-{2:2}, at: show_workqueue_state.cold.55+0x15b/0x6ca [30129.876645] #4: ffffffff92c39980 (console_lock){+.+.}-{0:0}, at: vprintk_emit+0x123/0x420 [30129.876648] stack backtrace: [30129.876649] CPU: 3 PID: 1222 Comm: sysrq.sh Tainted: G S W 5.9.0-rc2+ #3 [30129.876649] Hardware name: Intel Corporation 2012 Client Platform/Emerald Lake 2, BIOS ACRVMBY1.86C.0078.P00.1201161002 01/16/2012 [30129.876650] Call Trace: [30129.876650] dump_stack+0x9d/0xe0 [30129.876651] check_noncircular+0x34f/0x410 [30129.876653] __lock_acquire+0x2f70/0x4e90 [30129.876656] lock_acquire+0x1ac/0xad0 [30129.876658] console_unlock+0x460/0xa90 [30129.876660] vprintk_emit+0x130/0x420 [30129.876660] printk+0x9f/0xc5 [30129.876661] show_pwq+0x154/0x618 [30129.876662] show_workqueue_state.cold.55+0x193/0x6ca [30129.876664] __handle_sysrq+0x244/0x460 [30129.876665] write_sysrq_trigger+0x48/0x4a [30129.876665] proc_reg_write+0x1a6/0x240 [30129.876666] vfs_write+0x1a8/0x650 It looks like the commit was aimed to protect tty_insert_flip_string and there is no need for tty_flip_buffer_push to be under this lock. Fixes: b6da31b2c07c ("tty: Fix data race in tty_insert_flip_string_fixed_flag") Signed-off-by: Artem Savkov Acked-by: Jiri Slaby Link: https://lore.kernel.org/r/20200902120045.3693075-1-asavkov@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8f68d61584ec87d1baef40b4ebceabf0930d4f2f Author: Tyrel Datwyler Date: Thu Aug 20 18:46:38 2020 -0500 tty: hvcs: Don't NULL tty->driver_data until hvcs_cleanup() [ Upstream commit 63ffcbdad738e3d1c857027789a2273df3337624 ] The code currently NULLs tty->driver_data in hvcs_close() with the intent of informing the next call to hvcs_open() that device needs to be reconfigured. However, when hvcs_cleanup() is called we copy hvcsd from tty->driver_data which was previoulsy NULLed by hvcs_close() and our call to tty_port_put(&hvcsd->port) doesn't actually do anything since &hvcsd->port ends up translating to NULL by chance. This has the side effect that when hvcs_remove() is called we have one too many port references preventing hvcs_destuct_port() from ever being called. This also prevents us from reusing the /dev/hvcsX node in a future hvcs_probe() and we can eventually run out of /dev/hvcsX devices. Fix this by waiting to NULL tty->driver_data in hvcs_cleanup(). Fixes: 27bf7c43a19c ("TTY: hvcs, add tty install") Signed-off-by: Tyrel Datwyler Link: https://lore.kernel.org/r/20200820234643.70412-1-tyreld@linux.ibm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 864d8f4297718e416a088649f0ca61ad7bb0df7a Author: Tong Zhang Date: Fri Aug 28 08:39:50 2020 -0400 tty: serial: earlycon dependency [ Upstream commit 0fb9342d06b0f667b915ba58bfefc030e534a218 ] parse_options() in drivers/tty/serial/earlycon.c calls uart_parse_earlycon in drivers/tty/serial/serial_core.c therefore selecting SERIAL_EARLYCON should automatically select SERIAL_CORE, otherwise will result in symbol not found error during linking if SERIAL_CORE is not configured as builtin Fixes: 9aac5887595b ("tty/serial: add generic serial earlycon") Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20200828123949.2642-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4a738a991168079e7ec37dc1671c1c5e23570210 Author: Pierre-Louis Bossart Date: Fri Sep 4 04:47:37 2020 +0800 soundwire: intel: fix NULL/ERR_PTR confusion [ Upstream commit 06dcb4e443643db93b286f861133785ca46f5a19 ] snd_soc_dai_get_sdw_stream() can only return the pointer to stream or an ERR_PTR value, NULL is not a possible value. Fixes: 09553140c8d7b ('soundwire: intel: implement get_sdw_stream() operations') Reported-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20200903204739.31206-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5ab6a769b9480e176d74558d2b501d1b4a5b3322 Author: Pierre-Louis Bossart Date: Fri Sep 4 04:47:36 2020 +0800 soundwire: stream: fix NULL/IS_ERR confusion [ Upstream commit 3471d2a192bace106e4da7bcdcdd5ebcca4267d2 ] snd_soc_dai_get_sdw_stream() can only return -ENOTSUPP or the stream, NULL is not a possible value. Fixes: 4550569bd779f ('soundwire: stream: add helper to startup/shutdown streams') Reported-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20200903204739.31206-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 76d2e56cef5502338239fa57840177acbdc952ce Author: Christian König Date: Wed Sep 2 11:07:14 2020 +0200 drm/amdgpu: fix max_entries calculation v4 [ Upstream commit ee354ff1c7c210fb41952ebf0a820fb714eae7b1 ] Calculate the correct value for max_entries or we might run after the page_address array. v2: Xinhui pointed out we don't need the shift v3: use local copy of start and simplify some calculation v4: fix the case that we map less VA range than BO size Signed-off-by: Christian König Fixes: 1e691e244487 drm/amdgpu: stop allocating dummy GTT nodes Reviewed-by: xinhui pan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e18e0361124d84f899877c6b891e8d7d0a20a1ff Author: Jann Horn Date: Thu Aug 6 18:53:59 2020 +0200 binder: Remove bogus warning on failed same-process transaction [ Upstream commit e8b8ae7ce32e17a5c29f0289e9e2a39c7dcaa1b8 ] While binder transactions with the same binder_proc as sender and recipient are forbidden, transactions with the same task_struct as sender and recipient are possible (even though currently there is a weird check in binder_transaction() that rejects them in the target==0 case). Therefore, task_struct identities can't be used to distinguish whether the caller is running in the context of the sender or the recipient. Since I see no easy way to make this WARN_ON() useful and correct, let's just remove it. Fixes: 44d8047f1d87 ("binder: use standard functions to allocate fds") Reported-by: syzbot+e113a0b970b7b3f394ba@syzkaller.appspotmail.com Acked-by: Christian Brauner Acked-by: Todd Kjos Signed-off-by: Jann Horn Link: https://lore.kernel.org/r/20200806165359.2381483-1-jannh@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 66766fa6fc35df9e01b78edaae74efdd4ba6897f Author: Eric Biggers Date: Tue Aug 25 19:10:40 2020 -0700 scsi: ufs: Make ufshcd_print_trs() consider UFSHCD_QUIRK_PRDT_BYTE_GRAN [ Upstream commit cc770ce34aeeff21991f162f0db1a758ea672727 ] Fix ufshcd_print_trs() to consider UFSHCD_QUIRK_PRDT_BYTE_GRAN when using utp_transfer_req_desc::prd_table_length, so that it doesn't treat the number of bytes as the number of entries. Originally from Kiwoong Kim (https://lkml.kernel.org/r/20200218233115.8185-1-kwmad.kim@samsung.com). Link: https://lore.kernel.org/r/20200826021040.152148-1-ebiggers@kernel.org Fixes: 26f968d7de82 ("scsi: ufs: Introduce UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk") Cc: Alim Akhtar Cc: Kiwoong Kim Signed-off-by: Eric Biggers Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 85cbc300f1ec9a7a24bb85b3aeeeaf188e05d48d Author: Anatoly Pugachev Date: Tue Jun 16 15:26:18 2020 +0300 selftests: vm: add fragment CONFIG_GUP_BENCHMARK [ Upstream commit cae1d5a2c5a491141faa747e9944ba40ab4ab786 ] When running gup_benchmark test the following output states that the config options is missing. $ sudo ./gup_benchmark open: No such file or directory $ sudo strace -e trace=file ./gup_benchmark 2>&1 | tail -3 openat(AT_FDCWD, "/sys/kernel/debug/gup_benchmark", O_RDWR) = -1 ENOENT (No such file or directory) open: No such file or directory +++ exited with 1 +++ Fix it by adding config option fragment. Fixes: 64c349f4ae78 ("mm: add infrastructure for get_user_pages_fast() benchmarking") Signed-off-by: Anatoly Pugachev CC: Jiri Kosina CC: Shuah Khan Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit f05e6bac38c3c1701caa716f257167dcc510f1fb Author: Abhishek Pandit-Subedi Date: Mon Aug 31 09:51:27 2020 -0700 Bluetooth: Clear suspend tasks on unregister [ Upstream commit 0e9952804ec9c8ba60f131225eab80634339f042 ] While unregistering, make sure to clear the suspend tasks before cancelling the work. If the unregister is called during resume from suspend, this will unnecessarily add 2s to the resume time otherwise. Fixes: 4e8c36c3b0d73d (Bluetooth: Fix suspend notifier race) Signed-off-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit df0e32bc6ee48a5525b1394864e8976dca0daa78 Author: Dinghao Liu Date: Wed Aug 19 16:22:28 2020 +0800 drm/crc-debugfs: Fix memleak in crc_control_write [ Upstream commit f7ec68b341dbd5da13d4c65ce444dcd605f1c42e ] When verify_crc_source() fails, source needs to be freed. However, current code is returning directly and ends up leaking memory. Fixes: d5cc15a0c66e ("drm: crc: Introduce verify_crc_source callback") Signed-off-by: Dinghao Liu Reviewed-by: Laurent Pinchart [danvet: change Fixes: tag per Laurent's review] Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200819082228.26847-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin commit c6f45c5b0717cec4c5f878606b33957e86838302 Author: Tyler Hicks Date: Tue Aug 11 14:26:21 2020 -0500 ima: Fail rule parsing when asymmetric key measurement isn't supportable [ Upstream commit 48ce1ddce16b0d1e3ff948da40a0d5125a4ee1a0 ] Measuring keys is currently only supported for asymmetric keys. In the future, this might change. For now, the "func=KEY_CHECK" and "keyrings=" options are only appropriate when CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS is enabled. Make this clear at policy load so that IMA policy authors don't assume that these policy language constructs are supported. Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy") Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys") Suggested-by: Nayna Jain Signed-off-by: Tyler Hicks Reviewed-by: Lakshmi Ramasubramanian Reviewed-by: Nayna Jain Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit cab6eb5189bb428d11e1a4a36a077d4830080320 Author: Tyler Hicks Date: Tue Aug 11 14:26:20 2020 -0500 ima: Pre-parse the list of keyrings in a KEY_CHECK rule [ Upstream commit 176377d97d6a3fae971ecb1f47d9b9cb7dab05ef ] The ima_keyrings buffer was used as a work buffer for strsep()-based parsing of the "keyrings=" option of an IMA policy rule. This parsing was re-performed each time an asymmetric key was added to a kernel keyring for each loaded policy rule that contained a "keyrings=" option. An example rule specifying this option is: measure func=KEY_CHECK keyrings=a|b|c The rule says to measure asymmetric keys added to any of the kernel keyrings named "a", "b", or "c". The size of the buffer size was equal to the size of the largest "keyrings=" value seen in a previously loaded rule (5 + 1 for the NUL-terminator in the previous example) and the buffer was pre-allocated at the time of policy load. The pre-allocated buffer approach suffered from a couple bugs: 1) There was no locking around the use of the buffer so concurrent key add operations, to two different keyrings, would result in the strsep() loop of ima_match_keyring() to modify the buffer at the same time. This resulted in unexpected results from ima_match_keyring() and, therefore, could cause unintended keys to be measured or keys to not be measured when IMA policy intended for them to be measured. 2) If the kstrdup() that initialized entry->keyrings in ima_parse_rule() failed, the ima_keyrings buffer was freed and set to NULL even when a valid KEY_CHECK rule was previously loaded. The next KEY_CHECK event would trigger a call to strcpy() with a NULL destination pointer and crash the kernel. Remove the need for a pre-allocated global buffer by parsing the list of keyrings in a KEY_CHECK rule at the time of policy load. The ima_rule_entry will contain an array of string pointers which point to the name of each keyring specified in the rule. No string processing needs to happen at the time of asymmetric key add so iterating through the list and doing a string comparison is all that's required at the time of policy check. In the process of changing how the "keyrings=" policy option is handled, a couple additional bugs were fixed: 1) The rule parser accepted rules containing invalid "keyrings=" values such as "a|b||c", "a|b|", or simply "|". 2) The /sys/kernel/security/ima/policy file did not display the entire "keyrings=" value if the list of keyrings was longer than what could fit in the fixed size tbuf buffer in ima_policy_show(). Fixes: 5c7bac9fb2c5 ("IMA: pre-allocate buffer to hold keyrings string") Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy") Signed-off-by: Tyler Hicks Reviewed-by: Lakshmi Ramasubramanian Reviewed-by: Nayna Jain Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit d4b85682ccb38da3b75d18d24c898534fef8c0aa Author: Weqaar Janjua Date: Sat Aug 29 00:17:17 2020 +0800 samples/bpf: Fix to xdpsock to avoid recycling frames [ Upstream commit b69e56cf765155dcac0037d7d0f162a2afab76c2 ] The txpush program in the xdpsock sample application is supposed to send out all packets in the umem in a round-robin fashion. The problem is that it only cycled through the first BATCH_SIZE worth of packets. Fixed this so that it cycles through all buffers in the umem as intended. Fixes: 248c7f9c0e21 ("samples/bpf: convert xdpsock to use libbpf for AF_XDP access") Signed-off-by: Weqaar Janjua Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20200828161717.42705-1-weqaar.a.janjua@intel.com Signed-off-by: Sasha Levin commit eecfb4f59d9f96b98b4544bfb36eff5198f4128e Author: Laurent Pinchart Date: Mon Aug 24 03:32:54 2020 +0300 drm: panel: Fix bpc for OrtusTech COM43H4M85ULC panel [ Upstream commit 3b8095169982ff4ec2a1b4be61b7224bbef23b48 ] The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel. Commit f098f168e91c ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panel") has fixed the bus formats, but forgot to address the bpc value. Set it to 6. Fixes: f098f168e91c ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panel") Signed-off-by: Laurent Pinchart Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200824003254.21904-1-laurent.pinchart@ideasonboard.com Signed-off-by: Sasha Levin commit e91d7ff362797a261c93698bd8ef655db15a9dae Author: Alexei Starovoitov Date: Thu Aug 27 15:01:10 2020 -0700 mm/error_inject: Fix allow_error_inject function signatures. [ Upstream commit 76cd61739fd107a7f7ec4c24a045e98d8ee150f0 ] 'static' and 'static noinline' function attributes make no guarantees that gcc/clang won't optimize them. The compiler may decide to inline 'static' function and in such case ALLOW_ERROR_INJECT becomes meaningless. The compiler could have inlined __add_to_page_cache_locked() in one callsite and didn't inline in another. In such case injecting errors into it would cause unpredictable behavior. It's worse with 'static noinline' which won't be inlined, but it still can be optimized. Like the compiler may decide to remove one argument or constant propagate the value depending on the callsite. To avoid such issues make sure that these functions are global noinline. Fixes: af3b854492f3 ("mm/page_alloc.c: allow error injection") Fixes: cfcbfb1382db ("mm/filemap.c: enable error injection at add_to_page_cache()") Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Reviewed-by: Josef Bacik Link: https://lore.kernel.org/bpf/20200827220114.69225-2-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin commit 0fabd299429c6995fab73fe9c9ffb22c98458be5 Author: Alex Dewar Date: Tue Aug 25 17:45:18 2020 +0100 VMCI: check return value of get_user_pages_fast() for errors [ Upstream commit 90ca6333fd65f318c47bff425e1ea36c0a5539f6 ] In a couple of places in qp_host_get_user_memory(), get_user_pages_fast() is called without properly checking for errors. If e.g. -EFAULT is returned, this negative value will then be passed on to qp_release_pages(), which expects a u64 as input. Fix this by only calling qp_release_pages() when we have a positive number returned. Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") Signed-off-by: Alex Dewar Link: https://lore.kernel.org/r/20200825164522.412392-1-alex.dewar90@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2bef3040193868ed1fe6a697527007c6640aae2e Author: Alex Dewar Date: Tue Aug 25 10:19:28 2020 +0100 staging: emxx_udc: Fix passing of NULL to dma_alloc_coherent() [ Upstream commit cc34073c6248e9cec801bf690d1455f264d12357 ] In nbu2ss_eq_queue() memory is allocated with dma_alloc_coherent(), though, strangely, NULL is passed as the struct device* argument. Pass the UDC's device instead. Fix up the corresponding call to dma_free_coherent() in the same way. Build-tested on x86 only. Fixes: 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile USB Gadget driver") Reported-by: Dan Carpenter Signed-off-by: Alex Dewar Link: https://lore.kernel.org/r/20200825091928.55794-1-alex.dewar90@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 752414234ee737b31b3b075b5b9b5363da9e4a60 Author: Jérôme Pouiller Date: Tue Aug 25 10:58:23 2020 +0200 staging: wfx: fix frame reordering [ Upstream commit 7373f31c4b5e382e5117b71a6792e8005c45aa50 ] When mac80211 debug is enabled, the trace below appears: [60744.340037] wlan0: Rx A-MPDU request on aa:bb:cc:97:60:24 tid 0 result -524 This imply that ___ieee80211_start_rx_ba_session will prematurely exit and frame reordering won't be enabled. Fixes: e5da5fbd77411 ("staging: wfx: fix CCMP/TKIP replay protection") Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20200825085828.399505-7-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2c0e02f1d60875270f102acc402992e6018c5c93 Author: dinghao.liu@zju.edu.cn Date: Thu Aug 20 14:38:17 2020 +0800 backlight: sky81452-backlight: Fix refcount imbalance on error [ Upstream commit b7a4f80bc316a56d6ec8750e93e66f42431ed960 ] When of_property_read_u32_array() returns an error code, a pairing refcount decrement is needed to keep np's refcount balanced. Fixes: f705806c9f355 ("backlight: Add support Skyworks SKY81452 backlight driver") Signed-off-by: Dinghao Liu Reviewed-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit cd0fdb5c88b9616b163bd58dfc96862d13e3fe8c Author: Miroslav Benes Date: Thu Aug 27 13:07:09 2020 +0200 selftests/livepatch: Do not check order when using "comm" for dmesg checking [ Upstream commit 884ee754f5aedbe54406a4d308a6cc57335747ce ] check_result() uses "comm" to check expected results of selftests output in dmesg. Everything works fine if timestamps in dmesg are unique. If not, like in this example [ 86.844422] test_klp_callbacks_demo: pre_unpatch_callback: test_klp_callbacks_mod -> [MODULE_STATE_LIVE] Normal state [ 86.844422] livepatch: 'test_klp_callbacks_demo': starting unpatching transition , "comm" fails with "comm: file 2 is not in sorted order". Suppress the order checking with --nocheck-order option. Fixes: 2f3f651f3756 ("selftests/livepatch: Use "comm" instead of "diff" for dmesg") Signed-off-by: Miroslav Benes Acked-by: Joe Lawrence Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 9296dcc4055b440947c616b19e8e771495e19b24 Author: Brian Norris Date: Fri Aug 21 14:17:16 2020 -0700 rtw88: don't treat NULL pointer as an array [ Upstream commit 22b726cbdd09d9891ede8aa122a950d2d0ae5e09 ] I'm not a standards expert, but this really looks to be undefined behavior, when chip->dig_cck may be NULL. (And, we're trying to do a NULL check a few lines down, because some chip variants will use NULL.) Fixes: fc637a860a82 ("rtw88: 8723d: Set IG register for CCK rate") Signed-off-by: Brian Norris Acked-by: Yan-Hsuan Chuang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200821211716.1631556-1-briannorris@chromium.org Signed-off-by: Sasha Levin commit f09ff7a5cc375e4560efd7be47d4225e00993d37 Author: Dinghao Liu Date: Thu Aug 20 13:52:56 2020 +0800 wilc1000: Fix memleak in wilc_bus_probe [ Upstream commit 9a19a939abfa7d949f584a7ad872e683473fdc14 ] When devm_clk_get() returns -EPROBE_DEFER, spi_priv should be freed just like when wilc_cfg80211_init() fails. Fixes: 854d66df74aed ("staging: wilc1000: look for rtc_clk clock in spi mode") Signed-off-by: Dinghao Liu Acked-by: Ajay Singh Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200820055256.24333-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin commit a00a3ad966fb00201420a70a6a6ab0be525c3d04 Author: Dinghao Liu Date: Thu Aug 20 13:48:19 2020 +0800 wilc1000: Fix memleak in wilc_sdio_probe [ Upstream commit 8d95ab34b21ee0f870a9185b6457e8f6eb54914c ] When devm_clk_get() returns -EPROBE_DEFER, sdio_priv should be freed just like when wilc_cfg80211_init() fails. Fixes: 8692b047e86cf ("staging: wilc1000: look for rtc_clk clock") Signed-off-by: Dinghao Liu Acked-by: Ajay Singh Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200820054819.23365-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin commit f0ba7b6604c670daaaaf6ff3d9c57f04260c2ff4 Author: Alex Gartrell Date: Wed Aug 26 00:55:49 2020 -0700 libbpf: Fix unintentional success return code in bpf_object__load [ Upstream commit ef05afa66c59c2031a3798916ef3ff3778232129 ] There are code paths where EINVAL is returned directly without setting errno. In that case, errno could be 0, which would mask the failure. For example, if a careless programmer set log_level to 10000 out of laziness, they would have to spend a long time trying to figure out why. Fixes: 4f33ddb4e3e2 ("libbpf: Propagate EPERM to caller on program load") Signed-off-by: Alex Gartrell Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200826075549.1858580-1-alexgartrell@gmail.com Signed-off-by: Sasha Levin commit 7942b610438e7f4d19183ad24233d5390a7ae6a0 Author: Tianjia Zhang Date: Sun Aug 2 19:15:31 2020 +0800 scsi: csiostor: Fix wrong return value in csio_hw_prep_fw() [ Upstream commit 44f4daf8678ae5f08c93bbe70792f90cd88e4649 ] On an error exit path, a negative error code should be returned instead of a positive return value. Link: https://lore.kernel.org/r/20200802111531.5065-1-tianjia.zhang@linux.alibaba.com Fixes: f40e74ffa3de ("csiostor:firmware upgrade fix") Cc: Praveen Madhavan Signed-off-by: Tianjia Zhang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e4e0dc688e14990ea769f458cd2cf3a01d7c97cf Author: Tianjia Zhang Date: Sun Aug 2 19:15:30 2020 +0800 scsi: qla2xxx: Fix wrong return value in qla_nvme_register_hba() [ Upstream commit ca4fb89a3d714a770e9c73c649da830f3f4a5326 ] On an error exit path, a negative error code should be returned instead of a positive return value. Link: https://lore.kernel.org/r/20200802111530.5020-1-tianjia.zhang@linux.alibaba.com Fixes: 8777e4314d39 ("scsi: qla2xxx: Migrate NVME N2N handling into state machine") Cc: Quinn Tran Signed-off-by: Tianjia Zhang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6bfd875e02c02c4843f319dabb872b0fb75065fb Author: Tianjia Zhang Date: Sun Aug 2 19:15:28 2020 +0800 scsi: qla2xxx: Fix wrong return value in qlt_chk_unresolv_exchg() [ Upstream commit bbf2d06a9d767718bfe6028d6288c03edb98554a ] In the case of a failed retry, a positive value EIO is returned here. I think this is a typo error. It is necessary to return an error value. [mkp: caller checks != 0 but the rest of the file uses -Exxx so fix this up to be consistent] Link: https://lore.kernel.org/r/20200802111528.4974-1-tianjia.zhang@linux.alibaba.com Fixes: 0691094ff3f2 ("scsi: qla2xxx: Add logic to detect ABTS hang and response completion") Cc: Quinn Tran Signed-off-by: Tianjia Zhang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e66701fe09047a654977680efb0f4743dae8cbd7 Author: Christophe JAILLET Date: Sun Aug 2 13:07:21 2020 +0200 scsi: qla2xxx: Fix the size used in a 'dma_free_coherent()' call [ Upstream commit 650b323c8e7c3ac4830a20895b1d444fd68dd787 ] Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()'. [mkp: removed memset() hunk that has already been addressed] Link: https://lore.kernel.org/r/20200802110721.677707-1-christophe.jaillet@wanadoo.fr Fixes: 4161cee52df8 ("[SCSI] qla4xxx: Add host statistics support") Signed-off-by: Christophe JAILLET Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8989076c8ab514db6aabddc8606d4e2e28faf3f8 Author: Christophe JAILLET Date: Sun Aug 2 12:15:27 2020 +0200 scsi: qla4xxx: Fix an error handling path in 'qla4xxx_get_host_stats()' [ Upstream commit 574918e69720fe62ab3eb42ec3750230c8d16b06 ] Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()'. Link: https://lore.kernel.org/r/20200802101527.676054-1-christophe.jaillet@wanadoo.fr Fixes: 4161cee52df8 ("[SCSI] qla4xxx: Add host statistics support") Signed-off-by: Christophe JAILLET Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0e512941e64576ccf4f68dfc1d1584282f902d7c Author: Tom Rix Date: Wed Aug 5 13:59:11 2020 -0700 drm/gma500: fix error check [ Upstream commit cdd296cdae1af2d27dae3fcfbdf12c5252ab78cf ] Reviewing this block of code in cdv_intel_dp_init() ret = cdv_intel_dp_aux_native_read(gma_encoder, DP_DPCD_REV, ... cdv_intel_edp_panel_vdd_off(gma_encoder); if (ret == 0) { /* if this fails, presume the device is a ghost */ DRM_INFO("failed to retrieve link info, disabling eDP\n"); drm_encoder_cleanup(encoder); cdv_intel_dp_destroy(connector); goto err_priv; } else { The (ret == 0) is not strict enough. cdv_intel_dp_aux_native_read() returns > 0 on success otherwise it is failure. So change to <= Fixes: d112a8163f83 ("gma500/cdv: Add eDP support") Signed-off-by: Tom Rix Signed-off-by: Patrik Jakobsson Link: https://patchwork.freedesktop.org/patch/msgid/20200805205911.20927-1-trix@redhat.com Signed-off-by: Sasha Levin commit 503f6d52c7884dd54253e7d13eda5430a7d7220b Author: Andrii Nakryiko Date: Tue Aug 18 14:33:54 2020 -0700 selftests/bpf: Fix test_vmlinux test to use bpf_probe_read_user() [ Upstream commit 02f47faa25db134f6043fb6b12a68b5d4c980bb6 ] The test is reading UAPI kernel structure from user-space. So it doesn't need CO-RE relocations and has to use bpf_probe_read_user(). Fixes: acbd06206bbb ("selftests/bpf: Add vmlinux.h selftest exercising tracing of syscalls") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200818213356.2629020-6-andriin@fb.com Signed-off-by: Sasha Levin commit 0de02b9f051fc0ad7dd4f19bfd5a766765e8a0a1 Author: Colin Ian King Date: Tue Aug 18 13:09:14 2020 +0100 drm/amd/display: fix potential integer overflow when shifting 32 bit variable bl_pwm [ Upstream commit 1d5503331b12a76266049289747dfd94f1643fde ] The 32 bit unsigned integer bl_pwm is being shifted using 32 bit arithmetic and then being assigned to a 64 bit unsigned integer. There is a potential for a 32 bit overflow so cast bl_pwm to enforce a 64 bit shift operation to avoid this. Addresses-Coverity: ("unintentional integer overflow") Fixes: 3ba01817365c ("drm/amd/display: Move panel_cntl specific register from abm to panel_cntl.") Signed-off-by: Colin Ian King Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 22992106a784b1ceb9b741a030b9028ae943f66d Author: Christophe JAILLET Date: Thu Aug 13 19:34:58 2020 +0200 staging: rtl8192u: Do not use GFP_KERNEL in atomic context [ Upstream commit acac75bb451fd39344eb54fad6602dfc9482e970 ] 'rtl8192_irq_rx_tasklet()' is a tasklet initialized in 'rtl8192_init_priv_task()'. >From this function it is possible to allocate some memory with the GFP_KERNEL flag, which is not allowed in the atomic context of a tasklet. Use GFP_ATOMIC instead. The call chain is: rtl8192_irq_rx_tasklet (in r8192U_core.c) --> rtl8192_rx_nomal (in r8192U_core.c) --> ieee80211_rx (in ieee80211/ieee80211_rx.c) --> RxReorderIndicatePacket (in ieee80211/ieee80211_rx.c) Fixes: 79a5ccd97209 ("staging: rtl8192u: fix large frame size compiler warning") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20200813173458.758284-1-christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a13ce75147b6c2a49e5ece917d7352964c3ed01e Author: Thomas Zimmermann Date: Fri Aug 7 13:10:22 2020 +0200 drm/malidp: Use struct drm_gem_object_funcs.get_sg_table internally [ Upstream commit d3d1bbe794ab4f7cce13e8ba08a2ac978133375e ] The malidp driver uses GEM object functions for callbacks. Fix it to use them internally as well. Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter Fixes: ecdd6474644f ("drm/malidp: Use GEM CMA object functions") Cc: Thomas Zimmermann Cc: Emil Velikov Cc: Liviu Dudau Cc: Brian Starkey Link: https://patchwork.freedesktop.org/patch/msgid/20200807111022.12117-1-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 028ac9637a7e5b44e56954bb64df28b71c69c5cd Author: Christophe JAILLET Date: Sun Aug 9 11:29:06 2020 +0200 mwifiex: Do not use GFP_KERNEL in atomic context [ Upstream commit d2ab7f00f4321370a8ee14e5630d4349fdacc42e ] A possible call chain is as follow: mwifiex_sdio_interrupt (sdio.c) --> mwifiex_main_process (main.c) --> mwifiex_process_cmdresp (cmdevt.c) --> mwifiex_process_sta_cmdresp (sta_cmdresp.c) --> mwifiex_ret_802_11_scan (scan.c) --> mwifiex_parse_single_response_buf (scan.c) 'mwifiex_sdio_interrupt()' is an interrupt function. Also note that 'mwifiex_ret_802_11_scan()' already uses GFP_ATOMIC. So use GFP_ATOMIC instead of GFP_KERNEL when memory is allocated in 'mwifiex_parse_single_response_buf()'. Fixes: 7c6fa2a843c5 ("mwifiex: use cfg80211 dynamic scan table and cfg80211_get_bss API") or Fixes: 601216e12c65e ("mwifiex: process RX packets in SDIO IRQ thread directly") Signed-off-by: Christophe JAILLET Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200809092906.744621-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit fb4e3320d10a79c0fec047df8e3d90d1dbcf4faa Author: Tom Rix Date: Sun Aug 2 09:18:04 2020 -0700 brcmfmac: check ndev pointer [ Upstream commit 9c9f015bc9f8839831c7ba0a6d731a3853c464e2 ] Clang static analysis reports this error brcmfmac/core.c:490:4: warning: Dereference of null pointer (*ifp)->ndev->stats.rx_errors++; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In this block of code if (ret || !(*ifp) || !(*ifp)->ndev) { if (ret != -ENODATA && *ifp) (*ifp)->ndev->stats.rx_errors++; brcmu_pkt_buf_free_skb(skb); return -ENODATA; } (*ifp)->ndev being NULL is caught as an error But then it is used to report the error. So add a check before using it. Fixes: 91b632803ee4 ("brcmfmac: Use net_device_stats from struct net_device") Signed-off-by: Tom Rix Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200802161804.6126-1-trix@redhat.com Signed-off-by: Sasha Levin commit 800dd91934483982ee8fc171e0034f8c98a3e435 Author: Wang Yufen Date: Mon Jul 20 17:36:44 2020 +0800 ath11k: Fix possible memleak in ath11k_qmi_init_service [ Upstream commit 28f1632118818d9dccabf4c0fccfe49686742317 ] When qmi_add_lookup fail, we should destroy the workqueue Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Reported-by: Hulk Robot Signed-off-by: Wang Yufen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1595237804-66297-1-git-send-email-wangyufen@huawei.com Signed-off-by: Sasha Levin commit 63f4fe0a83268520392893fbc170f38bb694e15c Author: Rohit kumar Date: Fri Aug 14 16:23:02 2020 +0530 ASoC: qcom: lpass-cpu: fix concurrency issue [ Upstream commit 753a6e17942f6f425ca622e1610625998312ad89 ] i2sctl register value is set to 0 during hw_free(). This impacts any ongoing concurrent session on the same i2s port. As trigger() stop already resets enable bit to 0, there is no need of explicit hw_free. Removing it to fix the issue. Fixes: 80beab8e1d86 ("ASoC: qcom: Add LPASS CPU DAI driver") Signed-off-by: Rohit kumar Reviewed-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/1597402388-14112-7-git-send-email-rohitkr@codeaurora.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f262e3bb5be83da2b233383d38df1c79d0d46fbb Author: Rohit kumar Date: Fri Aug 14 16:23:00 2020 +0530 ASoC: qcom: lpass-platform: fix memory leak [ Upstream commit 5fd188215d4eb52703600d8986b22311099a5940 ] lpass_pcm_data is never freed. Free it in close ops to avoid memory leak. Fixes: 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage") Signed-off-by: Rohit kumar Reviewed-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/1597402388-14112-5-git-send-email-rohitkr@codeaurora.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 37e5649364e2680a80be33d10fe18c84b3b09e93 Author: Bryan O'Donoghue Date: Sun Aug 2 01:48:24 2020 +0100 wcn36xx: Fix reported 802.11n rx_highest rate wcn3660/wcn3680 [ Upstream commit 3b9fb6791e7113679b1eb472e6ce1659e80f5797 ] Qualcomm's document "80-WL007-1 Rev. J" states that the highest rx rate for the WCN3660 and WCN3680 on MCS 7 is 150 Mbps not the 72 Mbps stated here. This patch fixes the data-rate declared in the 5GHz table. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200802004824.1307124-1-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin commit f59b76fded37132f77fb233cf1112b510930182f Author: Christophe JAILLET Date: Sun Aug 2 14:22:27 2020 +0200 ath10k: Fix the size used in a 'dma_free_coherent()' call in an error handling path [ Upstream commit 454530a9950b5a26d4998908249564cedfc4babc ] Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()'. Fixes: 1863008369ae ("ath10k: fix shadow register implementation for WCN3990") Signed-off-by: Christophe JAILLET Reviewed-by: Rakesh Pillai Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200802122227.678637-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 47f9e652af03e6cb37ca789275300bcaeea3a37a Author: Dan Carpenter Date: Thu Aug 13 17:12:53 2020 +0300 ath9k: Fix potential out of bounds in ath9k_htc_txcompletion_cb() [ Upstream commit 2705cd7558e718a7240c64eb0afb2edad5f8c190 ] The value of "htc_hdr->endpoint_id" comes from skb->data so Smatch marks it as untrusted so we have to check it before using it as an array offset. This is similar to a bug that syzkaller found in commit e4ff08a4d727 ("ath9k: Fix use-after-free Write in ath9k_htc_rx_msg") so it is probably a real issue. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200813141253.GA457408@mwanda Signed-off-by: Sasha Levin commit 6141d4a1f59960ec8983bc25c3b33cb7c866d550 Author: Dan Carpenter Date: Thu Aug 13 17:13:15 2020 +0300 ath6kl: prevent potential array overflow in ath6kl_add_new_sta() [ Upstream commit 54f9ab7b870934b70e5a21786d951fbcf663970f ] The value for "aid" comes from skb->data so Smatch marks it as untrusted. If it's invalid then it can result in an out of bounds array access in ath6kl_add_new_sta(). Fixes: 572e27c00c9d ("ath6kl: Fix AP mode connect event parsing and TIM updates") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200813141315.GB457408@mwanda Signed-off-by: Sasha Levin commit 67ee72ec43160a970979b16b79141619f5c95a92 Author: Laurent Pinchart Date: Thu Aug 13 01:02:44 2020 +0300 drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panel [ Upstream commit f098f168e91ca915c6cf8aa316136af647792f2f ] The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel, set the bus format to MEDIA_BUS_FMT_RGB666_1X18. Fixes: 725c9d40f3fe ("drm/panel: Add support for OrtusTech COM43H4M85ULC panel") Signed-off-by: Laurent Pinchart Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200812220244.24500-1-laurent.pinchart@ideasonboard.com Signed-off-by: Sasha Levin commit ad52e20f33767694e32721a30efb52643bd43e92 Author: Qinglang Miao Date: Mon Aug 10 21:00:11 2020 +0800 drm/vkms: add missing platform_device_unregister() in vkms_init() [ Upstream commit 7995bd13296111d672d8c5959f5e81dbbbda5286 ] When vkms_init() get into out_put, the unregister call of vkms_device->platform is missing. So add it before return. Fixes: ac19f140bc27 ("drm/vkms: Use drmm_add_final_kfree") Signed-off-by: Qinglang Miao Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200810130011.187691-1-miaoqinglang@huawei.com Signed-off-by: Sasha Levin commit 1439fb7cd078aaa8ba0d3aaf5534175a67aab53b Author: Qinglang Miao Date: Mon Aug 10 20:59:42 2020 +0800 drm/vgem: add missing platform_device_unregister() in vgem_init() [ Upstream commit 57fb54082d5d14512dfd21bc39d91945d3ad1ee9 ] When vgem_init() get into out_put, the unregister call of vgem_device->platform is missing. So add it before return. Fixes: 363de9e7d4f6 ("drm/vgem: Use drmm_add_final_kfree") Signed-off-by: Qinglang Miao Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200810125942.186637-1-miaoqinglang@huawei.com Signed-off-by: Sasha Levin commit 52398e0d866ed9266b743c4f6b9c910daaabb145 Author: Tianjia Zhang Date: Sun Aug 2 19:15:36 2020 +0800 drm/amd/display: Fix wrong return value in dm_update_plane_state() [ Upstream commit c35376137e940c3389df2726a92649c01a9844b4 ] On an error exit path, a negative error code should be returned instead of a positive return value. Fixes: 9e869063b0021 ("drm/amd/display: Move iteration out of dm_update_planes") Cc: Leo Li Signed-off-by: Tianjia Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0d987e14bebaf0f67ee7dbefaf6165c62cd1d27f Author: Samuel Holland Date: Sat Aug 1 11:29:56 2020 -0500 Bluetooth: hci_uart: Cancel init work before unregistering [ Upstream commit 3b799254cf6f481460719023d7a18f46651e5e7f ] If hci_uart_tty_close() or hci_uart_unregister_device() is called while hu->init_ready is scheduled, hci_register_dev() could be called after the hci_uart is torn down. Avoid this by ensuring the work is complete or canceled before checking the HCI_UART_REGISTERED flag. Fixes: 9f2aee848fe6 ("Bluetooth: Add delayed init sequence support for UART controllers") Signed-off-by: Samuel Holland Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 62ea974996385a44916e250f3eafffe6958728de Author: Melissa Wen Date: Thu Jul 30 17:25:24 2020 -0300 drm/vkms: fix xrgb on compute crc [ Upstream commit 0986191186128b10b6bbfa5220fc587ed5725e49 ] The previous memset operation was not correctly zeroing the alpha channel to compute the crc, and as a result, the IGT subtest kms_cursor_crc/pipe-A-cursor-alpha-transparent fails. Fixes: db7f419c06d7c ("drm/vkms: Compute CRC with Cursor Plane") Signed-off-by: Melissa Wen Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200730202524.5upzuh4irboru7my@smtp.gmail.com Signed-off-by: Sasha Levin commit 675fe6a09b5ebe5ffc0a7973e052c656ba0fec65 Author: Venkateswara Naralasetty Date: Mon Jun 15 20:29:03 2020 +0300 ath10k: provide survey info as accumulated data [ Upstream commit 720e5c03e5cb26d33d97f55192b791bb48478aa5 ] It is expected that the returned counters by .get_survey are monotonic increasing. But the data from ath10k gets reset to zero regularly. Channel active/busy time are then showing incorrect values (less than previous or sometimes zero) for the currently active channel during successive survey dump commands. example: $ iw dev wlan0 survey dump Survey data from wlan0 frequency: 5180 MHz [in use] channel active time: 54995 ms channel busy time: 432 ms channel receive time: 0 ms channel transmit time: 59 ms ... $ iw dev wlan0 survey dump Survey data from wlan0 frequency: 5180 MHz [in use] channel active time: 32592 ms channel busy time: 254 ms channel receive time: 0 ms channel transmit time: 0 ms ... The correct way to handle this is to use the non-clearing WMI_BSS_SURVEY_REQ_TYPE_READ wmi_bss_survey_req_type. The firmware will then accumulate the survey data and handle wrap arounds. Tested-on: QCA9984 hw1.0 10.4-3.5.3-00057 Tested-on: QCA988X hw2.0 10.2.4-1.0-00047 Tested-on: QCA9888 hw2.0 10.4-3.9.0.2-00024 Tested-on: QCA4019 hw1.0 10.4-3.6-00140 Fixes: fa7937e3d5c2 ("ath10k: update bss channel survey information") Signed-off-by: Venkateswara Naralasetty Tested-by: Markus Theil Tested-by: John Deere <24601deerej@gmail.com> [sven@narfation.org: adjust commit message] Signed-off-by: Sven Eckelmann Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1592232686-28712-1-git-send-email-kvalo@codeaurora.org Signed-off-by: Sasha Levin commit 7893f6ac45e49061379cb7eb0a7b31b5e4d68b95 Author: Yang Yang Date: Fri Oct 9 01:00:14 2020 -0700 blk-mq: move cancel of hctx->run_work to the front of blk_exit_queue [ Upstream commit 47ce030b7ac5a5259a9a5919f230b52497afc31a ] blk_exit_queue will free elevator_data, while blk_mq_run_work_fn will access it. Move cancel of hctx->run_work to the front of blk_exit_queue to avoid use-after-free. Fixes: 1b97871b501f ("blk-mq: move cancel of hctx->run_work into blk_mq_hw_sysfs_release") Signed-off-by: Yang Yang Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4924b3d485fc28000ed451919c070bc1ddd9df22 Author: Qu Wenruo Date: Thu Aug 20 15:42:46 2020 +0800 btrfs: add owner and fs_info to alloc_state io_tree [ Upstream commit 154f7cb86809a3a796bffbc7a5a7ce0dee585eaa ] Commit 1c11b63eff2a ("btrfs: replace pending/pinned chunks lists with io tree") introduced btrfs_device::alloc_state extent io tree, but it doesn't initialize the fs_info and owner member. This means the following features are not properly supported: - Fs owner report for insert_state() error Without fs_info initialized, although btrfs_err() won't panic, it won't output which fs is causing the error. - Wrong owner for trace events alloc_state will get the owner as pinned extents. Fix this by assiging proper fs_info and owner for btrfs_device::alloc_state. Fixes: 1c11b63eff2a ("btrfs: replace pending/pinned chunks lists with io tree") Reviewed-by: Nikolay Borisov Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9e68d974b2fd4977e896e166656c36e2f80293d6 Author: Marek Vasut Date: Mon Oct 5 15:22:29 2020 +0200 spi: imx: Fix freeing of DMA channels if spi_bitbang_start() fails [ Upstream commit 45f0bbdafd26d6d772172563b30bff561cec9133 ] If the SPI controller has has_dmamode = true and spi_bitbang_start() fails in spi_imx_probe(), then the driver must release the DMA channels acquired in spi_imx_sdma_init() by calling spi_imx_sdma_exit() in the fail path. Fixes: f62caccd12c1 ("spi: spi-imx: add DMA support") Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Mark Brown Cc: NXP Linux Team Cc: Robin Gong Cc: Shawn Guo Link: https://lore.kernel.org/r/20201005132229.513119-1-marex@denx.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 385b10346884ba6a511f4a654173b0041f64fe44 Author: Serge Semin Date: Sun Sep 20 14:09:23 2020 +0300 hwmon: (bt1-pvt) Wait for the completion with timeout [ Upstream commit 0ffd21d5985506d164ada9e8fff6daae8ef469a1 ] If the PVT sensor is suddenly powered down while a caller is waiting for the conversion completion, the request won't be finished and the task will hang up on this procedure until the power is back up again. Let's call the wait_for_completion_timeout() method instead to prevent that. The cached timeout is exactly what we need to predict for how long conversion could normally last. Fixes: 87976ce2825d ("hwmon: Add Baikal-T1 PVT sensor driver") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20200920110924.19741-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f2c0f8ccac6572c8a0e8e5e482a09dca57a8d5a8 Author: Serge Semin Date: Sun Sep 20 14:09:22 2020 +0300 hwmon: (bt1-pvt) Cache current update timeout [ Upstream commit 0015503e5f6357f286bef34d039e43359fa4efd4 ] Instead of converting the update timeout data to the milliseconds each time on the read procedure let's preserve the currently set timeout in the dedicated driver private data cache. The cached value will be then used in the timeout read method and in the alarm-less data conversion to prevent the caller task hanging up in case if the PVT sensor is suddenly powered down. Fixes: 87976ce2825d ("hwmon: Add Baikal-T1 PVT sensor driver") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20200920110924.19741-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 77d1de6b7b9729aa85183dc3fdea51abd89cd8fc Author: Serge Semin Date: Sun Sep 20 14:09:21 2020 +0300 hwmon: (bt1-pvt) Test sensor power supply on probe [ Upstream commit a6db1561291fc0f2f9aa23bf38f381adc63e7b14 ] Baikal-T1 PVT sensor has got a dedicated power supply domain (feed up by the external GPVT/VPVT_18 pins). In case if it isn't powered up, the registers will be accessible, but the sensor conversion just won't happen. Due to that an attempt to read data from any PVT sensor will cause the task hanging up. For instance that will happen if XP11 jumper isn't installed on the Baikal-T1-based BFK3.1 board. Let's at least test whether the conversion work on the device probe procedure. By doing so will make sure that the PVT sensor is powered up at least at boot time. Fixes: 87976ce2825d ("hwmon: Add Baikal-T1 PVT sensor driver") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20200920110924.19741-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9d552ac606d1c17caaedc3085497844e11916527 Author: Łukasz Stelmach Date: Fri Oct 2 14:22:37 2020 +0200 spi: spi-s3c64xx: Check return values [ Upstream commit 2f4db6f705c5cba85d23836c19b44d9687dc1334 ] Check return values in prepare_dma() and s3c64xx_spi_config() and propagate errors upwards. Fixes: 788437273fa8 ("spi: s3c64xx: move to generic dmaengine API") Reviewed-by: Krzysztof Kozlowski Signed-off-by: Łukasz Stelmach Link: https://lore.kernel.org/r/20201002122243.26849-4-l.stelmach@samsung.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3214d9bf5337c84a49ae8707844a2c6abed88569 Author: Łukasz Stelmach Date: Fri Oct 2 14:22:35 2020 +0200 spi: spi-s3c64xx: swap s3c64xx_spi_set_cs() and s3c64xx_enable_datapath() [ Upstream commit 581e2b41977dfc2d4c26c8e976f89c43bb92f9bf ] Fix issues with DMA transfers bigger than 512 bytes on Exynos3250. Without the patches such transfers fail to complete. This solution to the problem is found in the vendor kernel for ARTIK5 boards based on Exynos3250. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Łukasz Stelmach Link: https://lore.kernel.org/r/20201002122243.26849-2-l.stelmach@samsung.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7f101eccd00b242dd15f6dd1dc6cd624cce2ef2c Author: Necip Fazil Yildiran Date: Mon Sep 14 17:40:26 2020 +0300 pinctrl: bcm: fix kconfig dependency warning when !GPIOLIB [ Upstream commit 513034d8b089b9a49dab57845aee70e830fe7334 ] When PINCTRL_BCM2835 is enabled and GPIOLIB is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for GPIOLIB_IRQCHIP Depends on [n]: GPIOLIB [=n] Selected by [y]: - PINCTRL_BCM2835 [=y] && PINCTRL [=y] && OF [=y] && (ARCH_BCM2835 [=n] || ARCH_BRCMSTB [=n] || COMPILE_TEST [=y]) The reason is that PINCTRL_BCM2835 selects GPIOLIB_IRQCHIP without depending on or selecting GPIOLIB while GPIOLIB_IRQCHIP is subordinate to GPIOLIB. Honor the kconfig menu hierarchy to remove kconfig dependency warnings. Fixes: 85ae9e512f43 ("pinctrl: bcm2835: switch to GPIOLIB_IRQCHIP") Signed-off-by: Necip Fazil Yildiran Link: https://lore.kernel.org/r/20200914144025.371370-1-fazilyildiran@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f58ce31b05b4ca0c200a5cbe4724efe279405095 Author: Michał Mirosław Date: Sat Sep 26 23:32:41 2020 +0200 regulator: resolve supply after creating regulator [ Upstream commit aea6cb99703e17019e025aa71643b4d3e0a24413 ] When creating a new regulator its supply cannot create the sysfs link because the device is not yet published. Remove early supply resolving since it will be done later anyway. This makes the following error disappear and the symlinks get created instead. DCDC_REG1: supplied by VSYS VSYS: could not add device link regulator.3 err -2 Note: It doesn't fix the problem for bypassed regulators, though. Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators") Signed-off-by: Michał Mirosław Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d7e1b54d63cd14e23e82663104fed8fd7d91dbd5 Author: Qiushi Wu Date: Sun Jun 14 04:56:05 2020 +0200 media: ti-vpe: Fix a missing check and reference count leak [ Upstream commit 7dae2aaaf432767ca7aa11fa84643a7c2600dbdd ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if pm_runtime_put_noidle() is not called in error handling paths. And also, when the call of function vpe_runtime_get() failed, we won't call vpe_runtime_put(). Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails inside vpe_runtime_get(). Fixes: 4571912743ac ("[media] v4l: ti-vpe: Add VPE mem to mem driver") Signed-off-by: Qiushi Wu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 41d024973d4194a87c9b9e80f9bfeecf16ddd066 Author: Qiushi Wu Date: Sun Jun 14 04:36:59 2020 +0200 media: stm32-dcmi: Fix a reference count leak [ Upstream commit 88f50a05f907d96a27a9ce3cc9e8cbb91a6f0f22 ] Calling pm_runtime_get_sync increments the counter even in case of failure, causing incorrect ref count if pm_runtime_put is not called in error handling paths. Thus replace the jump target "err_release_buffers" by "err_pm_putw". Fixes: 152e0bf60219 ("media: stm32-dcmi: add power saving support") Signed-off-by: Qiushi Wu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f9225e43a4542867e9a92f420ef8124de8138a35 Author: Qiushi Wu Date: Sun Jun 14 04:31:22 2020 +0200 media: s5p-mfc: Fix a reference count leak [ Upstream commit 78741ce98c2e36188e2343434406b0e0bc50b0e7 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if pm_runtime_put_noidle() is not called in error handling paths. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails. Fixes: c5086f130a77 ("[media] s5p-mfc: Use clock gating only on MFC v5 hardware") Signed-off-by: Qiushi Wu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d9d50b68bd70fe533a8e1a71a439655ce997919a Author: Qiushi Wu Date: Sun Jun 14 01:27:12 2020 +0200 media: camss: Fix a reference count leak. [ Upstream commit d0675b67b42eb4f1a840d1513b5b00f78312f833 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if PM runtime put is not called in error handling paths. Thus call pm_runtime_put_sync() if pm_runtime_get_sync() fails. Fixes: 02afa816dbbf ("media: camss: Add basic runtime PM support") Signed-off-by: Qiushi Wu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 50cd8acd7b663f698f99fa4200f84523291746b3 Author: Qiushi Wu Date: Sun Jun 14 01:19:44 2020 +0200 media: platform: fcp: Fix a reference count leak. [ Upstream commit 63e36a381d92a9cded97e90d481ee22566557dd1 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if pm_runtime_put_noidle() is not called in error handling paths. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails. Fixes: 6eaafbdb668b ("[media] v4l: rcar-fcp: Keep the coding style consistent") Signed-off-by: Qiushi Wu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 893662cfb5e30913961c6de8b21a434891d288df Author: Qiushi Wu Date: Sun Jun 14 01:13:49 2020 +0200 media: rockchip/rga: Fix a reference count leak. [ Upstream commit 884d638e0853c4b5f01eb6d048fc3b6239012404 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails. Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support") Signed-off-by: Qiushi Wu Reviewed-by: Heiko Stuebner Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5e32b7f8452b91d70a538f5080a615d0d46b8a60 Author: Qiushi Wu Date: Sun Jun 14 00:30:08 2020 +0200 media: rcar-vin: Fix a reference count leak. [ Upstream commit aaffa0126a111d65f4028c503c76192d4cc93277 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails. Fixes: 90dedce9bc54 ("media: rcar-vin: add function to manipulate Gen3 chsel value") Signed-off-by: Qiushi Wu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a6ca85387edd65c3698096b7cf07cf1240bd5c76 Author: Christoph Hellwig Date: Sun Aug 30 12:00:10 2020 +0200 nvme: fix error handling in nvme_ns_report_zones [ Upstream commit 936fab503ff4af94f5f9c0b549f3ab4d435500ec ] nvme_submit_sync_cmd can return positive NVMe error codes in addition to the negative Linux error code, which are currently ignored. Fix this by removing __nvme_ns_report_zones and handling the errors from nvme_submit_sync_cmd in the caller instead of multiplexing the return value and the number of zones reported into a single return value. Fixes: 240e6ee272c0 ("nvme: support for zoned namespaces") Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Signed-off-by: Sasha Levin commit 2e92a46fd714c0970269f61648af068df5ae463c Author: Tom Rix Date: Wed Sep 2 20:32:12 2020 +0200 media: tc358743: cleanup tc358743_cec_isr [ Upstream commit 877cb8a444dad2304e891294afb0915fe3c278d6 ] tc358743_cec_isr is misnammed, it is not the main isr. So rename it to be consistent with its siblings, tc358743_cec_handler. It also does not check if its input parameter 'handled' is is non NULL like its siblings, so add a check. Fixes: a0ec8d1dc42e ("media: tc358743: add CEC support") Signed-off-by: Tom Rix Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 665d45305ac9a0b844617c7a819473605477ad5f Author: Tom Rix Date: Sun Aug 30 18:30:43 2020 +0200 media: tc358743: initialize variable [ Upstream commit 274cf92d5dff5c2fec1a518078542ffe70d07646 ] clang static analysis flags this error tc358743.c:1468:9: warning: Branch condition evaluates to a garbage value return handled ? IRQ_HANDLED : IRQ_NONE; ^~~~~~~ handled should be initialized to false. Fixes: d747b806abf4 ("[media] tc358743: add direct interrupt handling") Signed-off-by: Tom Rix Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6ab5b3b205c731977e89389777a42108c37f9609 Author: Dafna Hirschfeld Date: Fri Aug 28 15:55:41 2020 +0200 media: mtk-mdp: Fix Null pointer dereference when calling list_add [ Upstream commit 0ca9454740b05eec199c5ffdb23a79eb44437917 ] In list_add, the first variable is the new node and the second is the list head. The function is called with a wrong order causing NULL dereference: [ 15.527030] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 15.542317] Mem abort info: [ 15.545152] ESR = 0x96000044 [ 15.548248] EC = 0x25: DABT (current EL), IL = 32 bits [ 15.553624] SET = 0, FnV = 0 [ 15.556715] EA = 0, S1PTW = 0 [ 15.559892] Data abort info: [ 15.562799] ISV = 0, ISS = 0x00000044 [ 15.566678] CM = 0, WnR = 1 [ 15.569683] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001373f0000 [ 15.576196] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000 [ 15.583101] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 15.588747] Modules linked in: mtk_mdp(+) cfg80211 v4l2_mem2mem videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common vide odev mt8173_rt5650 smsc95xx usbnet ecdh_generic ecc snd_soc_rt5645 mc mt8173_afe_pcm rfkill cros_ec_sensors snd_soc_mtk_common elan_i2c crct10dif_ce cros_ec_se nsors_core snd_soc_rl6231 elants_i2c industrialio_triggered_buffer kfifo_buf mtk_vpu cros_ec_chardev cros_usbpd_charger cros_usbpd_logger sbs_battery display_c onnector pwm_bl ip_tables x_tables ipv6 [ 15.634295] CPU: 0 PID: 188 Comm: systemd-udevd Not tainted 5.9.0-rc2+ #69 [ 15.641242] Hardware name: Google Elm (DT) [ 15.645381] pstate: 20000005 (nzCv daif -PAN -UAO BTYPE=--) [ 15.651022] pc : mtk_mdp_probe+0x134/0x3a8 [mtk_mdp] [ 15.656041] lr : mtk_mdp_probe+0x128/0x3a8 [mtk_mdp] [ 15.661055] sp : ffff80001255b910 [ 15.669548] x29: ffff80001255b910 x28: 0000000000000000 [ 15.679973] x27: ffff800009089bf8 x26: ffff0000fafde800 [ 15.690347] x25: ffff0000ff7d2768 x24: ffff800009089010 [ 15.700670] x23: ffff0000f01a7cd8 x22: ffff0000fafde810 [ 15.710940] x21: ffff0000f01a7c80 x20: ffff0000f0c3c180 [ 15.721148] x19: ffff0000ff7f1618 x18: 0000000000000010 [ 15.731289] x17: 0000000000000000 x16: 0000000000000000 [ 15.741375] x15: 0000000000aaaaaa x14: 0000000000000020 [ 15.751399] x13: 00000000ffffffff x12: 0000000000000020 [ 15.761363] x11: 0000000000000028 x10: 0101010101010101 [ 15.771279] x9 : 0000000000000004 x8 : 7f7f7f7f7f7f7f7f [ 15.781148] x7 : 646bff6171606b2b x6 : 0000000000806d65 [ 15.790981] x5 : ffff0000ff7f8360 x4 : 0000000000000000 [ 15.800767] x3 : 0000000000000004 x2 : 0000000000000001 [ 15.810501] x1 : 0000000000000005 x0 : 0000000000000000 [ 15.820171] Call trace: [ 15.826944] mtk_mdp_probe+0x134/0x3a8 [mtk_mdp] [ 15.835908] platform_drv_probe+0x54/0xa8 [ 15.844247] really_probe+0xe4/0x3b0 [ 15.852104] driver_probe_device+0x58/0xb8 [ 15.860457] device_driver_attach+0x74/0x80 [ 15.868854] __driver_attach+0x58/0xe0 [ 15.876770] bus_for_each_dev+0x70/0xc0 [ 15.884726] driver_attach+0x24/0x30 [ 15.892374] bus_add_driver+0x14c/0x1f0 [ 15.900295] driver_register+0x64/0x120 [ 15.908168] __platform_driver_register+0x48/0x58 [ 15.916864] mtk_mdp_driver_init+0x20/0x1000 [mtk_mdp] [ 15.925943] do_one_initcall+0x54/0x1b4 [ 15.933662] do_init_module+0x54/0x200 [ 15.941246] load_module+0x1cf8/0x22d0 [ 15.948798] __do_sys_finit_module+0xd8/0xf0 [ 15.956829] __arm64_sys_finit_module+0x20/0x30 [ 15.965082] el0_svc_common.constprop.0+0x6c/0x168 [ 15.973527] do_el0_svc+0x24/0x90 [ 15.980403] el0_sync_handler+0x90/0x198 [ 15.987867] el0_sync+0x158/0x180 [ 15.994653] Code: 9400014b 2a0003fc 35000920 f9400280 (f9000417) [ 16.004299] ---[ end trace 76fee0203f9898e5 ]--- Fixes: 86698b9505bbc ("media: mtk-mdp: convert mtk_mdp_dev.comp array to list") Signed-off-by: Dafna Hirschfeld Reviewed-by: Matthias Brugger Tested-by: Enric Balletbo i Serra Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bf3932bc7062b454f8af75b944bef29729bc7fc5 Author: Dinghao Liu Date: Wed Aug 26 11:26:04 2020 +0200 media: mx2_emmaprp: Fix memleak in emmaprp_probe [ Upstream commit 21d387b8d372f859d9e87fdcc7c3b4a432737f4d ] When platform_get_irq() fails, we should release vfd and unregister pcdev->v4l2_dev just like the subsequent error paths. Fixes: d4e192cc44914 ("media: mx2_emmaprp: Check for platform_get_irq() error") Signed-off-by: Dinghao Liu Reviewed-by: Fabio Estevam Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4f949a333b628e3640defbfeaad4effcda8b4c9a Author: Corentin Labbe Date: Fri Sep 18 07:23:05 2020 +0000 crypto: sun8i-ce - handle endianness of t_common_ctl [ Upstream commit 87f34260f5e09a4578132ad1c05aef2d707dd4bf ] t_common_ctl is LE32 so we need to convert its value before using it. This value is only used on H6 (ignored on other SoCs) and not handling the endianness cause failure on xRNG/hashes operations on H6 when running BE. Fixes: 06f751b61329 ("crypto: allwinner - Add sun8i-ce Crypto Engine") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 112fafd236a686635dd627e1ea69939c207972a0 Author: Nicolas Toromanoff Date: Wed Sep 16 08:33:44 2020 +0200 crypto: stm32/crc32 - Avoid lock if hardware is already used [ Upstream commit bbf2cb1ea1e1428589d7f4d652bed15b265ce92d ] If STM32 CRC device is already in use, calculate CRC by software. This will release CPU constraint for a concurrent access to the hardware, and avoid masking irqs during the whole block processing. Fixes: 7795c0baf5ac ("crypto: stm32/crc32 - protect from concurrent accesses") Signed-off-by: Nicolas Toromanoff Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e730bf5c4c9cf400b6b4239fce10d26dd261be34 Author: Xiaoliang Pang Date: Mon Sep 14 11:00:51 2020 +0800 cypto: mediatek - fix leaks in mtk_desc_ring_alloc [ Upstream commit 228d284aac61283cde508a925d666f854b57af63 ] In the init loop, if an error occurs in function 'dma_alloc_coherent', then goto the err_cleanup section, after run i--, in the array ring, the struct mtk_ring with index i will not be released, causing memory leaks Fixes: 785e5c616c849 ("crypto: mediatek - Add crypto driver support for some MediaTek chips") Cc: Ryder Lee Signed-off-by: Xiaoliang Pang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b45bc4d30ab10e7b15c4c2eae808f05e5627d667 Author: Dan Carpenter Date: Mon Sep 21 15:52:12 2020 +0300 hwmon: (w83627ehf) Fix a resource leak in probe [ Upstream commit 18360b33a071e5883250fd1e04bfdeff8c3887a3 ] Smatch has a new check for resource leaks which found a bug in probe: drivers/hwmon/w83627ehf.c:2417 w83627ehf_probe() warn: 'res->start' not released on lines: 2412. We need to clean up if devm_hwmon_device_register_with_info() fails. Fixes: 266cd5835947 ("hwmon: (w83627ehf) convert to with_info interface") Signed-off-by: Dan Carpenter Reviewed-by: Dr. David Alan Gilbert Link: https://lore.kernel.org/r/20200921125212.GA1128194@mwanda Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 6b5e51b7769796006f84644852c4c07299e2f05c Author: Guenter Roeck Date: Thu Sep 17 14:39:29 2020 -0700 hwmon: (pmbus/max34440) Fix status register reads for MAX344{51,60,61} [ Upstream commit 6c094b31ea2ad773824362ba0fccb88d36f8d32d ] Starting with MAX34451, the chips of this series support STATUS_IOUT and STATUS_TEMPERATURE commands, and no longer report over-current and over-temperature status with STATUS_MFR_SPECIFIC. Fixes: 7a001dbab4ade ("hwmon: (pmbus/max34440) Add support for MAX34451.") Fixes: 50115ac9b6f35 ("hwmon: (pmbus/max34440) Add support for MAX34460 and MAX34461") Reported-by: Steve Foreman Cc: Steve Foreman Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 4fa3d94aeebd0479cb98c087e7e118524caf4983 Author: Charles Keepax Date: Fri Sep 18 16:22:12 2020 +0100 regmap: debugfs: Fix more error path regressions [ Upstream commit 1d512ee861b80da63cbc501b973c53131aa22f29 ] Many error paths in __regmap_init rely on ret being pre-initialised to -EINVAL, add an extra initialisation in after the new call to regmap_set_name. Fixes: 94cc89eb8fa5 ("regmap: debugfs: Fix handling of name string for debugfs init delays") Reported-by: Dan Carpenter Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20200918152212.22200-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7c7c1d5909dafe2c2a65e78e5ece485aaa16d931 Author: Kees Cook Date: Sat Sep 12 04:08:17 2020 -0700 selftests/seccomp: powerpc: Fix seccomp return value testing [ Upstream commit 46138329faeac3598f5a4dc991a174386b6de833 ] On powerpc, the errno is not inverted, and depends on ccr.so being set. Add this to a powerpc definition of SYSCALL_RET_SET(). Co-developed-by: Thadeu Lima de Souza Cascardo Signed-off-by: Thadeu Lima de Souza Cascardo Link: https://lore.kernel.org/linux-kselftest/20200911181012.171027-1-cascardo@canonical.com/ Fixes: 5d83c2b37d43 ("selftests/seccomp: Add powerpc support") Signed-off-by: Kees Cook Link: https://lore.kernel.org/lkml/20200912110820.597135-13-keescook@chromium.org Reviewed-by: Michael Ellerman Signed-off-by: Sasha Levin commit c7816e2d6c442e0cc909046e4a927b691fdafd25 Author: Kees Cook Date: Sat Sep 12 04:08:06 2020 -0700 selftests/seccomp: Refactor arch register macros to avoid xtensa special case [ Upstream commit a6a4d78419a04095221ec2b518edefb080218d55 ] To avoid an xtensa special-case, refactor all arch register macros to take the register variable instead of depending on the macro expanding as a struct member name. Signed-off-by: Kees Cook Link: https://lore.kernel.org/lkml/20200912110820.597135-2-keescook@chromium.org Acked-by: Christian Brauner Signed-off-by: Sasha Levin commit 73c24c54988a407542ad17df33ed3af0b967ae18 Author: Kees Cook Date: Sat Sep 12 04:08:20 2020 -0700 selftests/seccomp: Use __NR_mknodat instead of __NR_mknod [ Upstream commit 05b52c6625278cc6ed1245a569167f86a971ff86 ] The __NR_mknod syscall doesn't exist on arm64 (only __NR_mknodat). Switch to the modern syscall. Fixes: ad5682184a81 ("selftests/seccomp: Check for EPOLLHUP for user_notif") Signed-off-by: Kees Cook Link: https://lore.kernel.org/lkml/20200912110820.597135-16-keescook@chromium.org Acked-by: Christian Brauner Signed-off-by: Sasha Levin commit 4ece2c1f2b762817748a7c40867492836dd58f5b Author: Dan Carpenter Date: Wed Sep 9 12:45:28 2020 +0300 crypto: sa2ul - Fix pm_runtime_get_sync() error checking [ Upstream commit 2baace5feb86c6916221911f391f11fcd8e1a259 ] The pm_runtime_get_sync() function returns either 0 or 1 on success but this code treats a return of 1 as a failure. Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver") Signed-off-by: Dan Carpenter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 47ec709dca4eed64c7ab9f1d4fa469f2d73a623a Author: Tero Kristo Date: Mon Sep 7 10:56:24 2020 +0300 crypto: omap-sham - fix digcnt register handling with export/import [ Upstream commit 3faf757bad75f3fc1b2736f0431e295a073a7423 ] Running export/import for hashes in peculiar order (mostly done by openssl) can mess up the internal book keeping of the OMAP SHA core. Fix by forcibly writing the correct DIGCNT back to hardware. This issue was noticed while transitioning to openssl 1.1 support. Fixes: 0d373d603202 ("crypto: omap-sham - Add OMAP4/AM33XX SHAM Support") Signed-off-by: Tero Kristo Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9ceb1da21f2ed39f4764bf0e8d48b6a19820869e Author: Herbert Xu Date: Mon Sep 7 16:22:40 2020 +1000 crypto: sa2ul - Select CRYPTO_AUTHENC [ Upstream commit 61f033ba18c37e6b9ddfc4ee6dffe049d981fe7e ] The sa2ul driver uses crypto_authenc_extractkeys and therefore must select CRYPTO_AUTHENC. Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver") Reported-by: kernel test robot Signed-off-by: Herbert Xu Reviewed-by: Keerthy Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3f90d0e361bef9ecbaca2cbf384970891e956630 Author: Jay Fang Date: Tue Sep 15 09:22:49 2020 +0800 spi: dw-pci: free previously allocated IRQs if desc->setup() fails [ Upstream commit 9599f341889c87e56bb944659c32490d05e2532f ] Free previously allocated IRQs when return an error code of desc->setup() which is not always successful. And simplify the code by adding a goto label. Fixes: 8f5c285f3ef5 ("SPI: designware: pci: Switch over to MSI interrupts") CC: Felipe Balbi Signed-off-by: Jay Fang Link: https://lore.kernel.org/r/1600132969-53037-1-git-send-email-f.fangjian@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2ae4bbfc15acf0735a100d52eeb9a4029460a3f6 Author: Eddie James Date: Wed Sep 9 17:28:56 2020 -0500 spi: fsi: Implement restricted size for certain controllers [ Upstream commit 49c9fc1d7c101eceaddb655e4f0e062b0c8f403b ] Some of the FSI-attached SPI controllers cannot use the loop command in programming the sequencer due to security requirements. Check the devicetree compatibility that indicates this condition and restrict the size for these controllers. Also, add more transfers directly in the sequence up to the length of the sequence register. Fixes: bbb6b2f9865b ("spi: Add FSI-attached SPI controller driver") Signed-off-by: Eddie James Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20200909222857.28653-6-eajames@linux.ibm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1183920430801eb65db92045b6a1984e02cc1ca2 Author: Brad Bishop Date: Wed Sep 9 17:28:54 2020 -0500 spi: fsi: Fix use of the bneq+ sequencer instruction [ Upstream commit 7909eebb2bea7fdbb2de0aa794cf29843761ed5b ] All of the switches in N2_count_control in the counter configuration are required to make the branch if not equal and increment command work. Set them when using bneq+. A side effect of this mode requires a dummy write to TDR when both transmitting and receiving otherwise the controller won't start shifting receive data. It is likely not possible to avoid TDR underrun errors in this mode and they are harmless, so do not check for them. Fixes: bbb6b2f9865b ("spi: Add FSI-attached SPI controller driver") Signed-off-by: Brad Bishop Signed-off-by: Eddie James Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20200909222857.28653-4-eajames@linux.ibm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8157d6ea799c37bfc194fe7e43ff5920d251df39 Author: Brad Bishop Date: Wed Sep 9 17:28:52 2020 -0500 spi: fsi: Handle 9 to 15 byte transfers lengths [ Upstream commit 2b3cef0fc757bd06ed9b83bd4c436bfa55f47370 ] The trailing - 8 bytes of transfer data in this size range is no longer ignored. Fixes: bbb6b2f9865b ("spi: Add FSI-attached SPI controller driver") Signed-off-by: Brad Bishop Signed-off-by: Eddie James Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20200909222857.28653-2-eajames@linux.ibm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 575a1cc649e7bbded3ec90c9d131df7b4f10c290 Author: Tero Kristo Date: Tue Aug 25 16:31:06 2020 +0300 crypto: sa2ul - fix compiler warning produced by clang [ Upstream commit 17bce37e1b5eca95f9da783a07930b6d608c1389 ] Clang detects a warning for an assignment that doesn't really do anything. Fix this by removing the offending piece of code. Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver") Reported-by: Nathan Chancellor Signed-off-by: Tero Kristo Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor # build Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e7e9e54d50d2baaa2c9ccc6c5b5693322556a5f7 Author: Laurent Pinchart Date: Tue Aug 11 22:59:39 2020 +0200 media: i2c: max9286: Allocate v4l2_async_subdev dynamically [ Upstream commit 86d37bf31af647760f1f17e7c1afa1bdba075198 ] v4l2_async_notifier_add_subdev() requires the asd to be allocated dynamically, but the max9286 driver embeds it in the max9286_source structure. This causes memory corruption when the notifier is destroyed at remove time with v4l2_async_notifier_cleanup(). Fix this issue by registering the asd with v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically internally. A new max9286_asd structure is introduced, to store a pointer to the corresonding max9286_source that needs to be accessed from bound and unbind callbacks. There's no need to take an extra explicit reference to the fwnode anymore as v4l2_async_notifier_add_fwnode_subdev() does so internally. While at it, use %u instead of %d to print the unsigned index in the error message from the v4l2_async_notifier_add_fwnode_subdev() error path. Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3748a4776052d6392c978f131763e4c8b1d0753f Author: Laurent Pinchart Date: Tue Aug 11 22:59:38 2020 +0200 media: rcar-csi2: Allocate v4l2_async_subdev dynamically [ Upstream commit 2cac7cbfb4099980e78244359ab9c6f056d6a7ec ] v4l2_async_notifier_add_subdev() requires the asd to be allocated dynamically, but the rcar-csi2 driver embeds it in the rcar_csi2 structure. This causes memory corruption when the notifier is destroyed at remove time with v4l2_async_notifier_cleanup(). Fix this issue by registering the asd with v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically internally. Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver") Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8224347a8c2601d92c7ae70fd618fd2ca8bae817 Author: Laurent Pinchart Date: Tue Aug 11 22:59:37 2020 +0200 media: rcar_drif: Allocate v4l2_async_subdev dynamically [ Upstream commit 468e986dac0e94194334ca6d0abf3af8c250792e ] v4l2_async_notifier_add_subdev() requires the asd to be allocated dynamically, but the rcar-drif driver embeds it in the rcar_drif_graph_ep structure. This causes memory corruption when the notifier is destroyed at remove time with v4l2_async_notifier_cleanup(). Fix this issue by registering the asd with v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically internally. Fixes: d079f94c9046 ("media: platform: Switch to v4l2_async_notifier_add_subdev") Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 871586c7810f8fac98b67078aa009b775cddc9f5 Author: Laurent Pinchart Date: Tue Aug 11 22:59:36 2020 +0200 media: rcar_drif: Fix fwnode reference leak when parsing DT [ Upstream commit cdd4f7824994c9254acc6e415750529ea2d2cfe0 ] The fwnode reference corresponding to the endpoint is leaked in an error path of the rcar_drif_parse_subdevs() function. Fix it, and reorganize fwnode reference handling in the function to release references early, simplifying error paths. Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0aafed122aabe0add95a535cbc10b7fa63bd1be8 Author: Lad Prabhakar Date: Fri Sep 4 22:18:32 2020 +0200 media: i2c: ov5640: Enable data pins on poweron for DVP mode [ Upstream commit 576f5d4ba8f672953513280510abf9a736b015cc ] During testing this sensor on iW-RainboW-G21D-Qseven platform in 8-bit DVP mode with rcar-vin bridge noticed the capture worked fine for the first run (with yavta), but for subsequent runs the bridge driver waited for the frame to be captured. Debugging further noticed the data lines were enabled/disabled in stream on/off callback and dumping the register contents 0x3017/0x3018 in ov5640_set_stream_dvp() reported the correct values, but yet frame capturing failed. To get around this issue data lines are enabled in s_power callback. (Also the sensor remains in power down mode if not streaming so power consumption shouldn't be affected) Fixes: f22996db44e2d ("media: ov5640: add support of DVP parallel interface") Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Tested-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f0a59e421bcdc9965b3ad7772d35f9373d374cfe Author: Lad Prabhakar Date: Fri Sep 4 22:18:31 2020 +0200 media: i2c: ov5640: Separate out mipi configuration from s_power [ Upstream commit b1751ae652fb95919c08df5bdd739ccf9886158a ] In preparation for adding DVP configuration in s_power callback move mipi configuration into separate function Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Tested-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit edd563c900a03e79ce86bdcc75f7cde5e95c06cc Author: Lad Prabhakar Date: Fri Sep 4 22:18:30 2020 +0200 media: i2c: ov5640: Remain in power down for DVP mode unless streaming [ Upstream commit 3b987d70e903962eb8c5961ba166c345a49d1a0b ] Keep the sensor in software power down mode and wake up only in ov5640_set_stream_dvp() callback. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Tested-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 64628c14151484c59af81e0ca08da7cd14213284 Author: Dinghao Liu Date: Mon Aug 24 08:53:52 2020 +0200 media: omap3isp: Fix memleak in isp_probe [ Upstream commit d8fc21c17099635e8ebd986d042be65a6c6b5bd0 ] When devm_ioremap_resource() fails, isp should be freed just like other error paths in isp_probe. Fixes: 8644cdf972dd6 ("[media] omap3isp: Replace many MMIO regions by two") Signed-off-by: Dinghao Liu Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 402a29c258fc6e76382b3ea790e137fced0b02c3 Author: Christophe JAILLET Date: Sat Aug 22 15:11:24 2020 +0200 media: staging/intel-ipu3: css: Correctly reset some memory [ Upstream commit 08913a8e458e03f886a1a1154a6501fcb9344c39 ] The intent here is to reset the whole 'scaler_coeffs_luma' array, not just the first element. Fixes: e11110a5b744 ("media: staging/intel-ipu3: css: Compute and program ccs") Signed-off-by: Christophe JAILLET Reviewed-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6f24143899ce244af638bc6e480fa85afcb61acb Author: Laurent Pinchart Date: Wed Aug 19 01:56:49 2020 +0200 media: uvcvideo: Silence shift-out-of-bounds warning [ Upstream commit 171994e498a0426cbe17f874c5c6af3c0af45200 ] UBSAN reports a shift-out-of-bounds warning in uvc_get_le_value(). The report is correct, but the issue should be harmless as the computed value isn't used when the shift is negative. This may however cause incorrect behaviour if a negative shift could generate adverse side effects (such as a trap on some architectures for instance). Regardless of whether that may happen or not, silence the warning as a full WARN backtrace isn't nice. Reported-by: Bart Van Assche Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver") Signed-off-by: Laurent Pinchart Reviewed-by: Bart Van Assche Tested-by: Bart Van Assche Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5e0157469ca62c0fae6ee23a798eb213a20a344a Author: Laurent Pinchart Date: Sun Jun 7 04:05:49 2020 +0200 media: uvcvideo: Set media controller entity functions [ Upstream commit d6834b4b58d110814aaf3469e7fd87d34ae5ae81 ] The media controller core prints a warning when an entity is registered without a function being set. This affects the uvcvideo driver, as the warning was added without first addressing the issue in existing drivers. The problem is harmless, but unnecessarily worries users. Fix it by mapping UVC entity types to MC entity functions as accurately as possible using the existing functions. Fixes: b50bde4e476d ("[media] v4l2-subdev: use MEDIA_ENT_T_UNKNOWN for new subdevs") Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ea00415b0ce22fb5a3c01109480bd3d2314ebd61 Author: Eric Biggers Date: Mon Aug 24 13:38:41 2020 -0700 fscrypt: restrict IV_INO_LBLK_32 to ino_bits <= 32 [ Upstream commit 5e895bd4d5233cb054447d0491d4e63c8496d419 ] When an encryption policy has the IV_INO_LBLK_32 flag set, the IV generation method involves hashing the inode number. This is different from fscrypt's other IV generation methods, where the inode number is either not used at all or is included directly in the IVs. Therefore, in principle IV_INO_LBLK_32 can work with any length inode number. However, currently fscrypt gets the inode number from inode::i_ino, which is 'unsigned long'. So currently the implementation limit is actually 32 bits (like IV_INO_LBLK_64), since longer inode numbers will have been truncated by the VFS on 32-bit platforms. Fix fscrypt_supported_v2_policy() to enforce the correct limit. This doesn't actually matter currently, since only ext4 and f2fs support IV_INO_LBLK_32, and they both only support 32-bit inode numbers. But we might as well fix it in case it matters in the future. Ideally inode::i_ino would instead be made 64-bit, but for now it's not needed. (Note, this limit does *not* prevent filesystems with 64-bit inode numbers from adding fscrypt support, since IV_INO_LBLK_* support is optional and is useful only on certain hardware.) Fixes: e3b1078bedd3 ("fscrypt: add support for IV_INO_LBLK_32 policies") Reported-by: Jeff Layton Link: https://lore.kernel.org/r/20200824203841.1707847-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit a62031bbab6fbef369af2a9b461df55a58e2a328 Author: Tom Rix Date: Sun Jul 19 17:34:47 2020 +0200 media: m5mols: Check function pointer in m5mols_sensor_power [ Upstream commit 52438c4463ac904d14bf3496765e67750766f3a6 ] clang static analysis reports this error m5mols_core.c:767:4: warning: Called function pointer is null (null dereference) [core.CallAndMessage] info->set_power(&client->dev, 0); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In other places, the set_power ptr is checked. So add a check. Fixes: bc125106f8af ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP") Signed-off-by: Tom Rix Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6f398ce6565d5fbd97ad897be35efeb66d12bc22 Author: Colin Ian King Date: Mon Jul 20 18:13:35 2020 +0200 media: i2c: fix error check on max9286_read call [ Upstream commit e5b95c8febd504659b60a7601fd43c0ae8e4f3c0 ] Currently the error return from the call to max9286_read is masked with 0xf0 so the following check for a negative error return is never true. Fix this by checking for an error first, then masking the return value for subsequent conflink_mask checking. Addresses-Coverity: ("Logically dead code") Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Colin Ian King Reviewed-by: Kieran Bingham Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 29b0340f55d1d823ebb6def9b0987a21b28a3d40 Author: Paul Kocialkowski Date: Mon Aug 3 11:06:58 2020 +0200 media: ov5640: Correct Bit Div register in clock tree diagram [ Upstream commit 4c85f628f6639e3e3e0a7788416154f28dfcae4f ] Although the code is correct and doing the right thing, the clock diagram showed the wrong register for the bit divider, which had me doubting the understanding of the tree. Fix this to avoid doubts in the future. Signed-off-by: Paul Kocialkowski Fixes: aa2882481cada ("media: ov5640: Adjust the clock based on the expected rate") Acked-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ea814907aa5275bccb2d3e8920ae41f8bd9e24d9 Author: Ezequiel Garcia Date: Mon Jul 27 19:05:38 2020 +0200 media: hantro: postproc: Fix motion vector space allocation [ Upstream commit 669ccf19ed2059b9d517664a2dbbf6bde87e1414 ] When the post-processor is enabled, the driver allocates "shadow buffers" which are used for the decoder core, and exposes the post-processed buffers to userspace. For this reason, extra motion vector space has to be allocated on the shadow buffers, which the driver wasn't doing. Fix it. This fix should address artifacts on high profile bitstreams. Fixes: 8c2d66b036c77 ("media: hantro: Support color conversion via post-processing") Signed-off-by: Ezequiel Garcia Reviewed-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e06b42539665417b3c65121b142db0570828305b Author: Ezequiel Garcia Date: Mon Jul 27 19:05:37 2020 +0200 media: hantro: h264: Get the correct fallback reference buffer [ Upstream commit 6d9e8cd0553bb03e8ab9d4d2d7d17f3fb639bd86 ] If the bitstream and the application are incorrectly configuring the reference pictures, the hardware will need to fallback to using some other reference picture. When the post-processor is enabled, the fallback buffer should be a shadow buffer (postproc.dec_q), and not a CAPTURE queue buffer, since the latter is post-processed and not really the output of the decoder core. Fixes: 8c2d66b036c77 ("media: hantro: Support color conversion via post-processing") Signed-off-by: Ezequiel Garcia Reviewed-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit aa2a408df4a3115fd35118e239c4bc60baab440d Author: Sylwester Nawrocki Date: Mon Aug 10 17:32:39 2020 +0200 media: Revert "media: exynos4-is: Add missed check for pinctrl_lookup_state()" [ Upstream commit 00d21f325d58567d81d9172096692d0a9ea7f725 ] The "idle" pinctrl state is optional as documented in the DT binding. The change introduced by the commit being reverted makes that pinctrl state mandatory and breaks initialization of the whole media driver, since the "idle" state is not specified in any mainline dts. This reverts commit 18ffec750578 ("media: exynos4-is: Add missed check for pinctrl_lookup_state()") to fix the regression. Fixes: 18ffec750578 ("media: exynos4-is: Add missed check for pinctrl_lookup_state()") Signed-off-by: Sylwester Nawrocki Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8ceaa8fb287973864be6ab79dd2aaf4f5195cdbc Author: dinghao.liu@zju.edu.cn Date: Fri Aug 21 16:15:13 2020 +0800 crypto: ccree - fix runtime PM imbalance on error [ Upstream commit b7b57a5643c2ae45afe6aa5e73363b553cacd14b ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. However, users of cc_pm_get(), a direct wrapper of pm_runtime_get_sync(), assume that PM usage counter will not change on error. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Fixes: 8c7849a30255c ("crypto: ccree - simplify Runtime PM handling") Signed-off-by: Dinghao Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e0d568d5c6f954b55965709011377b23be115890 Author: Tom Rix Date: Sat Aug 22 23:15:47 2020 +0200 media: tuner-simple: fix regression in simple_set_radio_freq [ Upstream commit 505bfc2a142f12ce7bc7a878b44abc3496f2e747 ] clang static analysis reports this problem tuner-simple.c:714:13: warning: Assigned value is garbage or undefined buffer[1] = buffer[3]; ^ ~~~~~~~~~ In simple_set_radio_freq buffer[3] used to be done in-function with a switch of tuner type, now done by a call to simple_radio_bandswitch which has this case case TUNER_TENA_9533_DI: case TUNER_YMEC_TVF_5533MF: tuner_dbg("This tuner doesn't ... return 0; which does not set buffer[3]. In the old logic, this case would have returned 0 from simple_set_radio_freq. Recover this old behavior by returning an error for this codition. Since the old simple_set_radio_freq behavior returned a 0, do the same. Fixes: c7a9f3aa1e1b ("V4L/DVB (7129): tuner-simple: move device-specific code into three separate functions") Signed-off-by: Tom Rix Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f391ad41d8c15c98e52a5e1644b345c356176a89 Author: Peilin Ye Date: Fri Aug 21 14:46:45 2020 +0200 media: vivid: Fix global-out-of-bounds read in precalculate_color() [ Upstream commit e3158a5e7e661786b3ab650c7e4d21024e8eff0f ] vivid_meta_out_process() is setting `brightness`, `contrast`, `saturation` and `hue` using tpg_s_*(). This is wrong, since tpg_s_*() do not provide range checks. Using tpg_s_*() here also makes the control framework out-of-sync with the actual values. Use v4l2_ctrl_s_ctrl() instead. This issue has been reported by syzbot as an out-of-bounds read bug in precalculate_color(). Reported-and-tested-by: syzbot+02d9172bf4c43104cd70@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=02d9172bf4c43104cd70 Fixes: 746facd39370 ("media: vivid: Add metadata output support") Suggested-by: Hans Verkuil Signed-off-by: Peilin Ye Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 25d82a00d4bf08f5b198ae2bd825d1a0e68718bc Author: Madhuparna Bhowmik Date: Tue Aug 11 18:00:24 2020 +0530 crypto: picoxcell - Fix potential race condition bug [ Upstream commit 64f4a62e3b17f1e473f971127c2924cae42afc82 ] engine->stat_irq_thresh was initialized after device_create_file() in the probe function, the initialization may race with call to spacc_stat_irq_thresh_store() which updates engine->stat_irq_thresh, therefore initialize it before creating the file in probe function. Found by Linux Driver Verification project (linuxtesting.org). Fixes: ce92136843cb ("crypto: picoxcell - add support for the...") Signed-off-by: Madhuparna Bhowmik Acked-by: Jamie Iles Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8686dc64a86ae875b21c0dc3833b44dc976b601d Author: Christophe JAILLET Date: Sun Aug 2 16:56:48 2020 +0200 crypto: ixp4xx - Fix the size used in a 'dma_free_coherent()' call [ Upstream commit f7ade9aaf66bd5599690acf0597df2c0f6cd825a ] Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()', in 'setup_crypt_desc()'. Fixes: 81bef0150074 ("crypto: ixp4xx - Hardware crypto support for IXP4xx CPUs") Signed-off-by: Christophe JAILLET Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bf0aa4248512dadd5126b7d4b01601a914b269f4 Author: Tianjia Zhang Date: Sun Aug 2 19:15:32 2020 +0800 crypto: mediatek - Fix wrong return value in mtk_desc_ring_alloc() [ Upstream commit 8cbde6c6a6d2b1599ff90f932304aab7e32fce89 ] In case of memory allocation failure, a negative error code should be returned. Fixes: 785e5c616c849 ("crypto: mediatek - Add crypto driver support for some MediaTek chips") Cc: Ryder Lee Signed-off-by: Tianjia Zhang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 77827cc1174d33a4f2bf669937272cc8abcade00 Author: Herbert Xu Date: Fri Jul 31 17:03:27 2020 +1000 crypto: algif_skcipher - EBUSY on aio should be an error [ Upstream commit 2a05b029c1ee045b886ebf9efef9985ca23450de ] I removed the MAY_BACKLOG flag on the aio path a while ago but the error check still incorrectly interpreted EBUSY as success. This may cause the submitter to wait for a request that will never complete. Fixes: dad419970637 ("crypto: algif_skcipher - Do not set...") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2934dc07691347e7863d88d195791d22545dfb16 Author: Jonathan Marek Date: Tue Aug 18 12:25:08 2020 -0400 regulator: set of_node for qcom vbus regulator [ Upstream commit 66c3b96a7bd042427d2e0eaa8704536828f8235f ] This allows the regulator to be found by devm_regulator_get(). Fixes: 4fe66d5a62fb ("regulator: Add support for QCOM PMIC VBUS booster") Signed-off-by: Jonathan Marek Link: https://lore.kernel.org/r/20200818162508.5246-1-jonathan@marek.ca Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f1f019eff8c9515d99bdc032aa77b36e7cd01b66 Author: Jiri Olsa Date: Wed Sep 16 13:53:11 2020 +0200 perf/core: Fix race in the perf_mmap_close() function [ Upstream commit f91072ed1b7283b13ca57fcfbece5a3b92726143 ] There's a possible race in perf_mmap_close() when checking ring buffer's mmap_count refcount value. The problem is that the mmap_count check is not atomic because we call atomic_dec() and atomic_read() separately. perf_mmap_close: ... atomic_dec(&rb->mmap_count); ... if (atomic_read(&rb->mmap_count)) goto out_put; free_uid out_put: ring_buffer_put(rb); /* could be last */ The race can happen when we have two (or more) events sharing same ring buffer and they go through atomic_dec() and then they both see 0 as refcount value later in atomic_read(). Then both will go on and execute code which is meant to be run just once. The code that detaches ring buffer is probably fine to be executed more than once, but the problem is in calling free_uid(), which will later on demonstrate in related crashes and refcount warnings, like: refcount_t: addition on 0; use-after-free. ... RIP: 0010:refcount_warn_saturate+0x6d/0xf ... Call Trace: prepare_creds+0x190/0x1e0 copy_creds+0x35/0x172 copy_process+0x471/0x1a80 _do_fork+0x83/0x3a0 __do_sys_wait4+0x83/0x90 __do_sys_clone+0x85/0xa0 do_syscall_64+0x5b/0x1e0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Using atomic decrease and check instead of separated calls. Tested-by: Michael Petlan Signed-off-by: Jiri Olsa Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra Acked-by: Namhyung Kim Acked-by: Wade Mealing Fixes: 9bb5d40cd93c ("perf: Fix mmap() accounting hole"); Link: https://lore.kernel.org/r/20200916115311.GE2301783@krava Signed-off-by: Sasha Levin commit f9adec2ae38e50a2227b624d52d87175c857f3f5 Author: Peter Zijlstra Date: Mon Oct 5 09:56:57 2020 +0200 lockdep: Revert "lockdep: Use raw_cpu_*() for per-cpu variables" [ Upstream commit baffd723e44dc3d7f84f0b8f1fe1ece00ddd2710 ] The thinking in commit: fddf9055a60d ("lockdep: Use raw_cpu_*() for per-cpu variables") is flawed. While it is true that when we're migratable both CPUs will have a 0 value, it doesn't hold that when we do get migrated in the middle of a raw_cpu_op(), the old CPU will still have 0 by the time we get around to reading it on the new CPU. Luckily, the reason for that commit (s390 using preempt_disable() instead of preempt_disable_notrace() in their percpu code), has since been fixed by commit: 1196f12a2c96 ("s390: don't trace preemption in percpu macros") An audit of arch/*/include/asm/percpu*.h shows there are no other architectures affected by this particular issue. Fixes: fddf9055a60d ("lockdep: Use raw_cpu_*() for per-cpu variables") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/20201005095958.GJ2651@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 380a7ef2d18818a8d8ce32d712d258f21604f0b7 Author: Peter Zijlstra Date: Fri Oct 2 11:04:21 2020 +0200 lockdep: Fix lockdep recursion [ Upstream commit 4d004099a668c41522242aa146a38cc4eb59cb1e ] Steve reported that lockdep_assert*irq*(), when nested inside lockdep itself, will trigger a false-positive. One example is the stack-trace code, as called from inside lockdep, triggering tracing, which in turn calls RCU, which then uses lockdep_assert_irqs_disabled(). Fixes: a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context} to per-cpu variables") Reported-by: Steven Rostedt Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 086b8ee4d43de2ab9bf74e547e7b0550550d33e0 Author: Peter Zijlstra Date: Wed Sep 30 11:49:37 2020 +0200 lockdep: Fix usage_traceoverflow [ Upstream commit 2bb8945bcc1a768f2bc402a16c9610bba8d5187d ] Basically print_lock_class_header()'s for loop is out of sync with the the size of of ->usage_traces[]. Also clean things up a bit while at it, to avoid such mishaps in the future. Fixes: 23870f122768 ("locking/lockdep: Fix "USED" <- "IN-NMI" inversions") Reported-by: Qian Cai Debugged-by: Boqun Feng Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Tested-by: Qian Cai Link: https://lkml.kernel.org/r/20200930094937.GE2651@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 7748425f370fbd14e17390155b3eaff4c7018366 Author: Sasha Levin Date: Mon Oct 12 23:28:52 2020 -0400 perf/x86: Fix n_pair for cancelled txn [ Upstream commit 871a93b0aad65a7f44ee25f2d17932ef6d559850 ] Kan reported that n_metric gets corrupted for cancelled transactions; a similar issue exists for n_pair for AMD's Large Increment thing. The problem was confirmed and confirmed fixed by Kim using: sudo perf stat -e "{cycles,cycles,cycles,cycles}:D" -a sleep 10 & # should succeed: sudo perf stat -e "{fp_ret_sse_avx_ops.all}:D" -a workload # should fail: sudo perf stat -e "{fp_ret_sse_avx_ops.all,fp_ret_sse_avx_ops.all,cycles}:D" -a workload # previously failed, now succeeds with this patch: sudo perf stat -e "{fp_ret_sse_avx_ops.all}:D" -a workload Fixes: 5738891229a2 ("perf/x86/amd: Add support for Large Increment per Cycle Events") Reported-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Tested-by: Kim Phillips Link: https://lkml.kernel.org/r/20201005082516.GG2628@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 88acb494448a42662aadf0a83761ac07d1e359aa Author: Maulik Shah Date: Mon Sep 28 10:02:00 2020 +0530 pinctrl: qcom: Use return value from irq_set_wake() call [ Upstream commit f41aaca593377a4fe3984459fd4539481263b4cd ] msmgpio irqchip was not using return value of irq_set_irq_wake() callback since previously GIC-v3 irqchip neither had IRQCHIP_SKIP_SET_WAKE flag nor it implemented .irq_set_wake callback. This lead to irq_set_irq_wake() return error -ENXIO. However from 'commit 4110b5cbb014 ("irqchip/gic-v3: Allow interrupt to be configured as wake-up sources")' GIC irqchip has IRQCHIP_SKIP_SET_WAKE flag. Use return value from irq_set_irq_wake() and irq_chip_set_wake_parent() instead of always returning success. Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy") Signed-off-by: Maulik Shah Signed-off-by: Marc Zyngier Tested-by: Stephen Boyd Reviewed-by: Douglas Anderson Reviewed-by: Stephen Boyd Acked-by: Bjorn Andersson Acked-by: Linus Walleij Link: https://lore.kernel.org/r/1601267524-20199-3-git-send-email-mkshah@codeaurora.org Signed-off-by: Sasha Levin commit 82418bfc0c6916089b14ae55e67676d0f198cb60 Author: Maulik Shah Date: Mon Sep 28 10:01:59 2020 +0530 pinctrl: qcom: Set IRQCHIP_SET_TYPE_MASKED and IRQCHIP_MASK_ON_SUSPEND flags [ Upstream commit c5f72aeb659eb2f809b9531d759651514d42aa3a ] Both IRQCHIP_SET_TYPE_MASKED and IRQCHIP_MASK_ON_SUSPEND flags are already set for msmgpio's parent PDC irqchip but GPIO interrupts do not get masked during suspend or during setting irq type since genirq checks irqchip flag of msmgpio irqchip which forwards these calls to its parent PDC irqchip. Add irqchip specific flags for msmgpio irqchip to mask non wakeirqs during suspend and mask before setting irq type. Masking before changing type make sures any spurious interrupt is not detected during this operation. Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy") Signed-off-by: Maulik Shah Signed-off-by: Marc Zyngier Tested-by: Stephen Boyd Reviewed-by: Douglas Anderson Acked-by: Bjorn Andersson Acked-by: Linus Walleij Link: https://lore.kernel.org/r/1601267524-20199-2-git-send-email-mkshah@codeaurora.org Signed-off-by: Sasha Levin commit b1bee36f3371360f308c1d1f5a615d8c54b0bd9e Author: Colin Ian King Date: Thu Oct 1 12:39:00 2020 +0100 x86/events/amd/iommu: Fix sizeof mismatch [ Upstream commit 59d5396a4666195f89a67e118e9e627ddd6f53a1 ] An incorrect sizeof is being used, struct attribute ** is not correct, it should be struct attribute *. Note that since ** is the same size as * this is not causing any issues. Improve this fix by using sizeof(*attrs) as this allows us to not even reference the type of the pointer. Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)") Fixes: 51686546304f ("x86/events/amd/iommu: Fix sysfs perf attribute groups") Signed-off-by: Colin Ian King Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20201001113900.58889-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit 537a9156a67aeec0a8491000aeb842e9dbfda265 Author: Libing Zhou Date: Thu Aug 20 10:56:41 2020 +0800 x86/nmi: Fix nmi_handle() duration miscalculation [ Upstream commit f94c91f7ba3ba7de2bc8aa31be28e1abb22f849e ] When nmi_check_duration() is checking the time an NMI handler took to execute, the whole_msecs value used should be read from the @duration argument, not from the ->max_duration, the latter being used to store the current maximal duration. [ bp: Rewrite commit message. ] Fixes: 248ed51048c4 ("x86/nmi: Remove irq_work from the long duration NMI handler") Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Libing Zhou Signed-off-by: Borislav Petkov Cc: Changbin Du Link: https://lkml.kernel.org/r/20200820025641.44075-1-libing.zhou@nokia-sbell.com Signed-off-by: Sasha Levin commit 86a891c752af3db9635d429204fc6f8218e95ab8 Author: Kan Liang Date: Mon Sep 28 06:32:40 2020 -0700 perf/x86/intel/uncore: Fix the scale of the IMC free-running events [ Upstream commit 8191016a026b8dfbb14dea64efc8e723ee99fe65 ] The "MiB" result of the IMC free-running bandwidth events, uncore_imc_free_running/read/ and uncore_imc_free_running/write/ are 16 times too small. The "MiB" value equals the raw IMC free-running bandwidth counter value times a "scale" which is inaccurate. The IMC free-running bandwidth events should be incremented per 64B cache line, not DWs (4 bytes). The "scale" should be 6.103515625e-5. Fix the "scale" for both Snow Ridge and Ice Lake. Fixes: 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore support") Fixes: ee49532b38dd ("perf/x86/intel/uncore: Add IMC uncore support for Snow Ridge") Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200928133240.12977-1-kan.liang@linux.intel.com Signed-off-by: Sasha Levin commit 5bd034c922f7211fce18102af34c17054801f342 Author: Alexander Antonov Date: Mon Sep 28 13:21:33 2020 +0300 perf/x86/intel/uncore: Fix for iio mapping on Skylake Server [ Upstream commit f797f05d917ffef94249ee0aec4c14a5b50517b2 ] Introduced early attributes /sys/devices/uncore_iio_/die* are initialized by skx_iio_set_mapping(), however, for example, for multiple segment platforms skx_iio_get_topology() returns -EPERM before a list of attributes in skx_iio_mapping_group will have been initialized. As a result the list is being NULL. Thus the warning "sysfs: (bin_)attrs not set by subsystem for group: uncore_iio_*/" appears and uncore_iio pmus are not available in sysfs. Clear IIO attr_update to properly handle the cases when topology information cannot be retrieved. Fixes: bb42b3d39781 ("perf/x86/intel/uncore: Expose an Uncore unit to IIO PMON mapping") Reported-by: Kyle Meyer Suggested-by: Kan Liang Signed-off-by: Alexander Antonov Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Alexei Budankov Reviewed-by: Kan Liang Link: https://lkml.kernel.org/r/20200928102133.61041-1-alexander.antonov@linux.intel.com Signed-off-by: Sasha Levin commit 91d2a7e8e91b0b0e913820b69e3e4eb82a6b1dd6 Author: Kan Liang Date: Fri Sep 25 06:49:05 2020 -0700 perf/x86/intel/uncore: Reduce the number of CBOX counters [ Upstream commit ee139385432e919f4d1f59b80edbc073cdae1391 ] An oops is triggered by the fuzzy test. [ 327.853081] unchecked MSR access error: RDMSR from 0x70c at rIP: 0xffffffffc082c820 (uncore_msr_read_counter+0x10/0x50 [intel_uncore]) [ 327.853083] Call Trace: [ 327.853085] [ 327.853089] uncore_pmu_event_start+0x85/0x170 [intel_uncore] [ 327.853093] uncore_pmu_event_add+0x1a4/0x410 [intel_uncore] [ 327.853097] ? event_sched_in.isra.118+0xca/0x240 There are 2 GP counters for each CBOX, but the current code claims 4 counters. Accessing the invalid registers triggers the oops. Fixes: 6e394376ee89 ("perf/x86/intel/uncore: Add Intel Icelake uncore support") Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200925134905.8839-3-kan.liang@linux.intel.com Signed-off-by: Sasha Levin commit ed3671167ba556baf369f0847d5610dde22e068e Author: Kan Liang Date: Fri Sep 25 06:49:04 2020 -0700 perf/x86/intel/uncore: Update Ice Lake uncore units [ Upstream commit 8f5d41f3a0f495435c88ebba8fc150c931c10fef ] There are some updates for the Icelake model specific uncore performance monitors. (The update can be found at 10th generation intel core processors families specification update Revision 004, ICL068) 1) Counter 0 of ARB uncore unit is not available for software use 2) The global 'enable bit' (bit 29) and 'freeze bit' (bit 31) of MSR_UNC_PERF_GLOBAL_CTRL cannot be used to control counter behavior. Needs to use local enable in event select MSR. Accessing the modified bit/registers will be ignored by HW. Users may observe inaccurate results with the current code. The changes of the MSR_UNC_PERF_GLOBAL_CTRL imply that groups cannot be read atomically anymore. Although the error of the result for a group becomes a bit bigger, it still far lower than not using a group. The group support is still kept. Only Remove the *_box() related implementation. Since the counter 0 of ARB uncore unit is not available, update the MSR address for the ARB uncore unit. There is no change for IMC uncore unit, which only include free-running counters. Fixes: 6e394376ee89 ("perf/x86/intel/uncore: Add Intel Icelake uncore support") Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200925134905.8839-2-kan.liang@linux.intel.com Signed-off-by: Sasha Levin commit 30a573d492814cd276336734bf05c007f4d8a9f5 Author: Alexandru Elisei Date: Thu Sep 24 12:07:00 2020 +0100 arm64: perf: Add missing ISB in armv8pmu_enable_counter() [ Upstream commit 490d7b7c0845eacf5593db333fd2ae7715416e16 ] Writes to the PMXEVTYPER_EL0 register are not self-synchronising. In armv8pmu_enable_event(), the PE can reorder configuring the event type after we have enabled the counter and the interrupt. This can lead to an interrupt being asserted because of the previous event type that we were counting using the same counter, not the one that we've just configured. The same rationale applies to writes to the PMINTENSET_EL1 register. The PE can reorder enabling the interrupt at any point in the future after we have enabled the event. Prevent both situations from happening by adding an ISB just before we enable the event counter. Fixes: 030896885ade ("arm64: Performance counters support") Reported-by: Julien Thierry Signed-off-by: Alexandru Elisei Tested-by: Sumit Garg (Developerbox) Cc: Julien Thierry Cc: Will Deacon Cc: Mark Rutland Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: Catalin Marinas Link: https://lore.kernel.org/r/20200924110706.254996-2-alexandru.elisei@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 0823fb41f994509a1da9f78020839bc7df8bc8a1 Author: Barry Song Date: Mon Sep 21 23:18:49 2020 +0100 sched/fair: Use dst group while checking imbalance for NUMA balancer [ Upstream commit 233e7aca4c8a2c764f556bba9644c36154017e7f ] Barry Song noted the following Something is wrong. In find_busiest_group(), we are checking if src has higher load, however, in task_numa_find_cpu(), we are checking if dst will have higher load after balancing. It seems it is not sensible to check src. It maybe cause wrong imbalance value, for example, if dst_running = env->dst_stats.nr_running + 1 results in 3 or above, and src_running = env->src_stats.nr_running - 1 results in 1; The current code is thinking imbalance as 0 since src_running is smaller than 2. This is inconsistent with load balancer. Basically, in find_busiest_group(), the NUMA imbalance is ignored if moving a task "from an almost idle domain" to a "domain with spare capacity". This patch forbids movement "from a misplaced domain" to "an almost idle domain" as that is closer to what the CPU load balancer expects. This patch is not a universal win. The old behaviour was intended to allow a task from an almost idle NUMA node to migrate to its preferred node if the destination had capacity but there are corner cases. For example, a NAS compute load could be parallelised to use 1/3rd of available CPUs but not all those potential tasks are active at all times allowing this logic to trigger. An obvious example is specjbb 2005 running various numbers of warehouses on a 2 socket box with 80 cpus. specjbb 5.9.0-rc4 5.9.0-rc4 vanilla dstbalance-v1r1 Hmean tput-1 46425.00 ( 0.00%) 43394.00 * -6.53%* Hmean tput-2 98416.00 ( 0.00%) 96031.00 * -2.42%* Hmean tput-3 150184.00 ( 0.00%) 148783.00 * -0.93%* Hmean tput-4 200683.00 ( 0.00%) 197906.00 * -1.38%* Hmean tput-5 236305.00 ( 0.00%) 245549.00 * 3.91%* Hmean tput-6 281559.00 ( 0.00%) 285692.00 * 1.47%* Hmean tput-7 338558.00 ( 0.00%) 334467.00 * -1.21%* Hmean tput-8 340745.00 ( 0.00%) 372501.00 * 9.32%* Hmean tput-9 424343.00 ( 0.00%) 413006.00 * -2.67%* Hmean tput-10 421854.00 ( 0.00%) 434261.00 * 2.94%* Hmean tput-11 493256.00 ( 0.00%) 485330.00 * -1.61%* Hmean tput-12 549573.00 ( 0.00%) 529959.00 * -3.57%* Hmean tput-13 593183.00 ( 0.00%) 555010.00 * -6.44%* Hmean tput-14 588252.00 ( 0.00%) 599166.00 * 1.86%* Hmean tput-15 623065.00 ( 0.00%) 642713.00 * 3.15%* Hmean tput-16 703924.00 ( 0.00%) 660758.00 * -6.13%* Hmean tput-17 666023.00 ( 0.00%) 697675.00 * 4.75%* Hmean tput-18 761502.00 ( 0.00%) 758360.00 * -0.41%* Hmean tput-19 796088.00 ( 0.00%) 798368.00 * 0.29%* Hmean tput-20 733564.00 ( 0.00%) 823086.00 * 12.20%* Hmean tput-21 840980.00 ( 0.00%) 856711.00 * 1.87%* Hmean tput-22 804285.00 ( 0.00%) 872238.00 * 8.45%* Hmean tput-23 795208.00 ( 0.00%) 889374.00 * 11.84%* Hmean tput-24 848619.00 ( 0.00%) 966783.00 * 13.92%* Hmean tput-25 750848.00 ( 0.00%) 903790.00 * 20.37%* Hmean tput-26 780523.00 ( 0.00%) 962254.00 * 23.28%* Hmean tput-27 1042245.00 ( 0.00%) 991544.00 * -4.86%* Hmean tput-28 1090580.00 ( 0.00%) 1035926.00 * -5.01%* Hmean tput-29 999483.00 ( 0.00%) 1082948.00 * 8.35%* Hmean tput-30 1098663.00 ( 0.00%) 1113427.00 * 1.34%* Hmean tput-31 1125671.00 ( 0.00%) 1134175.00 * 0.76%* Hmean tput-32 968167.00 ( 0.00%) 1250286.00 * 29.14%* Hmean tput-33 1077676.00 ( 0.00%) 1060893.00 * -1.56%* Hmean tput-34 1090538.00 ( 0.00%) 1090933.00 * 0.04%* Hmean tput-35 967058.00 ( 0.00%) 1107421.00 * 14.51%* Hmean tput-36 1051745.00 ( 0.00%) 1210663.00 * 15.11%* Hmean tput-37 1019465.00 ( 0.00%) 1351446.00 * 32.56%* Hmean tput-38 1083102.00 ( 0.00%) 1064541.00 * -1.71%* Hmean tput-39 1232990.00 ( 0.00%) 1303623.00 * 5.73%* Hmean tput-40 1175542.00 ( 0.00%) 1340943.00 * 14.07%* Hmean tput-41 1127826.00 ( 0.00%) 1339492.00 * 18.77%* Hmean tput-42 1198313.00 ( 0.00%) 1411023.00 * 17.75%* Hmean tput-43 1163733.00 ( 0.00%) 1228253.00 * 5.54%* Hmean tput-44 1305562.00 ( 0.00%) 1357886.00 * 4.01%* Hmean tput-45 1326752.00 ( 0.00%) 1406061.00 * 5.98%* Hmean tput-46 1339424.00 ( 0.00%) 1418451.00 * 5.90%* Hmean tput-47 1415057.00 ( 0.00%) 1381570.00 * -2.37%* Hmean tput-48 1392003.00 ( 0.00%) 1421167.00 * 2.10%* Hmean tput-49 1408374.00 ( 0.00%) 1418659.00 * 0.73%* Hmean tput-50 1359822.00 ( 0.00%) 1391070.00 * 2.30%* Hmean tput-51 1414246.00 ( 0.00%) 1392679.00 * -1.52%* Hmean tput-52 1432352.00 ( 0.00%) 1354020.00 * -5.47%* Hmean tput-53 1387563.00 ( 0.00%) 1409563.00 * 1.59%* Hmean tput-54 1406420.00 ( 0.00%) 1388711.00 * -1.26%* Hmean tput-55 1438804.00 ( 0.00%) 1387472.00 * -3.57%* Hmean tput-56 1399465.00 ( 0.00%) 1400296.00 * 0.06%* Hmean tput-57 1428132.00 ( 0.00%) 1396399.00 * -2.22%* Hmean tput-58 1432385.00 ( 0.00%) 1386253.00 * -3.22%* Hmean tput-59 1421612.00 ( 0.00%) 1371416.00 * -3.53%* Hmean tput-60 1429423.00 ( 0.00%) 1389412.00 * -2.80%* Hmean tput-61 1396230.00 ( 0.00%) 1351122.00 * -3.23%* Hmean tput-62 1418396.00 ( 0.00%) 1383098.00 * -2.49%* Hmean tput-63 1409918.00 ( 0.00%) 1374662.00 * -2.50%* Hmean tput-64 1410236.00 ( 0.00%) 1376216.00 * -2.41%* Hmean tput-65 1396405.00 ( 0.00%) 1364418.00 * -2.29%* Hmean tput-66 1395975.00 ( 0.00%) 1357326.00 * -2.77%* Hmean tput-67 1392986.00 ( 0.00%) 1349642.00 * -3.11%* Hmean tput-68 1386541.00 ( 0.00%) 1343261.00 * -3.12%* Hmean tput-69 1374407.00 ( 0.00%) 1342588.00 * -2.32%* Hmean tput-70 1377513.00 ( 0.00%) 1334654.00 * -3.11%* Hmean tput-71 1369319.00 ( 0.00%) 1334952.00 * -2.51%* Hmean tput-72 1354635.00 ( 0.00%) 1329005.00 * -1.89%* Hmean tput-73 1350933.00 ( 0.00%) 1318942.00 * -2.37%* Hmean tput-74 1351714.00 ( 0.00%) 1316347.00 * -2.62%* Hmean tput-75 1352198.00 ( 0.00%) 1309974.00 * -3.12%* Hmean tput-76 1349490.00 ( 0.00%) 1286064.00 * -4.70%* Hmean tput-77 1336131.00 ( 0.00%) 1303684.00 * -2.43%* Hmean tput-78 1308896.00 ( 0.00%) 1271024.00 * -2.89%* Hmean tput-79 1326703.00 ( 0.00%) 1290862.00 * -2.70%* Hmean tput-80 1336199.00 ( 0.00%) 1291629.00 * -3.34%* The performance at the mid-point is better but not universally better. The patch is a mixed bag depending on the workload, machine and overall levels of utilisation. Sometimes it's better (sometimes much better), other times it is worse (sometimes much worse). Given that there isn't a universally good decision in this section and more people seem to prefer the patch then it may be best to keep the LB decisions consistent and revisit imbalance handling when the load balancer code changes settle down. Jirka Hladky added the following observation. Our results are mostly in line with what you see. We observe big gains (20-50%) when the system is loaded to 1/3 of the maximum capacity and mixed results at the full load - some workloads benefit from the patch at the full load, others not, but performance changes at the full load are mostly within the noise of results (+/-5%). Overall, we think this patch is helpful. [mgorman@techsingularity.net: Rewrote changelog] Fixes: fb86f5b211 ("sched/numa: Use similar logic to the load balancer for moving between domains with spare capacity") Signed-off-by: Barry Song Signed-off-by: Mel Gorman Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200921221849.GI3179@techsingularity.net Signed-off-by: Sasha Levin commit b4e623ddf50614efebdd65f72068820e6b6ae9fc Author: Xunlei Pang Date: Thu Sep 24 14:48:47 2020 +0800 sched/fair: Fix wrong cpu selecting from isolated domain [ Upstream commit df3cb4ea1fb63ff326488efd671ba3c39034255e ] We've met problems that occasionally tasks with full cpumask (e.g. by putting it into a cpuset or setting to full affinity) were migrated to our isolated cpus in production environment. After some analysis, we found that it is due to the current select_idle_smt() not considering the sched_domain mask. Steps to reproduce on my 31-CPU hyperthreads machine: 1. with boot parameter: "isolcpus=domain,2-31" (thread lists: 0,16 and 1,17) 2. cgcreate -g cpu:test; cgexec -g cpu:test "test_threads" 3. some threads will be migrated to the isolated cpu16~17. Fix it by checking the valid domain mask in select_idle_smt(). Fixes: 10e2f1acd010 ("sched/core: Rewrite and improve select_idle_siblings()) Reported-by: Wetp Zhang Signed-off-by: Xunlei Pang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Jiang Biao Reviewed-by: Vincent Guittot Link: https://lkml.kernel.org/r/1600930127-76857-1-git-send-email-xlpang@linux.alibaba.com Signed-off-by: Sasha Levin commit 797f596715c71f47cc85b0a19ad286da2fd0c9cf Author: Mark Salter Date: Tue Sep 15 16:41:10 2020 -0400 drivers/perf: thunderx2_pmu: Fix memory resource error handling [ Upstream commit 688494a407d1419a6b158c644b262c61cde39f48 ] In tx2_uncore_pmu_init_dev(), a call to acpi_dev_get_resources() is used to create a list _CRS resources which is searched for the device base address. There is an error check following this: if (!rentry->res) return NULL In no case, will rentry->res be NULL, so the test is useless. Even if the test worked, it comes before the resource list memory is freed. None of this really matters as long as the ACPI table has the memory resource. Let's clean it up so that it makes sense and will give a meaningful error should firmware leave out the memory resource. Fixes: 69c32972d593 ("drivers/perf: Add Cavium ThunderX2 SoC UNCORE PMU driver") Signed-off-by: Mark Salter Link: https://lore.kernel.org/r/20200915204110.326138-2-msalter@redhat.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 6372e3fb57413c679b3c079358b989aadebd6845 Author: Mark Salter Date: Tue Sep 15 16:41:09 2020 -0400 drivers/perf: xgene_pmu: Fix uninitialized resource struct [ Upstream commit a76b8236edcf5b785d044b930f9e14ad02b4a484 ] This splat was reported on newer Fedora kernels booting on certain X-gene based machines: xgene-pmu APMC0D83:00: X-Gene PMU version 3 Unable to handle kernel read from unreadable memory at virtual \ address 0000000000004006 ... Call trace: string+0x50/0x100 vsnprintf+0x160/0x750 devm_kvasprintf+0x5c/0xb4 devm_kasprintf+0x54/0x60 __devm_ioremap_resource+0xdc/0x1a0 devm_ioremap_resource+0x14/0x20 acpi_get_pmu_hw_inf.isra.0+0x84/0x15c acpi_pmu_dev_add+0xbc/0x21c acpi_ns_walk_namespace+0x16c/0x1e4 acpi_walk_namespace+0xb4/0xfc xgene_pmu_probe_pmu_dev+0x7c/0xe0 xgene_pmu_probe.part.0+0x2c0/0x310 xgene_pmu_probe+0x54/0x64 platform_drv_probe+0x60/0xb4 really_probe+0xe8/0x4a0 driver_probe_device+0xe4/0x100 device_driver_attach+0xcc/0xd4 __driver_attach+0xb0/0x17c bus_for_each_dev+0x6c/0xb0 driver_attach+0x30/0x40 bus_add_driver+0x154/0x250 driver_register+0x84/0x140 __platform_driver_register+0x54/0x60 xgene_pmu_driver_init+0x28/0x34 do_one_initcall+0x40/0x204 do_initcalls+0x104/0x144 kernel_init_freeable+0x198/0x210 kernel_init+0x20/0x12c ret_from_fork+0x10/0x18 Code: 91000400 110004e1 eb08009f 540000c0 (38646846) ---[ end trace f08c10566496a703 ]--- This is due to use of an uninitialized local resource struct in the xgene pmu driver. The thunderx2_pmu driver avoids this by using the resource list constructed by acpi_dev_get_resources() rather than using a callback from that function. The callback in the xgene driver didn't fully initialize the resource. So get rid of the callback and search the resource list as done by thunderx2. Fixes: 832c927d119b ("perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver") Signed-off-by: Mark Salter Link: https://lore.kernel.org/r/20200915204110.326138-1-msalter@redhat.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 621f8f26aa36b4a64f28dec5d1775c8178c6d0e6 Author: peterz@infradead.org Date: Tue Sep 15 16:30:28 2020 +0200 seqlock: Unbreak lockdep [ Upstream commit 267580db047ef428a70bef8287ca62c5a450c139 ] seqcount_LOCKNAME_init() needs to be a macro due to the lockdep annotation in seqcount_init(). Since a macro cannot define another macro, we need to effectively revert commit: e4e9ab3f9f91 ("seqlock: Fold seqcount_LOCKNAME_init() definition"). Fixes: e4e9ab3f9f91 ("seqlock: Fold seqcount_LOCKNAME_init() definition") Reported-by: Qian Cai Debugged-by: Boqun Feng Signed-off-by: Peter Zijlstra (Intel) Tested-by: Qian Cai Link: https://lkml.kernel.org/r/20200915143028.GB2674@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 273d706b5afe2e0bc24135d536c05567014d165e Author: Amit Daniel Kachhap Date: Mon Sep 14 14:06:51 2020 +0530 arm64: kprobe: add checks for ARMv8.3-PAuth combined instructions [ Upstream commit 93396936ed0ce2c6f44140bd14728611d0bb065e ] Currently the ARMv8.3-PAuth combined branch instructions (braa, retaa etc.) are not simulated for out-of-line execution with a handler. Hence the uprobe of such instructions leads to kernel warnings in a loop as they are not explicitly checked and fall into INSN_GOOD categories. Other combined instructions like LDRAA and LDRBB can be probed. The issue of the combined branch instructions is fixed by adding group definitions of all such instructions and rejecting their probes. The instruction groups added are br_auth(braa, brab, braaz and brabz), blr_auth(blraa, blrab, blraaz and blrabz), ret_auth(retaa and retab) and eret_auth(eretaa and eretab). Warning log: WARNING: CPU: 0 PID: 156 at arch/arm64/kernel/probes/uprobes.c:182 uprobe_single_step_handler+0x34/0x50 Modules linked in: CPU: 0 PID: 156 Comm: func Not tainted 5.9.0-rc3 #188 Hardware name: Foundation-v8A (DT) pstate: 804003c9 (Nzcv DAIF +PAN -UAO BTYPE=--) pc : uprobe_single_step_handler+0x34/0x50 lr : single_step_handler+0x70/0xf8 sp : ffff800012af3e30 x29: ffff800012af3e30 x28: ffff000878723b00 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000060001000 x22: 00000000cb000022 x21: ffff800012065ce8 x20: ffff800012af3ec0 x19: ffff800012068d50 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffff800010085c90 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff80001205a9c8 x5 : ffff80001205a000 x4 : ffff80001233db80 x3 : ffff8000100a7a60 x2 : 0020000000000003 x1 : 0000fffffffff008 x0 : ffff800012af3ec0 Call trace: uprobe_single_step_handler+0x34/0x50 single_step_handler+0x70/0xf8 do_debug_exception+0xb8/0x130 el0_sync_handler+0x138/0x1b8 el0_sync+0x158/0x180 Fixes: 74afda4016a7 ("arm64: compile the kernel with ptrauth return address signing") Fixes: 04ca3204fa09 ("arm64: enable pointer authentication") Signed-off-by: Amit Daniel Kachhap Reviewed-by: Dave Martin Link: https://lore.kernel.org/r/20200914083656.21428-2-amit.kachhap@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2006ad73abd714a7e0e82689d2dc415bc8d59c30 Author: YueHaibing Date: Wed Aug 26 11:53:21 2020 +0800 irqchip/ti-sci-intr: Fix unsigned comparison to zero [ Upstream commit 8ddf1905a904ca86d71ca1c435e4b0b2a0b70df8 ] ti_sci_intr_xlate_irq() return -ENOENT on fail, p_hwirq should be int type. Fixes: a5b659bd4bc7 ("irqchip/ti-sci-intr: Add support for INTR being a parent to INTR") Signed-off-by: YueHaibing Signed-off-by: Marc Zyngier Acked-by: Lokesh Vutla Link: https://lore.kernel.org/r/20200826035321.18620-1-yuehaibing@huawei.com Signed-off-by: Sasha Levin commit e3e35a1e470e27f2bfc75ca0e6152bb3c4950972 Author: YueHaibing Date: Wed Aug 26 11:54:30 2020 +0800 irqchip/ti-sci-inta: Fix unsigned comparison to zero [ Upstream commit 4c9b1bfaa5039fee650f4de514a8e70ae976fc2f ] ti_sci_inta_xlate_irq() return -ENOENT on fail, p_hwirq should be int type. Fixes: 5c4b585d2910 ("irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC") Signed-off-by: YueHaibing Signed-off-by: Marc Zyngier Acked-by: Lokesh Vutla Link: https://lore.kernel.org/r/20200826035430.21060-1-yuehaibing@huawei.com Signed-off-by: Sasha Levin commit 928c35799946b2917f6b64a3c88f6e7dcae59dfa Author: Arvind Sankar Date: Mon Sep 7 17:39:19 2020 -0400 x86/fpu: Allow multiple bits in clearcpuid= parameter [ Upstream commit 0a4bb5e5507a585532cc413125b921c8546fc39f ] Commit 0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as early XSAVE argument") changed clearcpuid parsing from __setup() to cmdline_find_option(). While the __setup() function would have been called for each clearcpuid= parameter on the command line, cmdline_find_option() will only return the last one, so the change effectively made it impossible to disable more than one bit. Allow a comma-separated list of bit numbers as the argument for clearcpuid to allow multiple bits to be disabled again. Log the bits being disabled for informational purposes. Also fix the check on the return value of cmdline_find_option(). It returns -1 when the option is not found, so testing as a boolean is incorrect. Fixes: 0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as early XSAVE argument") Signed-off-by: Arvind Sankar Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200907213919.2423441-1-nivedita@alum.mit.edu Signed-off-by: Sasha Levin commit 3fd6ca1060118c1fad59c52ee653753a7c3ca3ec Author: Kan Liang Date: Wed Sep 2 14:06:49 2020 -0700 perf/x86/intel/ds: Fix x86_pmu_stop warning for large PEBS [ Upstream commit 35d1ce6bec133679ff16325d335217f108b84871 ] A warning as below may be triggered when sampling with large PEBS. [ 410.411250] perf: interrupt took too long (72145 > 71975), lowering kernel.perf_event_max_sample_rate to 2000 [ 410.724923] ------------[ cut here ]------------ [ 410.729822] WARNING: CPU: 0 PID: 16397 at arch/x86/events/core.c:1422 x86_pmu_stop+0x95/0xa0 [ 410.933811] x86_pmu_del+0x50/0x150 [ 410.937304] event_sched_out.isra.0+0xbc/0x210 [ 410.941751] group_sched_out.part.0+0x53/0xd0 [ 410.946111] ctx_sched_out+0x193/0x270 [ 410.949862] __perf_event_task_sched_out+0x32c/0x890 [ 410.954827] ? set_next_entity+0x98/0x2d0 [ 410.958841] __schedule+0x592/0x9c0 [ 410.962332] schedule+0x5f/0xd0 [ 410.965477] exit_to_usermode_loop+0x73/0x120 [ 410.969837] prepare_exit_to_usermode+0xcd/0xf0 [ 410.974369] ret_from_intr+0x2a/0x3a [ 410.977946] RIP: 0033:0x40123c [ 411.079661] ---[ end trace bc83adaea7bb664a ]--- In the non-overflow context, e.g., context switch, with large PEBS, perf may stop an event twice. An example is below. //max_samples_per_tick is adjusted to 2 //NMI is triggered intel_pmu_handle_irq() handle_pmi_common() drain_pebs() __intel_pmu_pebs_event() perf_event_overflow() __perf_event_account_interrupt() hwc->interrupts = 1 return 0 //A context switch happens right after the NMI. //In the same tick, the perf_throttled_seq is not changed. perf_event_task_sched_out() perf_pmu_sched_task() intel_pmu_drain_pebs_buffer() __intel_pmu_pebs_event() perf_event_overflow() __perf_event_account_interrupt() ++hwc->interrupts >= max_samples_per_tick return 1 x86_pmu_stop(); # First stop perf_event_context_sched_out() task_ctx_sched_out() ctx_sched_out() event_sched_out() x86_pmu_del() x86_pmu_stop(); # Second stop and trigger the warning Perf should only invoke the perf_event_overflow() in the overflow context. Current drain_pebs() is called from: - handle_pmi_common() -- overflow context - intel_pmu_pebs_sched_task() -- non-overflow context - intel_pmu_pebs_disable() -- non-overflow context - intel_pmu_auto_reload_read() -- possible overflow context With PERF_SAMPLE_READ + PERF_FORMAT_GROUP, the function may be invoked in the NMI handler. But, before calling the function, the PEBS buffer has already been drained. The __intel_pmu_pebs_event() will not be called in the possible overflow context. To fix the issue, an indicator is required to distinguish between the overflow context aka handle_pmi_common() and other cases. The dummy regs pointer can be used as the indicator. In the non-overflow context, perf should treat the last record the same as other PEBS records, and doesn't invoke the generic overflow handler. Fixes: 21509084f999 ("perf/x86/intel: Handle multiple records in the PEBS buffer") Reported-by: Like Xu Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Tested-by: Like Xu Link: https://lkml.kernel.org/r/20200902210649.2743-1-kan.liang@linux.intel.com Signed-off-by: Sasha Levin commit 3682a4b42de5f084635e84bd0e37c23fe1da0d23 Author: Krzysztof Kozlowski Date: Thu Aug 27 09:07:43 2020 +0200 EDAC/ti: Fix handling of platform_get_irq() error [ Upstream commit 66077adb70a2a9e92540155b2ace33ec98299c90 ] platform_get_irq() returns a negative error number on error. In such a case, comparison to 0 would pass the check therefore check the return value properly, whether it is negative. [ bp: Massage commit message. ] Fixes: 86a18ee21e5e ("EDAC, ti: Add support for TI keystone and DRA7xx EDAC") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Borislav Petkov Reviewed-by: Tero Kristo Link: https://lkml.kernel.org/r/20200827070743.26628-2-krzk@kernel.org Signed-off-by: Sasha Levin commit 0b60f7353faf8a02f955238675b04bf7874c725e Author: Krzysztof Kozlowski Date: Thu Aug 27 09:07:42 2020 +0200 EDAC/aspeed: Fix handling of platform_get_irq() error [ Upstream commit afce6996943be265fa39240b67025cfcb1bcdfb1 ] platform_get_irq() returns a negative error number on error. In such a case, comparison to 0 would pass the check therefore check the return value properly, whether it is negative. [ bp: Massage commit message. ] Fixes: 9b7e6242ee4e ("EDAC, aspeed: Add an Aspeed AST2500 EDAC driver") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Borislav Petkov Reviewed-by: Stefan Schaeckeler Link: https://lkml.kernel.org/r/20200827070743.26628-1-krzk@kernel.org Signed-off-by: Sasha Levin commit 2c9b78a63f82062ef0e230930ff850c5429a15ab Author: Dinghao Liu Date: Wed Aug 26 20:14:37 2020 +0800 EDAC/i5100: Fix error handling order in i5100_init_one() [ Upstream commit 857a3139bd8be4f702c030c8ca06f3fd69c1741a ] When pci_get_device_func() fails, the driver doesn't need to execute pci_dev_put(). mci should still be freed, though, to prevent a memory leak. When pci_enable_device() fails, the error injection PCI device "einj" doesn't need to be disabled either. [ bp: Massage commit message, rename label to "bail_mc_free". ] Fixes: 52608ba205461 ("i5100_edac: probe for device 19 function 0") Signed-off-by: Dinghao Liu Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200826121437.31606-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin commit ab3edd32cbc2206b2115965a75a6450b72b0a914 Author: Randy Dunlap Date: Mon Aug 31 09:38:58 2020 -0700 microblaze: fix kbuild redundant file warning [ Upstream commit 4a17e8513376bb23f814d3e340a5692a12c69369 ] Fix build warning since this file is already listed in include/asm-generic/Kbuild. ../scripts/Makefile.asm-generic:25: redundant generic-y found in arch/microblaze/include/asm/Kbuild: hw_irq.h Fixes: 630f289b7114 ("asm-generic: make more kernel-space headers mandatory") Signed-off-by: Randy Dunlap Cc: Michal Simek Cc: Michal Simek Cc: Masahiro Yamada Reviewed-by: Masahiro Yamada Link: https://lore.kernel.org/r/4d992aee-8a69-1769-e622-8d6d6e316346@infradead.org Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 362af05310119939a68a5b3564a04a9995098dae Author: Lukasz Luba Date: Mon Aug 10 09:30:04 2020 +0100 sched/fair: Fix wrong negative conversion in find_energy_efficient_cpu() [ Upstream commit da0777d35f47892f359c3f73ea155870bb595700 ] In find_energy_efficient_cpu() 'cpu_cap' could be less that 'util'. It might be because of RT, DL (so higher sched class than CFS), irq or thermal pressure signal, which reduce the capacity value. In such situation the result of 'cpu_cap - util' might be negative but stored in the unsigned long. Then it might be compared with other unsigned long when uclamp_rq_util_with() reduced the 'util' such that is passes the fits_capacity() check. Prevent this situation and make the arithmetic more safe. Fixes: 1d42509e475cd ("sched/fair: Make EAS wakeup placement consider uclamp restrictions") Signed-off-by: Lukasz Luba Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Link: https://lkml.kernel.org/r/20200810083004.26420-1-lukasz.luba@arm.com Signed-off-by: Sasha Levin commit 56acefdc255c42a797ec4eacdcda561f8ec98983 Author: Luca Stefani Date: Wed Aug 5 11:57:08 2020 +0200 RAS/CEC: Fix cec_init() prototype [ Upstream commit 85e6084e0b436cabe9c909e679937998ffbf9c9d ] late_initcall() expects a function that returns an integer. Update the function signature to match. [ bp: Massage commit message into proper sentences. ] Fixes: 9554bfe403bd ("x86/mce: Convert the CEC to use the MCE notifier") Signed-off-by: Luca Stefani Signed-off-by: Borislav Petkov Reviewed-by: Sami Tolvanen Tested-by: Sami Tolvanen Link: https://lkml.kernel.org/r/20200805095708.83939-1-luca.stefani.ge1@gmail.com Signed-off-by: Sasha Levin commit 928372ed3091f675b580b1a44287accbbfbd0247 Author: Andrei Botila Date: Tue Sep 22 19:03:24 2020 +0300 crypto: caam/qi2 - add support for more XTS key lengths commit 596efd57cfa1e1bee575e2a2df44fd8ec5e4a42d upstream. CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since it adheres strictly to the standard. All the other key lengths are accepted and processed through a fallback as long as they pass the xts_verify_key() checks. Fixes: 226853ac3ebe ("crypto: caam/qi2 - add skcipher algorithms") Cc: # v4.20+ Signed-off-by: Andrei Botila Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit f61a67ced4cf4b7126a7df9a843d32582e49c55b Author: Andrei Botila Date: Tue Sep 22 19:03:21 2020 +0300 crypto: caam/qi2 - add fallback for XTS with more than 8B IV commit 36e2d7cfdcf17b6126863d884d4200191e922524 upstream. A hardware limitation exists for CAAM until Era 9 which restricts the accelerator to IVs with only 8 bytes. When CAAM has a lower era a fallback is necessary to process 16 bytes IV. Fixes: 226853ac3ebe ("crypto: caam/qi2 - add skcipher algorithms") Cc: # v4.20+ Signed-off-by: Andrei Botila Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e9a14a26837d44733f4f89eab127fc0fbb394721 Author: Andrei Botila Date: Tue Sep 22 19:03:22 2020 +0300 crypto: caam/jr - add support for more XTS key lengths commit c91f734862664ca86dc3ee7e55f199e2bde829e4 upstream. CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since it adheres strictly to the standard. All the other key lengths are accepted and processed through a fallback as long as they pass the xts_verify_key() checks. Fixes: c6415a6016bf ("crypto: caam - add support for acipher xts(aes)") Cc: # v4.4+ Signed-off-by: Andrei Botila Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 2792f70110101b66975c1837561394e06bdc75ac Author: Andrei Botila Date: Tue Sep 22 19:03:19 2020 +0300 crypto: caam/jr - add fallback for XTS with more than 8B IV commit 9d9b14dbe077c8704d8c3546e38820d35aff2d35 upstream. A hardware limitation exists for CAAM until Era 9 which restricts the accelerator to IVs with only 8 bytes. When CAAM has a lower era a fallback is necessary to process 16 bytes IV. Fixes: c6415a6016bf ("crypto: caam - add support for acipher xts(aes)") Cc: # v4.4+ Signed-off-by: Andrei Botila Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d8c60783e13e04df2ac97ab90e5a1585ed0a36c6 Author: Andrei Botila Date: Tue Sep 22 19:03:23 2020 +0300 crypto: caam/qi - add support for more XTS key lengths commit 62b9a6690926ee199445b23fd46e6349d9057146 upstream. CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since it adheres strictly to the standard. All the other key lengths are accepted and processed through a fallback as long as they pass the xts_verify_key() checks. Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc algorithms") Cc: # v4.12+ Signed-off-by: Andrei Botila Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7ade3e6c3e9c8775339ad3fb62b2cbe635c458ec Author: Andrei Botila Date: Tue Sep 22 19:03:20 2020 +0300 crypto: caam/qi - add fallback for XTS with more than 8B IV commit 83e8aa9121380b23ebae6e413962fa2a7b52cf92 upstream. A hardware limitation exists for CAAM until Era 9 which restricts the accelerator to IVs with only 8 bytes. When CAAM has a lower era a fallback is necessary to process 16 bytes IV. Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc algorithms") Cc: # v4.12+ Signed-off-by: Andrei Botila Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit fca060ae19d53d8df1aca4012b7f50a687e92c89 Author: Herbert Xu Date: Fri Jul 31 17:03:50 2020 +1000 crypto: algif_aead - Do not set MAY_BACKLOG on the async path commit cbdad1f246dd98e6c9c32a6e5212337f542aa7e0 upstream. The async path cannot use MAY_BACKLOG because it is not meant to block, which is what MAY_BACKLOG does. On the other hand, both the sync and async paths can make use of MAY_SLEEP. Fixes: 83094e5e9e49 ("crypto: af_alg - add async support to...") Cc: Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 8bb8f23294d4ac0cbf8bdde5fd1671afd8667f4a Author: Andrei Botila Date: Tue Sep 22 19:03:25 2020 +0300 crypto: caam - add xts check for block length equal to zero commit 297b931c2a3cada230d8b84432ee982fc68cf76a upstream. XTS should not return succes when dealing with block length equal to zero. This is different than the rest of the skcipher algorithms. Fixes: 31bb2f0da1b50 ("crypto: caam - check zero-length input") Cc: # v5.4+ Signed-off-by: Andrei Botila Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ebcfbab750a8b02031644e40246ce4b798015823 Author: Roberto Sassu Date: Fri Sep 4 11:23:28 2020 +0200 ima: Don't ignore errors from crypto_shash_update() commit 60386b854008adc951c470067f90a2d85b5d520f upstream. Errors returned by crypto_shash_update() are not checked in ima_calc_boot_aggregate_tfm() and thus can be overwritten at the next iteration of the loop. This patch adds a check after calling crypto_shash_update() and returns immediately if the result is not zero. Cc: stable@vger.kernel.org Fixes: 3323eec921efd ("integrity: IMA as an integrity service provider") Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 9f924bfd967d2779622389858d95883bb1f4d3ab Author: Suravee Suthikulpanit Date: Sat Oct 3 23:27:07 2020 +0000 KVM: SVM: Initialize prev_ga_tag before use commit f6426ab9c957e97418ac5b0466538792767b1738 upstream. The function amd_ir_set_vcpu_affinity makes use of the parameter struct amd_iommu_pi_data.prev_ga_tag to determine if it should delete struct amd_iommu_pi_data from a list when not running in AVIC mode. However, prev_ga_tag is initialized only when AVIC is enabled. The non-zero uninitialized value can cause unintended code path, which ends up making use of the struct vcpu_svm.ir_list and ir_list_lock without being initialized (since they are intended only for the AVIC case). This triggers NULL pointer dereference bug in the function vm_ir_list_del with the following call trace: svm_update_pi_irte+0x3c2/0x550 [kvm_amd] ? proc_create_single_data+0x41/0x50 kvm_arch_irq_bypass_add_producer+0x40/0x60 [kvm] __connect+0x5f/0xb0 [irqbypass] irq_bypass_register_producer+0xf8/0x120 [irqbypass] vfio_msi_set_vector_signal+0x1de/0x2d0 [vfio_pci] vfio_msi_set_block+0x77/0xe0 [vfio_pci] vfio_pci_set_msi_trigger+0x25c/0x2f0 [vfio_pci] vfio_pci_set_irqs_ioctl+0x88/0xb0 [vfio_pci] vfio_pci_ioctl+0x2ea/0xed0 [vfio_pci] ? alloc_file_pseudo+0xa5/0x100 vfio_device_fops_unl_ioctl+0x26/0x30 [vfio] ? vfio_device_fops_unl_ioctl+0x26/0x30 [vfio] __x64_sys_ioctl+0x96/0xd0 do_syscall_64+0x37/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Therefore, initialize prev_ga_tag to zero before use. This should be safe because ga_tag value 0 is invalid (see function avic_vm_init). Fixes: dfa20099e26e ("KVM: SVM: Refactor AVIC vcpu initialization into avic_init_vcpu()") Signed-off-by: Suravee Suthikulpanit Message-Id: <20201003232707.4662-1-suravee.suthikulpanit@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 2cb87c3bf13ff0ba159d4ec44f379aa15d53d86c Author: Lai Jiangshan Date: Tue Sep 29 21:16:55 2020 -0700 KVM: x86: Intercept LA57 to inject #GP fault when it's reserved commit 6e1d849fa3296526e64b75fa227b6377cd0fd3da upstream. Unconditionally intercept changes to CR4.LA57 so that KVM correctly injects a #GP fault if the guest attempts to set CR4.LA57 when it's supported in hardware but not exposed to the guest. Long term, KVM needs to properly handle CR4 bits that can be under guest control but also may be reserved from the guest's perspective. But, KVM currently sets the CR4 guest/host mask only during vCPU creation, and reworking flows to change that will take a bit of elbow grease. Even if/when generic support for intercepting reserved bits exists, it's probably not worth letting the guest set CR4.LA57 directly. LA57 can't be toggled while long mode is enabled, thus it's all but guaranteed to be set once (maybe twice, e.g. by BIOS and kernel) during boot and never touched again. On the flip side, letting the guest own CR4.LA57 may incur extra VMREADs. In other words, this temporary "hack" is probably also the right long term fix. Fixes: fd8cb433734e ("KVM: MMU: Expose the LA57 feature to VM.") Cc: stable@vger.kernel.org Cc: Lai Jiangshan Signed-off-by: Lai Jiangshan [sean: rewrote changelog] Signed-off-by: Sean Christopherson Message-Id: <20200930041659.28181-2-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 8f7258f4b22129e53e95b4e28746bf3c7aab19d3 Author: Sean Christopherson Date: Wed Sep 23 11:37:28 2020 -0700 KVM: x86/mmu: Commit zap of remaining invalid pages when recovering lpages commit e89505698c9f70125651060547da4ff5046124fc upstream. Call kvm_mmu_commit_zap_page() after exiting the "prepare zap" loop in kvm_recover_nx_lpages() to finish zapping pages in the unlikely event that the loop exited due to lpage_disallowed_mmu_pages being empty. Because the recovery thread drops mmu_lock() when rescheduling, it's possible that lpage_disallowed_mmu_pages could be emptied by a different thread without to_zap reaching zero despite to_zap being derived from the number of disallowed lpages. Fixes: 1aa9b9572b105 ("kvm: x86: mmu: Recovery of shattered NX large pages") Cc: Junaid Shahid Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20200923183735.584-2-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 1ba3ea7f3b7803a5b99943e9264cefd5966c2f3c Author: Sean Christopherson Date: Wed Sep 23 11:44:47 2020 -0700 KVM: nVMX: Reload vmcs01 if getting vmcs12's pages fails commit b89d5ad00e789967a5e2c5335f75c48755bebd88 upstream. Reload vmcs01 when bailing from nested_vmx_enter_non_root_mode() as KVM expects vmcs01 to be loaded when is_guest_mode() is false. Fixes: 671ddc700fd08 ("KVM: nVMX: Don't leak L1 MMIO regions to L2") Cc: stable@vger.kernel.org Cc: Dan Cross Cc: Jim Mattson Cc: Peter Shier Signed-off-by: Sean Christopherson Message-Id: <20200923184452.980-3-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit df57471fcde21aa0cd1cd869cd70e3c7939b0a4a Author: Sean Christopherson Date: Wed Sep 23 11:44:46 2020 -0700 KVM: nVMX: Reset the segment cache when stuffing guest segs commit fc387d8daf3960c5e1bc18fa353768056f4fd394 upstream. Explicitly reset the segment cache after stuffing guest segment regs in prepare_vmcs02_rare(). Although the cache is reset when switching to vmcs02, there is nothing that prevents KVM from re-populating the cache prior to writing vmcs02 with vmcs12's values. E.g. if the vCPU is preempted after switching to vmcs02 but before prepare_vmcs02_rare(), kvm_arch_vcpu_put() will dereference GUEST_SS_AR_BYTES via .get_cpl() and cache the stale vmcs02 value. While the current code base only caches stale data in the preemption case, it's theoretically possible future code could read a segment register during the nested flow itself, i.e. this isn't technically illegal behavior in kvm_arch_vcpu_put(), although it did introduce the bug. This manifests as an unexpected nested VM-Enter failure when running with unrestricted guest disabled if the above preemption case coincides with L1 switching L2's CPL, e.g. when switching from a L2 vCPU at CPL3 to to a L2 vCPU at CPL0. stack_segment_valid() will see the new SS_SEL but the old SS_AR_BYTES and incorrectly mark the guest state as invalid due to SS.dpl != SS.rpl. Don't bother updating the cache even though prepare_vmcs02_rare() writes every segment. With unrestricted guest, guest segments are almost never read, let alone L2 guest segments. On the other hand, populating the cache requires a large number of memory writes, i.e. it's unlikely to be a net win. Updating the cache would be a win when unrestricted guest is not supported, as guest_state_valid() will immediately cache all segment registers. But, nested virtualization without unrestricted guest is dirt slow, saving some VMREADs won't change that, and every CPU manufactured in the last decade supports unrestricted guest. In other words, the extra (minor) complexity isn't worth the trouble. Note, kvm_arch_vcpu_put() may see stale data when querying guest CPL depending on when preemption occurs. This is "ok" in that the usage is imperfect by nature, i.e. it's used heuristically to improve performance but doesn't affect functionality. kvm_arch_vcpu_put() could be "fixed" by also disabling preemption while loading segments, but that's pointless and misleading as reading state from kvm_sched_{in,out}() is guaranteed to see stale data in one form or another. E.g. even if all the usage of regs_avail is fixed to call kvm_register_mark_available() after the associated state is set, the individual state might still be stale with respect to the overall vCPU state. I.e. making functional decisions in an asynchronous hook is doomed from the get go. Thankfully KVM doesn't do that. Fixes: de63ad4cf4973 ("KVM: X86: implement the logic for spinlock optimization") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20200923184452.980-2-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit cfabbcf5f55eeb5bbd94d689ebce8e94f1050896 Author: Sean Christopherson Date: Wed Aug 12 10:51:29 2020 -0700 KVM: nVMX: Morph notification vector IRQ on nested VM-Enter to pending PI commit 25bb2cf97139f81e3bb8910d26016a529019528e upstream. On successful nested VM-Enter, check for pending interrupts and convert the highest priority interrupt to a pending posted interrupt if it matches L2's notification vector. If the vCPU receives a notification interrupt before nested VM-Enter (assuming L1 disables IRQs before doing VM-Enter), the pending interrupt (for L1) should be recognized and processed as a posted interrupt when interrupts become unblocked after VM-Enter to L2. This fixes a bug where L1/L2 will get stuck in an infinite loop if L1 is trying to inject an interrupt into L2 by setting the appropriate bit in L2's PIR and sending a self-IPI prior to VM-Enter (as opposed to KVM's method of manually moving the vector from PIR->vIRR/RVI). KVM will observe the IPI while the vCPU is in L1 context and so won't immediately morph it to a posted interrupt for L2. The pending interrupt will be seen by vmx_check_nested_events(), cause KVM to force an immediate exit after nested VM-Enter, and eventually be reflected to L1 as a VM-Exit. After handling the VM-Exit, L1 will see that L2 has a pending interrupt in PIR, send another IPI, and repeat until L2 is killed. Note, posted interrupts require virtual interrupt deliveriy, and virtual interrupt delivery requires exit-on-interrupt, ergo interrupts will be unconditionally unmasked on VM-Enter if posted interrupts are enabled. Fixes: 705699a13994 ("KVM: nVMX: Enable nested posted interrupt processing") Cc: stable@vger.kernel.org Cc: Liran Alon Signed-off-by: Sean Christopherson Message-Id: <20200812175129.12172-1-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 8e8c1e70f0570c956c0d576c8c18d663acb6311b Author: Marc Zyngier Date: Thu Jul 16 17:11:08 2020 +0100 arm64: Make use of ARCH_WORKAROUND_1 even when KVM is not enabled commit b11483ef5a502663732c6ca1b58d14ff9eedd6f7 upstream. We seem to be pretending that we don't have any firmware mitigation when KVM is not compiled in, which is not quite expected. Bring back the mitigation in this case. Fixes: 4db61fef16a1 ("arm64: kvm: Modernize __smccc_workaround_1_smc_start annotations") Cc: Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 9acbff2784ed37f4d574485c607f3d4b56dbab85 Author: Steve French Date: Wed Oct 21 13:12:08 2020 -0500 smb3: fix stat when special device file and mounted with modefromsid commit 3c3317daef0afa0cd541fc9c1bfd6ce8bbf1129a upstream. When mounting with modefromsid mount option, it was possible to get the error on stat of a fifo or char or block device: "cannot stat : Operation not supported" Special devices can be stored as reparse points by some servers (e.g. Windows NFS server and when using the SMB3.1.1 POSIX Extensions) but when the modefromsid mount option is used the client attempts to get the ACL for the file which requires opening with OPEN_REPARSE_POINT create option. Signed-off-by: Steve French CC: Stable Reviewed-by: Ronnie Sahlberg Reviewed-by: Shyam Prasad N Signed-off-by: Greg Kroah-Hartman commit 417baa95b0ac126e029b1738c742d64c51c5267c Author: Steve French Date: Wed Oct 21 00:15:42 2020 -0500 smb3: do not try to cache root directory if dir leases not supported commit 3c6e65e679182d55779ef6f8582f0945af4319b0 upstream. To servers which do not support directory leases (e.g. Samba) it is wasteful to try to open_shroot (ie attempt to cache the root directory handle). Skip attempt to open_shroot when server does not indicate support for directory leases. Cuts the number of requests on mount from 17 to 15, and cuts the number of requests on stat of the root directory from 4 to 3. Signed-off-by: Steve French CC: Stable # v5.1+ Signed-off-by: Greg Kroah-Hartman commit d8e39c11f66125f49de55537a6efc8ecadf4a0f7 Author: Steve French Date: Tue Oct 20 02:02:02 2020 -0500 SMB3.1.1: Fix ids returned in POSIX query dir commit 9934430e2178d5164eb1ac91a9b092f9e7e64745 upstream. We were setting the uid/gid to the default in each dir entry in the parsing of the POSIX query dir response, rather than attempting to map the user and group SIDs returned by the server to well known SIDs (or upcall if not found). CC: Stable Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 1b890b8ae11f893fa8d2826395aa069de4fcd078 Author: Rohith Surabattula Date: Thu Oct 8 09:58:41 2020 +0000 SMB3: Resolve data corruption of TCP server info fields commit 62593011247c8a8cfeb0c86aff84688b196727c2 upstream. TCP server info field server->total_read is modified in parallel by demultiplex thread and decrypt offload worker thread. server->total_read is used in calculation to discard the remaining data of PDU which is not read into memory. Because of parallel modification, server->total_read can get corrupted and can result in discarding the valid data of next PDU. Signed-off-by: Rohith Surabattula Reviewed-by: Aurelien Aptel Reviewed-by: Pavel Shilovsky CC: Stable #5.4+ Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit c7c2f24074e8d851e8be8b7531861f3710a4dcc0 Author: Shyam Prasad N Date: Thu Oct 15 10:41:31 2020 -0700 cifs: Return the error from crypt_message when enc/dec key not found. commit 0bd294b55a5de442370c29fa53bab17aef3ff318 upstream. In crypt_message, when smb2_get_enc_key returns error, we need to return the error back to the caller. If not, we end up processing the message further, causing a kernel oops due to unwarranted access of memory. Call Trace: smb3_receive_transform+0x120/0x870 [cifs] cifs_demultiplex_thread+0xb53/0xc20 [cifs] ? cifs_handle_standard+0x190/0x190 [cifs] kthread+0x116/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x1f/0x30 Signed-off-by: Shyam Prasad N Reviewed-by: Pavel Shilovsky Reviewed-by: Ronnie Sahlberg CC: Stable Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b5244320a7729bcdd50e4d7a081b8509f7aaa4a2 Author: Dan Carpenter Date: Wed Sep 16 23:18:21 2020 +0300 cifs: remove bogus debug code commit d367cb960ce88914898cbfa43645c2e43ede9465 upstream. The "end" pointer is either NULL or it points to the next byte to parse. If there isn't a next byte then dereferencing "end" is an off-by-one out of bounds error. And, of course, if it's NULL that leads to an Oops. Printing "*end" doesn't seem very useful so let's delete this code. Also for the last debug statement, I noticed that it should be printing "sequence_end" instead of "end" so fix that as well. Reported-by: Dominik Maier Signed-off-by: Dan Carpenter Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5fc1fd5ceb236a9564e4f73b3b54f909e3605619 Author: Jian-Hong Pan Date: Wed Oct 7 13:22:25 2020 +0800 ALSA: hda/realtek: Enable audio jacks of ASUS D700SA with ALC887 commit ca184355db8e60290fa34bf61c13308e6f4f50d3 upstream. The ASUS D700SA desktop's audio (1043:2390) with ALC887 cannot detect the headset microphone and another headphone jack until ALC887_FIXUP_ASUS_HMIC and ALC887_FIXUP_ASUS_AUDIO quirks are applied. The NID 0x15 maps as the headset microphone and NID 0x19 maps as another headphone jack. Also need the function like alc887_fixup_asus_jack to enable the audio jacks. Signed-off-by: Jian-Hong Pan Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/20201007052224.22611-1-jhp@endlessos.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 91f3eabcbac8d864f7d041121ea93de51d13b636 Author: Qiu Wenbo Date: Fri Oct 2 20:44:54 2020 +0800 ALSA: hda/realtek - Add mute Led support for HP Elitebook 845 G7 commit 08befca40026136c14c3cd84f9e36c4cd20a358e upstream. After installing archlinux, the mute led and micmute led are not working at all. This patch fix this issue by applying a fixup from similar model. These mute leds are confirmed working on HP Elitebook 845 G7. Signed-off-by: Qiu Wenbo Cc: Link: https://lore.kernel.org/r/20201002124454.7240-1-qiuwenbo@kylinos.com.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2a8bc2526d183bf311593c90968a24dc42f8e2aa Author: Hui Wang Date: Mon Sep 28 16:01:17 2020 +0800 ALSA: hda/realtek - set mic to auto detect on a HP AIO machine commit 13468bfa8c58731dc9ecda1cd9b22a191114f944 upstream. Recently we enabled a HP AIO machine, we found the mic on the machine couldn't record any sound and it couldn't detect plugging and unplugging as well. Through debugging we found the mic is set to manual detect mode, after setting it to auto detect mode, it could detect plugging and unplugging and could record sound. Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20200928080117.12435-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a7a7a58d88210624fd17d28d931ca32fc984435e Author: Jeremy Szu Date: Thu Oct 8 18:56:44 2020 +0800 ALSA: hda/realtek - The front Mic on a HP machine doesn't work commit 148ebf548a1af366fc797fcc7d03f0bb92b12a79 upstream. On a HP ZCentral, the front Mic could not be detected. The codec of the HP ZCentrol is alc671 and it needs to override the pin configuration to enable the headset mic. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20201008105645.65505-1-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d46bfac2131bfdcb33a9c7738c608526b773817b Author: Lukasz Halman Date: Tue Oct 20 08:14:09 2020 +0200 ALSA: usb-audio: Line6 Pod Go interface requires static clock rate quirk commit 7da4c510abff8ad47eb2d7cc9a97def5a411947f upstream. Recently released Line6 Pod Go requires static clock rate quirk to make its usb audio interface working. Added its usb id to the list of similar line6 devices. Signed-off-by: Lukasz Halman Cc: Link: https://lore.kernel.org/r/20201020061409.GA24382@TAG009442538903 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 45819223353ea730b996ac6050a5b7707ae6f734 Author: Hui Wang Date: Thu Oct 22 11:02:21 2020 +0800 ALSA: hda - Fix the return value if cb func is already registered commit 033e4040d453f1f7111e5957a54f3019eb089cc6 upstream. If the cb function is already registered, should return the pointer of the structure hda_jack_callback which contains this cb func, but instead it returns the NULL. Now fix it by replacing func_is_already_in_callback_list() with find_callback_from_list(). Fixes: f4794c6064a8 ("ALSA: hda - Don't register a cb func if it is registered already") Reported-and-suggested-by: Dan Carpenter Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20201022030221.22393-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 979328beb55ffd3b6c5f7a713f16272d975735a5 Author: Hui Wang Date: Wed Sep 30 13:51:46 2020 +0800 ALSA: hda - Don't register a cb func if it is registered already commit f4794c6064a83d2c57b264bd299c367d172d1044 upstream. If the caller of enable_callback_mst() passes a cb func, the callee function will malloc memory and link this cb func to the list unconditionally. This will introduce problem if caller is in the hda_codec_ops.init() since the init() will be repeatedly called in the codec rt_resume(). So far, the patch_hdmi.c and patch_ca0132.c call enable_callback_mst() in the hda_codec_ops.init(). Signed-off-by: Hui Wang Cc: Link: https://lore.kernel.org/r/20200930055146.5665-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3a1b61d558cc4d681380cd594fd4b70d284cb0d2 Author: Edward Cree Date: Tue Oct 20 15:35:08 2020 +0100 sfc: move initialisation of efx->filter_sem to efx_init_struct() [ Upstream commit 05f90bf3d5df40e1a705527520e5fd56b2b6f09e ] efx_probe_filters() has not been called yet when EF100 calls into efx_mcdi_filter_table_probe(), for which it wants to take the filter_sem. Fixes: a9dc3d5612ce ("sfc_ef100: RX filter table management and related gubbins") Signed-off-by: Edward Cree Link: https://lore.kernel.org/r/24fad43e-887d-051e-25e3-506f23f63abf@solarflare.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 02259e5c2b82db718bbd4ec2baba92b7344d5920 Author: Eelco Chaudron Date: Sat Oct 17 20:24:51 2020 +0200 net: openvswitch: fix to make sure flow_lookup() is not preempted [ Upstream commit f981fc3d515a588c389242b7e3a71487b40571a5 ] The flow_lookup() function uses per CPU variables, which must be called with BH disabled. However, this is fine in the general NAPI use case where the local BH is disabled. But, it's also called from the netlink context. The below patch makes sure that even in the netlink path, the BH is disabled. In addition, u64_stats_update_begin() requires a lock to ensure one writer which is not ensured here. Making it per-CPU and disabling NAPI (softirq) ensures that there is always only one writer. Fixes: eac87c413bf9 ("net: openvswitch: reorder masks array based on usage") Reported-by: Juri Lelli Signed-off-by: Eelco Chaudron Link: https://lore.kernel.org/r/160295903253.7789.826736662555102345.stgit@ebuild Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d8d6c3c3c7b39583a3c906c90fbfc3959ac5c354 Author: Geert Uytterhoeven Date: Mon Oct 19 13:32:40 2020 +0200 mptcp: MPTCP_KUNIT_TESTS should depend on MPTCP instead of selecting it [ Upstream commit b142083b585c2c03af24cca4d274f797796a4064 ] MPTCP_KUNIT_TESTS selects MPTCP, thus enabling an optional feature the user may not want to enable. Fix this by making the test depend on MPTCP instead. Fixes: a00a582203dbc43e ("mptcp: move crypto test to KUNIT") Signed-off-by: Geert Uytterhoeven Reviewed-by: Matthieu Baerts Link: https://lore.kernel.org/r/20201019113240.11516-1-geert@linux-m68k.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 08762a572262b87ec424e7aa1af8db6849ba179a Author: Jakub Kicinski Date: Fri Oct 16 16:20:06 2020 -0700 ixgbe: fix probing of multi-port devices with one MDIO [ Upstream commit bd7f14df9492e7d3772812a215fca66e6737e598 ] Ian reports that after upgrade from v5.8.14 to v5.9 only one of his 4 ixgbe netdevs appear in the system. Quoting the comment on ixgbe_x550em_a_has_mii(): * Returns true if hw points to lowest numbered PCI B:D.F x550_em_a device in * the SoC. There are up to 4 MACs sharing a single MDIO bus on the x550em_a, * but we only want to register one MDIO bus. This matches the symptoms, since the return value from ixgbe_mii_bus_init() is no longer ignored we need to handle the higher ports of x550em without an error. Fixes: 09ef193fef7e ("net: ethernet: ixgbe: check the return value of ixgbe_mii_bus_init()") Reported-by: Ian Kumlien Tested-by: Ian Kumlien Acked-by: Jesse Brandeburg Link: https://lore.kernel.org/r/20201016232006.3352947-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a9cee4ed5a6abb04d45ae6ba0d65448671671727 Author: Guillaume Nault Date: Tue Oct 20 17:34:31 2020 +0200 net/sched: act_gate: Unlock ->tcfa_lock in tc_setup_flow_action() [ Upstream commit b130762161374b1ef31549bef8ebd4abeb998d94 ] We need to jump to the "err_out_locked" label when tcf_gate_get_entries() fails. Otherwise, tc_setup_flow_action() exits with ->tcfa_lock still held. Fixes: d29bdd69ecdd ("net: schedule: add action gate offloading") Signed-off-by: Guillaume Nault Acked-by: Cong Wang Link: https://lore.kernel.org/r/12f60e385584c52c22863701c0185e40ab08a7a7.1603207948.git.gnault@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 77827f3d7d4de6d45f345da2b862038ad67eca6a Author: Bartosz Golaszewski Date: Tue Oct 20 09:35:15 2020 +0200 net: ethernet: mtk-star-emac: select REGMAP_MMIO [ Upstream commit 5403caf21648d739bf2b1266c33e34384c313379 ] The driver depends on mmio regmap API but doesn't select the appropriate Kconfig option. This fixes it. Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver") Signed-off-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20201020073515.22769-1-brgl@bgdev.pl Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c485024eeac597906f0044ac17dd709239b0f22a Author: Neal Cardwell Date: Thu Oct 22 10:33:31 2020 -0400 tcp: fix to update snd_wl1 in bulk receiver fast path [ Upstream commit 18ded910b589839e38a51623a179837ab4cc3789 ] In the header prediction fast path for a bulk data receiver, if no data is newly acknowledged then we do not call tcp_ack() and do not call tcp_ack_update_window(). This means that a bulk receiver that receives large amounts of data can have the incoming sequence numbers wrap, so that the check in tcp_may_update_window fails: after(ack_seq, tp->snd_wl1) If the incoming receive windows are zero in this state, and then the connection that was a bulk data receiver later wants to send data, that connection can find itself persistently rejecting the window updates in incoming ACKs. This means the connection can persistently fail to discover that the receive window has opened, which in turn means that the connection is unable to send anything, and the connection's sending process can get permanently "stuck". The fix is to update snd_wl1 in the header prediction fast path for a bulk data receiver, so that it keeps up and does not see wrapping problems. This fix is based on a very nice and thorough analysis and diagnosis by Apollon Oikonomopoulos (see link below). This is a stable candidate but there is no Fixes tag here since the bug predates current git history. Just for fun: looks like the bug dates back to when header prediction was added in Linux v2.1.8 in Nov 1996. In that version tcp_rcv_established() was added, and the code only updates snd_wl1 in tcp_ack(), and in the new "Bulk data transfer: receiver" code path it does not call tcp_ack(). This fix seems to apply cleanly at least as far back as v3.2. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Neal Cardwell Reported-by: Apollon Oikonomopoulos Tested-by: Apollon Oikonomopoulos Link: https://www.spinics.net/lists/netdev/msg692430.html Acked-by: Soheil Hassas Yeganeh Acked-by: Yuchung Cheng Signed-off-by: Eric Dumazet Link: https://lore.kernel.org/r/20201022143331.1887495-1-ncardwell.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 139e332b1e2f90abd684f54e758b9364427dd489 Author: Po-Hsu Lin Date: Mon Oct 19 11:09:28 2020 +0800 selftests: rtnetlink: load fou module for kci_test_encap_fou() test [ Upstream commit 26ebd6fed9bb3aa480c7c0f147ac0e7b11000f65 ] The kci_test_encap_fou() test from kci_test_encap() in rtnetlink.sh needs the fou module to work. Otherwise it will fail with: $ ip netns exec "$testns" ip fou add port 7777 ipproto 47 RTNETLINK answers: No such file or directory Error talking to the kernel Add the CONFIG_NET_FOU into the config file as well. Which needs at least to be set as a loadable module. Fixes: 6227efc1a20b ("selftests: rtnetlink.sh: add vxlan and fou test cases") Signed-off-by: Po-Hsu Lin Link: https://lore.kernel.org/r/20201019030928.9859-1-po-hsu.lin@canonical.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cc8cb560ae5f33f0bb2fe7a589f86c6567f3260f Author: Ido Schimmel Date: Thu Oct 15 11:45:25 2020 +0300 selftests: forwarding: Add missing 'rp_filter' configuration [ Upstream commit 71a0e29e99405d89b695882d52eec60844173697 ] When 'rp_filter' is configured in strict mode (1) the tests fail because packets received from the macvlan netdevs would not be forwarded through them on the reverse path. Fix this by disabling the 'rp_filter', meaning no source validation is performed. Fixes: 1538812e0880 ("selftests: forwarding: Add a test for VXLAN asymmetric routing") Fixes: 438a4f5665b2 ("selftests: forwarding: Add a test for VXLAN symmetric routing") Signed-off-by: Ido Schimmel Reported-by: Hangbin Liu Tested-by: Hangbin Liu Link: https://lore.kernel.org/r/20201015084525.135121-1-idosch@idosch.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9be585f7d4b8da0d2b570bd39077bb6d75e1d6c7 Author: Heiner Kallweit Date: Sun Oct 18 18:38:59 2020 +0200 r8169: fix operation under forced interrupt threading [ Upstream commit 424a646e072a887aa87283b53aa6f8b19c2a7bef ] For several network drivers it was reported that using __napi_schedule_irqoff() is unsafe with forced threading. One way to fix this is switching back to __napi_schedule, but then we lose the benefit of the irqoff version in general. As stated by Eric it doesn't make sense to make the minimal hard irq handlers in drivers using NAPI a thread. Therefore ensure that the hard irq handler is never thread-ified. Fixes: 9a899a35b0d6 ("r8169: switch to napi_schedule_irqoff") Link: https://lkml.org/lkml/2020/10/18/19 Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/4d3ef84a-c812-5072-918a-22a6f6468310@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d8086039b5f5c828a52d9d4a3460e0f412aa5edb Author: Defang Bo Date: Mon Oct 19 19:38:58 2020 +0800 nfc: Ensure presence of NFC_ATTR_FIRMWARE_NAME attribute in nfc_genl_fw_download() [ Upstream commit 280e3ebdafb863b3cb50d5842f056267e15bf40c ] Check that the NFC_ATTR_FIRMWARE_NAME attributes are provided by the netlink client prior to accessing them.This prevents potential unhandled NULL pointer dereference exceptions which can be triggered by malicious user-mode programs, if they omit one or both of these attributes. Similar to commit a0323b979f81 ("nfc: Ensure presence of required attributes in the activate_target handler"). Fixes: 9674da8759df ("NFC: Add firmware upload netlink command") Signed-off-by: Defang Bo Link: https://lore.kernel.org/r/1603107538-4744-1-git-send-email-bodefang@126.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1f6c2cce9a298e4161619c4c6a65d6d953c9ad84 Author: Ido Schimmel Date: Fri Oct 16 20:29:14 2020 +0300 nexthop: Fix performance regression in nexthop deletion [ Upstream commit df6afe2f7c19349de2ee560dc62ea4d9ad3ff889 ] While insertion of 16k nexthops all using the same netdev ('dummy10') takes less than a second, deletion takes about 130 seconds: # time -p ip -b nexthop.batch real 0.29 user 0.01 sys 0.15 # time -p ip link set dev dummy10 down real 131.03 user 0.06 sys 0.52 This is because of repeated calls to synchronize_rcu() whenever a nexthop is removed from a nexthop group: # /usr/share/bcc/tools/offcputime -p `pgrep -nx ip` -K ... b'finish_task_switch' b'schedule' b'schedule_timeout' b'wait_for_completion' b'__wait_rcu_gp' b'synchronize_rcu.part.0' b'synchronize_rcu' b'__remove_nexthop' b'remove_nexthop' b'nexthop_flush_dev' b'nh_netdev_event' b'raw_notifier_call_chain' b'call_netdevice_notifiers_info' b'__dev_notify_flags' b'dev_change_flags' b'do_setlink' b'__rtnl_newlink' b'rtnl_newlink' b'rtnetlink_rcv_msg' b'netlink_rcv_skb' b'rtnetlink_rcv' b'netlink_unicast' b'netlink_sendmsg' b'____sys_sendmsg' b'___sys_sendmsg' b'__sys_sendmsg' b'__x64_sys_sendmsg' b'do_syscall_64' b'entry_SYSCALL_64_after_hwframe' - ip (277) 126554955 Since nexthops are always deleted under RTNL, synchronize_net() can be used instead. It will call synchronize_rcu_expedited() which only blocks for several microseconds as opposed to multiple milliseconds like synchronize_rcu(). With this patch deletion of 16k nexthops takes less than a second: # time -p ip link set dev dummy10 down real 0.12 user 0.00 sys 0.04 Tested with fib_nexthops.sh which includes torture tests that prompted the initial change: # ./fib_nexthops.sh ... Tests passed: 134 Tests failed: 0 Fixes: 90f33bffa382 ("nexthops: don't modify published nexthop groups") Signed-off-by: Ido Schimmel Reviewed-by: Jesse Brandeburg Reviewed-by: David Ahern Acked-by: Nikolay Aleksandrov Link: https://lore.kernel.org/r/20201016172914.643282-1-idosch@idosch.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 42cef4d686bedd5dacd591104b76c3bbec12cbc8 Author: Ard Biesheuvel Date: Sun Oct 18 18:36:25 2020 +0200 netsec: ignore 'phy-mode' device property on ACPI systems [ Upstream commit acd7aaf51b20263a7e62d2a26569988c63bdd3d8 ] Since commit bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the Realtek PHY driver will override any TX/RX delay set by hardware straps if the phy-mode device property does not match. This is causing problems on SynQuacer based platforms (the only SoC that incorporates the netsec hardware), since many were built with this Realtek PHY, and shipped with firmware that defines the phy-mode as 'rgmii', even though the PHY is configured for TX and RX delay using pull-ups. >From the driver's perspective, we should not make any assumptions in the general case that the PHY hardware does not require any initial configuration. However, the situation is slightly different for ACPI boot, since it implies rich firmware with AML abstractions to handle hardware details that are not exposed to the OS. So in the ACPI case, it is reasonable to assume that the PHY comes up in the right mode, regardless of whether the mode is set by straps, by boot time firmware or by AML executed by the ACPI interpreter. So let's ignore the 'phy-mode' device property when probing the netsec driver in ACPI mode, and hardcode the mode to PHY_INTERFACE_MODE_NA, which should work with any PHY provided that it is configured by the time the driver attaches to it. While at it, document that omitting the mode is permitted for DT probing as well, by setting the phy-mode DT property to the empty string. Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Ard Biesheuvel Reviewed-by: Ilias Apalodimas Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20201018163625.2392-1-ardb@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7ab3d9170a76c02e1f7f96d3b8061c886c5498b5 Author: Davide Caratti Date: Wed Oct 21 00:02:40 2020 +0200 net/sched: act_tunnel_key: fix OOB write in case of IPv6 ERSPAN tunnels [ Upstream commit a7a12b5a0f950bc6b9f7153390634ea798738db9 ] the following command # tc action add action tunnel_key \ > set src_ip 2001:db8::1 dst_ip 2001:db8::2 id 10 erspan_opts 1:6789:0:0 generates the following splat: BUG: KASAN: slab-out-of-bounds in tunnel_key_copy_opts+0xcc9/0x1010 [act_tunnel_key] Write of size 4 at addr ffff88813f5f1cc8 by task tc/873 CPU: 2 PID: 873 Comm: tc Not tainted 5.9.0+ #282 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x99/0xcb print_address_description.constprop.7+0x1e/0x230 kasan_report.cold.13+0x37/0x7c tunnel_key_copy_opts+0xcc9/0x1010 [act_tunnel_key] tunnel_key_init+0x160c/0x1f40 [act_tunnel_key] tcf_action_init_1+0x5b5/0x850 tcf_action_init+0x15d/0x370 tcf_action_add+0xd9/0x2f0 tc_ctl_action+0x29b/0x3a0 rtnetlink_rcv_msg+0x341/0x8d0 netlink_rcv_skb+0x120/0x380 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f872a96b338 Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 RSP: 002b:00007ffffe367518 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000005f8f5aed RCX: 00007f872a96b338 RDX: 0000000000000000 RSI: 00007ffffe367580 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000001c R10: 000000000000000b R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000686760 R14: 0000000000000601 R15: 0000000000000000 Allocated by task 873: kasan_save_stack+0x19/0x40 __kasan_kmalloc.constprop.7+0xc1/0xd0 __kmalloc+0x151/0x310 metadata_dst_alloc+0x20/0x40 tunnel_key_init+0xfff/0x1f40 [act_tunnel_key] tcf_action_init_1+0x5b5/0x850 tcf_action_init+0x15d/0x370 tcf_action_add+0xd9/0x2f0 tc_ctl_action+0x29b/0x3a0 rtnetlink_rcv_msg+0x341/0x8d0 netlink_rcv_skb+0x120/0x380 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff88813f5f1c00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 200 bytes inside of 256-byte region [ffff88813f5f1c00, ffff88813f5f1d00) The buggy address belongs to the page: page:0000000011b48a19 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x13f5f0 head:0000000011b48a19 order:1 compound_mapcount:0 flags: 0x17ffffc0010200(slab|head) raw: 0017ffffc0010200 0000000000000000 0000000d00000001 ffff888107c43400 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88813f5f1b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88813f5f1c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88813f5f1c80: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc ^ ffff88813f5f1d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88813f5f1d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc using IPv6 tunnels, act_tunnel_key allocates a fixed amount of memory for the tunnel metadata, but then it expects additional bytes to store tunnel specific metadata with tunnel_key_copy_opts(). Fix the arguments of __ipv6_tun_set_dst(), so that 'md_size' contains the size previously computed by tunnel_key_get_opts_len(), like it's done for IPv4 tunnels. Fixes: 0ed5269f9e41 ("net/sched: add tunnel option support to act_tunnel_key") Reported-by: Shuang Li Signed-off-by: Davide Caratti Acked-by: Cong Wang Link: https://lore.kernel.org/r/36ebe969f6d13ff59912d6464a4356fe6f103766.1603231100.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7570e3bc3b0c5fe60058e64ea7e786f9ae25167d Author: Roi Dayan Date: Mon Oct 19 12:02:44 2020 +0300 net/sched: act_ct: Fix adding udp port mangle operation [ Upstream commit 47b5d2a107396ab05e83a4dfbd30b563ecbc83af ] Need to use the udp header type and not tcp. Fixes: 9c26ba9b1f45 ("net/sched: act_ct: Instantiate flow table entry actions") Signed-off-by: Roi Dayan Reviewed-by: Paul Blakey Link: https://lore.kernel.org/r/20201019090244.3015186-1-roid@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9270742be088354cae1289b07cafb86eb4adab0e Author: Ke Li Date: Thu Oct 22 02:41:46 2020 -0400 net: Properly typecast int values to set sk_max_pacing_rate [ Upstream commit 700465fd338fe5df08a1b2e27fa16981f562547f ] In setsockopt(SO_MAX_PACING_RATE) on 64bit systems, sk_max_pacing_rate, after extended from 'u32' to 'unsigned long', takes unintentionally hiked value whenever assigned from an 'int' value with MSB=1, due to binary sign extension in promoting s32 to u64, e.g. 0x80000000 becomes 0xFFFFFFFF80000000. Thus inflated sk_max_pacing_rate causes subsequent getsockopt to return ~0U unexpectedly. It may also result in increased pacing rate. Fix by explicitly casting the 'int' value to 'unsigned int' before assigning it to sk_max_pacing_rate, for zero extension to happen. Fixes: 76a9ebe811fb ("net: extend sk_pacing_rate to unsigned long") Signed-off-by: Ji Li Signed-off-by: Ke Li Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20201022064146.79873-1-keli@akamai.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 57d0fdccbfc1ed9e40c281b1e82f0eb67c5d99ae Author: Xie He Date: Mon Oct 19 23:34:20 2020 -0700 net: hdlc_raw_eth: Clear the IFF_TX_SKB_SHARING flag after calling ether_setup [ Upstream commit 5fce1e43e2d5bf2f7e3224d7b99b1c65ab2c26e2 ] This driver calls ether_setup to set up the network device. The ether_setup function would add the IFF_TX_SKB_SHARING flag to the device. This flag indicates that it is safe to transmit shared skbs to the device. However, this is not true. This driver may pad the frame (in eth_tx) before transmission, so the skb may be modified. Fixes: 550fd08c2ceb ("net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared") Cc: Neil Horman Cc: Krzysztof Halasa Signed-off-by: Xie He Link: https://lore.kernel.org/r/20201020063420.187497-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e1a25b825e31e82fd048b301155e8799a656d0ed Author: Xie He Date: Mon Oct 19 18:31:52 2020 -0700 net: hdlc: In hdlc_rcv, check to make sure dev is an HDLC device [ Upstream commit 01c4ceae0a38a0bdbfea6896f41efcd985a9c064 ] The hdlc_rcv function is used as hdlc_packet_type.func to process any skb received in the kernel with skb->protocol == htons(ETH_P_HDLC). The purpose of this function is to provide second-stage processing for skbs not assigned a "real" L3 skb->protocol value in the first stage. This function assumes the device from which the skb is received is an HDLC device (a device created by this module). It assumes that netdev_priv(dev) returns a pointer to "struct hdlc_device". However, it is possible that some driver in the kernel (not necessarily in our control) submits a received skb with skb->protocol == htons(ETH_P_HDLC), from a non-HDLC device. In this case, the skb would still be received by hdlc_rcv. This will cause problems. hdlc_rcv should be able to recognize and drop invalid skbs. It should first make sure "dev" is actually an HDLC device, before starting its processing. This patch adds this check to hdlc_rcv. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: Krzysztof Halasa Signed-off-by: Xie He Link: https://lore.kernel.org/r/20201020013152.89259-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bb2b3c6f9fa7fbd0e834ee32336fc9083d7dc1b6 Author: Dylan Hung Date: Wed Oct 14 14:06:32 2020 +0800 net: ftgmac100: Fix Aspeed ast2600 TX hang issue [ Upstream commit 137d23cea1c044b2d4853ac71bc68126b25fdbb2 ] The new HW arbitration feature on Aspeed ast2600 will cause MAC TX to hang when handling scatter-gather DMA. Disable the problematic feature by setting MAC register 0x58 bit28 and bit27. Fixes: 39bfab8844a0 ("net: ftgmac100: Add support for DT phy-handle property") Signed-off-by: Dylan Hung Reviewed-by: Joel Stanley Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cd3f491b6b700cc1b65b33063b2d19c908207e35 Author: Geliang Tang Date: Mon Oct 19 18:23:15 2020 +0800 mptcp: initialize mptcp_options_received's ahmac [ Upstream commit fe2d9b1a0e7805384770ec0ddd34c9f1e9fe6fa8 ] Initialize mptcp_options_received's ahmac to zero, otherwise it will be a random number when receiving ADD_ADDR suboption with echo-flag=1. Fixes: 3df523ab582c5 ("mptcp: Add ADD_ADDR handling") Signed-off-by: Geliang Tang Reviewed-by: Matthieu Baerts Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7237c55005ed638b7c89703079944dbd80dee7fe Author: Eric Dumazet Date: Thu Oct 15 11:42:00 2020 -0700 icmp: randomize the global rate limiter [ Upstream commit b38e7819cae946e2edf869e604af1e65a5d241c5 ] Keyu Man reported that the ICMP rate limiter could be used by attackers to get useful signal. Details will be provided in an upcoming academic publication. Our solution is to add some noise, so that the attackers no longer can get help from the predictable token bucket limiter. Fixes: 4cdf507d5452 ("icmp: add a global rate limitation") Signed-off-by: Eric Dumazet Reported-by: Keyu Man Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9913d9ffe7bb0601dd7f083507986cdb8246b727 Author: Lijun Pan Date: Tue Oct 20 17:39:19 2020 -0500 ibmvnic: save changed mac address to adapter->mac_addr [ Upstream commit d9b0e599b2b892422f1cbc5d2658049b895b2b58 ] After mac address change request completes successfully, the new mac address need to be saved to adapter->mac_addr as well as netdev->dev_addr. Otherwise, adapter->mac_addr still holds old data. Fixes: 62740e97881c ("net/ibmvnic: Update MAC address settings after adapter reset") Signed-off-by: Lijun Pan Link: https://lore.kernel.org/r/20201020223919.46106-1-ljp@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 54106218f14bc0da813a84dfb21b686c4d1408cd Author: Vinay Kumar Yadav Date: Mon Oct 19 17:20:25 2020 +0530 chelsio/chtls: fix writing freed memory [ Upstream commit da1a039bcf293e4699d413c9f65d975da2d7c0bd ] When chtls_sock *csk is freed, same memory can be allocated to different csk in chtls_sock_create(). csk->cdev = NULL; statement might ends up modifying wrong csk, eventually causing kernel panic. removing (csk->cdev = NULL) statement as it is not required. Fixes: 3a0a97838923 ("crypto/chtls: Fix chtls crash in connection cleanup") Signed-off-by: Vinay Kumar Yadav Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 91b307232e316abc47dadb35384547f2bd4103a3 Author: Vinay Kumar Yadav Date: Mon Oct 19 17:20:24 2020 +0530 chelsio/chtls: correct function return and return type [ Upstream commit 8580a61aede28d441e1c80588803411ee86aa299 ] csk_mem_free() should return true if send buffer is available, false otherwise. Fixes: 3b8305f5c844 ("crypto: chtls - wait for memory sendmsg, sendpage") Signed-off-by: Vinay Kumar Yadav Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c5a6bb67675a08ded60471e4ceef59b9a6642f3a Author: Vinay Kumar Yadav Date: Mon Oct 19 17:20:23 2020 +0530 chelsio/chtls: Fix panic when listen on multiadapter [ Upstream commit 9819f22c410b4bf6589d3126e8bc3952db507cbf ] Add the logic to compare net_device returned by ip_dev_find() with the net_device list in cdev->ports[] array and return net_device if matched else NULL. Fixes: 6abde0b24122 ("crypto/chtls: IPv6 support for inline TLS") Signed-off-by: Venkatesh Ellapu Signed-off-by: Vinay Kumar Yadav Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 788faa0250f3ed17689dcaf8df46d9693535f35a Author: Vinay Kumar Yadav Date: Mon Oct 19 17:20:22 2020 +0530 chelsio/chtls: fix panic when server is on ipv6 [ Upstream commit 86cdf9ca4409d997a391103e480b3f77b7ccc19b ] Netdev is filled in egress_dev when connection is established, If connection is closed before establishment, then egress_dev is NULL, Fix it using ip_dev_find() rather then extracting from egress_dev. Fixes: 6abde0b24122 ("crypto/chtls: IPv6 support for inline TLS") Signed-off-by: Venkatesh Ellapu Signed-off-by: Vinay Kumar Yadav Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 99b5b5fbf805f61f780284dd3ccfbd346d109653 Author: Vinay Kumar Yadav Date: Mon Oct 19 17:20:21 2020 +0530 chelsio/chtls: correct netdevice for vlan interface [ Upstream commit 81519d1f7df7ed1bd5b1397540c8884438f57ae2 ] Check if netdevice is a vlan interface and find real vlan netdevice. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Venkatesh Ellapu Signed-off-by: Vinay Kumar Yadav Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8227ff98c87af98dfec729eedc555318f7fa9ca1 Author: Vinay Kumar Yadav Date: Mon Oct 19 17:20:20 2020 +0530 chelsio/chtls: fix socket lock [ Upstream commit 0fb5f0160a36d7acaa8e84ce873af99f94b60484 ] In chtls_sendpage() socket lock is released but not acquired, fix it by taking lock. Fixes: 36bedb3f2e5b ("crypto: chtls - Inline TLS record Tx") Signed-off-by: Vinay Kumar Yadav Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 95ac3301ec6256dcccdb5b0a60fd2f197af563d6 Author: Hoang Huu Le Date: Fri Oct 16 09:31:19 2020 +0700 tipc: fix incorrect setting window for bcast link [ Upstream commit ec78e31852c9bb7d96b6557468fecb6f6f3b28f3 ] In commit 16ad3f4022bb ("tipc: introduce variable window congestion control"), we applied the algorithm to select window size from minimum window to the configured maximum window for unicast link, and, besides we chose to keep the window size for broadcast link unchanged and equal (i.e fix window 50) However, when setting maximum window variable via command, the window variable was re-initialized to unexpect value (i.e 32). We fix this by updating the fix window for broadcast as we stated. Fixes: 16ad3f4022bb ("tipc: introduce variable window congestion control") Acked-by: Jon Maloy Signed-off-by: Hoang Huu Le Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 20770b1e88f219a4782e1513dd23185a23f788e5 Author: Hoang Huu Le Date: Fri Oct 16 09:31:18 2020 +0700 tipc: re-configure queue limit for broadcast link [ Upstream commit 75cee397ae6f1020fbb75db90aa22a51bc3318ac ] The queue limit of the broadcast link is being calculated base on initial MTU. However, when MTU value changed (e.g manual changing MTU on NIC device, MTU negotiation etc.,) we do not re-calculate queue limit. This gives throughput does not reflect with the change. So fix it by calling the function to re-calculate queue limit of the broadcast link. Acked-by: Jon Maloy Signed-off-by: Hoang Huu Le Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f48d8d15ced4774d957dfaeda9744f2c587d615e Author: Kai Vehmanen Date: Tue Oct 13 18:26:28 2020 +0300 ALSA: hda/hdmi: fix incorrect locking in hdmi_pcm_close commit ce1558c285f9ad04c03b46833a028230771cc0a7 upstream. A race exists between closing a PCM and update of ELD data. In hdmi_pcm_close(), hinfo->nid value is modified without taking spec->pcm_lock. If this happens concurrently while processing an ELD update in hdmi_pcm_setup_pin(), converter assignment may be done incorrectly. This bug was found by hitting a WARN_ON in snd_hda_spdif_ctls_assign() in a HDMI receiver connection stress test: [2739.684569] WARNING: CPU: 5 PID: 2090 at sound/pci/hda/patch_hdmi.c:1898 check_non_pcm_per_cvt+0x41/0x50 [snd_hda_codec_hdmi] ... [2739.684707] Call Trace: [2739.684720] update_eld+0x121/0x5a0 [snd_hda_codec_hdmi] [2739.684736] hdmi_present_sense+0x21e/0x3b0 [snd_hda_codec_hdmi] [2739.684750] check_presence_and_report+0x81/0xd0 [snd_hda_codec_hdmi] [2739.684842] intel_audio_codec_enable+0x122/0x190 [i915] Fixes: 42b2987079ec ("ALSA: hda - hdmi playback without monitor in dynamic pcm bind mode") Signed-off-by: Kai Vehmanen Cc: Link: https://lore.kernel.org/r/20201013152628.920764-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6aafca025b27628e518e000a9943b7b0e4ba694a Author: Kai Vehmanen Date: Mon Oct 12 13:27:04 2020 +0300 ALSA: hda: fix jack detection with Realtek codecs when in D3 commit a6e7d0a4bdb02a7a3ffe0b44aaa8842b7efdd056 upstream. In case HDA controller becomes active, but codec is runtime suspended, jack detection is not successful and no interrupt is raised. This has been observed with multiple Realtek codecs and HDA controllers from different vendors. Bug does not occur if both codec and controller are active, or both are in suspend. Bug can be easily hit on desktop systems with no built-in speaker. The problem can be fixed by powering up the codec once after every controller runtime resume. Even if codec goes back to suspend later, the jack detection will continue to work. Add a flag to 'hda_codec' to describe codecs that require this flow from the controller driver. Modify __azx_runtime_resume() to use pm_request_resume() to make the intent clearer. Mark all Realtek codecs with the new forced_resume flag. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209379 Cc: Kailang Yang Co-developed-by: Kai-Heng Feng Signed-off-by: Kai-Heng Feng Signed-off-by: Kai Vehmanen Cc: Link: https://lore.kernel.org/r/20201012102704.794423-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit da0ca343179eac9950315910a67465c4ce75061d Author: Dan Carpenter Date: Wed Oct 7 10:49:28 2020 +0300 ALSA: bebob: potential info leak in hwdep_read() commit b41c15f4e1c1f1657da15c482fa837c1b7384452 upstream. The "count" variable needs to be capped on every path so that we don't copy too much information to the user. Fixes: 618eabeae711 ("ALSA: bebob: Add hwdep interface") Signed-off-by: Dan Carpenter Acked-by: Takashi Sakamoto Cc: Link: https://lore.kernel.org/r/20201007074928.GA2529578@mwanda Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2144f0b90aeb2ead33d590f2e45f9be185b93009 Author: Todd Kjos Date: Fri Oct 9 16:24:55 2020 -0700 binder: fix UAF when releasing todo list commit f3277cbfba763cd2826396521b9296de67cf1bbc upstream. When releasing a thread todo list when tearing down a binder_proc, the following race was possible which could result in a use-after-free: 1. Thread 1: enter binder_release_work from binder_thread_release 2. Thread 2: binder_update_ref_for_handle() -> binder_dec_node_ilocked() 3. Thread 2: dec nodeA --> 0 (will free node) 4. Thread 1: ACQ inner_proc_lock 5. Thread 2: block on inner_proc_lock 6. Thread 1: dequeue work (BINDER_WORK_NODE, part of nodeA) 7. Thread 1: REL inner_proc_lock 8. Thread 2: ACQ inner_proc_lock 9. Thread 2: todo list cleanup, but work was already dequeued 10. Thread 2: free node 11. Thread 2: REL inner_proc_lock 12. Thread 1: deref w->type (UAF) The problem was that for a BINDER_WORK_NODE, the binder_work element must not be accessed after releasing the inner_proc_lock while processing the todo list elements since another thread might be handling a deref on the node containing the binder_work element leading to the node being freed. Signed-off-by: Todd Kjos Link: https://lore.kernel.org/r/20201009232455.4054810-1-tkjos@google.com Cc: # 4.14, 4.19, 5.4, 5.8 Signed-off-by: Greg Kroah-Hartman commit d7c329942fe75be4d5e33530127d845cf5d8f32d Author: Marc Kleine-Budde Date: Thu Oct 8 23:23:10 2020 +0200 net: j1939: j1939_session_fresh_new(): fix missing initialization of skbcnt [ Upstream commit 13ba4c434422837d7c8c163f9c8d854e67bf3c99 ] This patch add the initialization of skbcnt, similar to: e009f95b1543 can: j1935: j1939_tp_tx_dat_new(): fix missing initialization of skbcnt Let's play save and initialize this skbcnt as well. Suggested-by: Jakub Kicinski Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 52d96d227355b05d93c3e98979b507af77eb55e5 Author: Cong Wang Date: Wed Oct 7 23:18:21 2020 -0700 can: j1935: j1939_tp_tx_dat_new(): fix missing initialization of skbcnt [ Upstream commit e009f95b1543e26606dca2f7e6e9f0f9174538e5 ] This fixes an uninit-value warning: BUG: KMSAN: uninit-value in can_receive+0x26b/0x630 net/can/af_can.c:650 Reported-and-tested-by: syzbot+3f3837e61a48d32b495f@syzkaller.appspotmail.com Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Cc: Robin van der Gracht Cc: Oleksij Rempel Cc: Pengutronix Kernel Team Cc: Oliver Hartkopp Cc: Marc Kleine-Budde Signed-off-by: Cong Wang Link: https://lore.kernel.org/r/20201008061821.24663-1-xiyou.wangcong@gmail.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit e0e835313cbb6cf850aed2937af5c5e5307f39ee Author: Lucas Stach Date: Tue Aug 11 10:15:44 2020 +0200 can: m_can_platform: don't call m_can_class_suspend in runtime suspend [ Upstream commit 81f1f5ae8b3cbd54fdd994c9e9aacdb7b414a802 ] 0704c5743694 can: m_can_platform: remove unnecessary m_can_class_resume() call removed the m_can_class_resume() call in the runtime resume path to get rid of a infinite recursion, so the runtime resume now only handles the device clocks. Unfortunately it did not remove the complementary m_can_class_suspend() call in the runtime suspend function, so those paths are now unbalanced, which causes the pinctrl state to get stuck on the "sleep" state, which breaks all CAN functionality on SoCs where this state is defined. Remove the m_can_class_suspend() call to fix this. Fixes: 0704c5743694 can: m_can_platform: remove unnecessary m_can_class_resume() call Signed-off-by: Lucas Stach Link: https://lore.kernel.org/r/20200811081545.19921-1-l.stach@pengutronix.de Acked-by: Dan Murphy Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 90036c9b3c8489a80630be71a28ab8eeb661c50d Author: Christian Eggers Date: Mon Oct 12 11:35:42 2020 +0200 socket: don't clear SOCK_TSTAMP_NEW when SO_TIMESTAMPNS is disabled [ Upstream commit 4e3bbb33e6f36e4b05be1b1b9b02e3dd5aaa3e69 ] SOCK_TSTAMP_NEW (timespec64 instead of timespec) is also used for hardware time stamps (configured via SO_TIMESTAMPING_NEW). User space (ptp4l) first configures hardware time stamping via SO_TIMESTAMPING_NEW which sets SOCK_TSTAMP_NEW. In the next step, ptp4l disables SO_TIMESTAMPNS(_NEW) (software time stamps), but this must not switch hardware time stamps back to "32 bit mode". This problem happens on 32 bit platforms were the libc has already switched to struct timespec64 (from SO_TIMExxx_OLD to SO_TIMExxx_NEW socket options). ptp4l complains with "missing timestamp on transmitted peer delay request" because the wrong format is received (and discarded). Fixes: 887feae36aee ("socket: Add SO_TIMESTAMP[NS]_NEW") Fixes: 783da70e8396 ("net: add sock_enable_timestamps") Signed-off-by: Christian Eggers Acked-by: Willem de Bruijn Acked-by: Deepa Dinamani Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 06bf6238fdb56b22e676cc2afe224ac9d13606d6 Author: Christian Eggers Date: Mon Oct 12 11:35:41 2020 +0200 socket: fix option SO_TIMESTAMPING_NEW [ Upstream commit 59e611a566e7cd48cf54b6777a11fe3f9c2f9db5 ] The comparison of optname with SO_TIMESTAMPING_NEW is wrong way around, so SOCK_TSTAMP_NEW will first be set and than reset again. Additionally move it out of the test for SOF_TIMESTAMPING_RX_SOFTWARE as this seems unrelated. This problem happens on 32 bit platforms were the libc has already switched to struct timespec64 (from SO_TIMExxx_OLD to SO_TIMExxx_NEW socket options). ptp4l complains with "missing timestamp on transmitted peer delay request" because the wrong format is received (and discarded). Fixes: 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW") Signed-off-by: Christian Eggers Reviewed-by: Willem de Bruijn Reviewed-by: Deepa Dinamani Acked-by: Willem de Bruijn Acked-by: Deepa Dinamani Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3a4e7ac9fd56d8e34a274a9dad3dc67b564278f4 Author: Cong Wang Date: Wed Oct 7 21:12:50 2020 -0700 tipc: fix the skb_unshare() in tipc_buf_append() [ Upstream commit ed42989eab57d619667d7e87dfbd8fe207db54fe ] skb_unshare() drops a reference count on the old skb unconditionally, so in the failure case, we end up freeing the skb twice here. And because the skb is allocated in fclone and cloned by caller tipc_msg_reassemble(), the consequence is actually freeing the original skb too, thus triggered the UAF by syzbot. Fix this by replacing this skb_unshare() with skb_cloned()+skb_copy(). Fixes: ff48b6222e65 ("tipc: use skb_unshare() instead in tipc_buf_append()") Reported-and-tested-by: syzbot+e96a7ba46281824cc46a@syzkaller.appspotmail.com Cc: Jon Maloy Cc: Ying Xue Signed-off-by: Cong Wang Reviewed-by: Xin Long Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c99293ddd73fb19de2640e9d04dbd7417690102b Author: Hoang Huu Le Date: Thu Oct 8 14:31:56 2020 +0700 tipc: fix NULL pointer dereference in tipc_named_rcv [ Upstream commit 7b50ee3dad2581dc022b4e32e55964d4fcdccf20 ] In the function node_lost_contact(), we call __skb_queue_purge() without grabbing the list->lock. This can cause to a race-condition why processing the list 'namedq' in calling path tipc_named_rcv()->tipc_named_dequeue(). [] BUG: kernel NULL pointer dereference, address: 0000000000000000 [] #PF: supervisor read access in kernel mode [] #PF: error_code(0x0000) - not-present page [] PGD 7ca63067 P4D 7ca63067 PUD 6c553067 PMD 0 [] Oops: 0000 [#1] SMP NOPTI [] CPU: 1 PID: 15 Comm: ksoftirqd/1 Tainted: G O 5.9.0-rc6+ #2 [] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS [...] [] RIP: 0010:tipc_named_rcv+0x103/0x320 [tipc] [] Code: 41 89 44 24 10 49 8b 16 49 8b 46 08 49 c7 06 00 00 00 [...] [] RSP: 0018:ffffc900000a7c58 EFLAGS: 00000282 [] RAX: 00000000000012ec RBX: 0000000000000000 RCX: ffff88807bde1270 [] RDX: 0000000000002c7c RSI: 0000000000002c7c RDI: ffff88807b38f1a8 [] RBP: ffff88807b006288 R08: ffff88806a367800 R09: ffff88806a367900 [] R10: ffff88806a367a00 R11: ffff88806a367b00 R12: ffff88807b006258 [] R13: ffff88807b00628a R14: ffff888069334d00 R15: ffff88806a434600 [] FS: 0000000000000000(0000) GS:ffff888079480000(0000) knlGS:0[...] [] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [] CR2: 0000000000000000 CR3: 0000000077320000 CR4: 00000000000006e0 [] Call Trace: [] ? tipc_bcast_rcv+0x9a/0x1a0 [tipc] [] tipc_rcv+0x40d/0x670 [tipc] [] ? _raw_spin_unlock+0xa/0x20 [] tipc_l2_rcv_msg+0x55/0x80 [tipc] [] __netif_receive_skb_one_core+0x8c/0xa0 [] process_backlog+0x98/0x140 [] net_rx_action+0x13a/0x420 [] __do_softirq+0xdb/0x316 [] ? smpboot_thread_fn+0x2f/0x1e0 [] ? smpboot_thread_fn+0x74/0x1e0 [] ? smpboot_thread_fn+0x14e/0x1e0 [] run_ksoftirqd+0x1a/0x40 [] smpboot_thread_fn+0x149/0x1e0 [] ? sort_range+0x20/0x20 [] kthread+0x131/0x150 [] ? kthread_unuse_mm+0xa0/0xa0 [] ret_from_fork+0x22/0x30 [] Modules linked in: veth tipc(O) ip6_udp_tunnel udp_tunnel [...] [] CR2: 0000000000000000 [] ---[ end trace 65c276a8e2e2f310 ]--- To fix this, we need to grab the lock of the 'namedq' list on both path calling. Fixes: cad2929dc432 ("tipc: update a binding service via broadcast") Acked-by: Jon Maloy Signed-off-by: Hoang Huu Le Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ee1f41972c460b80b7d0d3ab48b9e091ae71ac09 Author: Rohit Maheshwari Date: Thu Oct 8 00:10:21 2020 +0530 net/tls: sendfile fails with ktls offload [ Upstream commit ea1dd3e9d080c961b9a451130b61c72dc9a5397b ] At first when sendpage gets called, if there is more data, 'more' in tls_push_data() gets set which later sets pending_open_record_frags, but when there is no more data in file left, and last time tls_push_data() gets called, pending_open_record_frags doesn't get reset. And later when 2 bytes of encrypted alert comes as sendmsg, it first checks for pending_open_record_frags, and since this is set, it creates a record with 0 data bytes to encrypt, meaning record length is prepend_size + tag_size only, which causes problem. We should set/reset pending_open_record_frags based on more bit. Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure") Signed-off-by: Rohit Maheshwari Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4f33f7c5e3ebf3122d80c8cb01fb310d10fb5d89 Author: Karsten Graul Date: Wed Oct 14 19:43:28 2020 +0200 net/smc: fix valid DMBE buffer sizes [ Upstream commit ef12ad45880b696eb993d86c481ca891836ab593 ] The SMCD_DMBE_SIZES should include all valid DMBE buffer sizes, so the correct value is 6 which means 1MB. With 7 the registration of an ISM buffer would always fail because of the invalid size requested. Fix that and set the value to 6. Fixes: c6ba7c9ba43d ("net/smc: add base infrastructure for SMC-D and ISM") Signed-off-by: Karsten Graul Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3d1b5d3c4da7426dcc11ae9a9ea1247dec255bfb Author: Karsten Graul Date: Wed Oct 14 19:43:27 2020 +0200 net/smc: fix use-after-free of delayed events [ Upstream commit d535ca1367787ddc8bff22d679a11f864c8228bc ] When a delayed event is enqueued then the event worker will send this event the next time it is running and no other flow is currently active. The event handler is called for the delayed event, and the pointer to the event keeps set in lgr->delayed_event. This pointer is cleared later in the processing by smc_llc_flow_start(). This can lead to a use-after-free condition when the processing does not reach smc_llc_flow_start(), but frees the event because of an error situation. Then the delayed_event pointer is still set but the event is freed. Fix this by always clearing the delayed event pointer when the event is provided to the event handler for processing, and remove the code to clear it in smc_llc_flow_start(). Fixes: 555da9af827d ("net/smc: add event-based llc_flow framework") Signed-off-by: Karsten Graul Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ea4f9b89ca785d702c403f6f1621d7e427190d3a Author: Leon Romanovsky Date: Wed Oct 14 11:56:42 2020 +0300 net: sched: Fix suspicious RCU usage while accessing tcf_tunnel_info [ Upstream commit d086a1c65aabb5a4e1edc580ca583e2964c62b44 ] The access of tcf_tunnel_info() produces the following splat, so fix it by dereferencing the tcf_tunnel_key_params pointer with marker that internal tcfa_liock is held. ============================= WARNING: suspicious RCU usage 5.9.0+ #1 Not tainted ----------------------------- include/net/tc_act/tc_tunnel_key.h:59 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by tc/34839: #0: ffff88828572c2a0 (&p->tcfa_lock){+...}-{2:2}, at: tc_setup_flow_action+0xb3/0x48b5 stack backtrace: CPU: 1 PID: 34839 Comm: tc Not tainted 5.9.0+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0x9a/0xd0 tc_setup_flow_action+0x14cb/0x48b5 fl_hw_replace_filter+0x347/0x690 [cls_flower] fl_change+0x2bad/0x4875 [cls_flower] tc_new_tfilter+0xf6f/0x1ba0 rtnetlink_rcv_msg+0x5f2/0x870 netlink_rcv_skb+0x124/0x350 netlink_unicast+0x433/0x700 netlink_sendmsg+0x6f1/0xbd0 sock_sendmsg+0xb0/0xe0 ____sys_sendmsg+0x4fa/0x6d0 ___sys_sendmsg+0x12e/0x1b0 __sys_sendmsg+0xa4/0x120 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f1f8cd4fe57 Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RSP: 002b:00007ffdc1e193b8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1f8cd4fe57 RDX: 0000000000000000 RSI: 00007ffdc1e19420 RDI: 0000000000000003 RBP: 000000005f85aafa R08: 0000000000000001 R09: 00007ffdc1e1936c R10: 000000000040522d R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000000 R14: 00007ffdc1e1d6f0 R15: 0000000000482420 Fixes: 3ebaf6da0716 ("net: sched: Do not assume RTNL is held in tunnel key action helpers") Fixes: 7a47281439ba ("net: sched: lock action when translating it to flow_action infra") Signed-off-by: Leon Romanovsky Acked-by: Cong Wang Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 255cc75c0203933d33ea8e0447eeb3751e82ca19 Author: Davide Caratti Date: Tue Oct 6 18:26:17 2020 +0200 net: mptcp: make DACK4/DACK8 usage consistent among all subflows [ Upstream commit 37198e93ced70733f0b993dff28b7c33857e254f ] using packetdrill it's possible to observe the same MPTCP DSN being acked by different subflows with DACK4 and DACK8. This is in contrast with what specified in RFC8684 §3.3.2: if an MPTCP endpoint transmits a 64-bit wide DSN, it MUST be acknowledged with a 64-bit wide DACK. Fix 'use_64bit_ack' variable to make it a property of MPTCP sockets, not TCP subflows. Fixes: a0c1d0eafd1e ("mptcp: Use 32-bit DATA_ACK when possible") Acked-by: Paolo Abeni Signed-off-by: Davide Caratti Reviewed-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 35fe97404ade018cf2bf9b0d62896b028d9faf64 Author: Alex Elder Date: Fri Oct 9 15:28:48 2020 -0500 net: ipa: skip suspend/resume activities if not set up [ Upstream commit d1704382821032fede445b816f4296fd379baacf ] When processing a system suspend request we suspend modem endpoints if they are enabled, and call ipa_cmd_tag_process() (which issues IPA commands) to ensure the IPA pipeline is cleared. It is an error to attempt to issue an IPA command before setup is complete, so this is clearly a bug. But we also shouldn't suspend or resume any endpoints that have not been set up. Have ipa_endpoint_suspend() and ipa_endpoint_resume() immediately return if setup hasn't completed, to avoid any attempt to configure endpoints or issue IPA commands in that case. Fixes: 84f9bd12d46d ("soc: qcom: ipa: IPA endpoints") Tested-by: Matthias Kaehlcke Signed-off-by: Alex Elder Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c2c599a98533513573538537d1e6a7620826285e Author: Yonghong Song Date: Wed Oct 14 07:46:12 2020 -0700 net: fix pos incrementment in ipv6_route_seq_next [ Upstream commit 6617dfd440149e42ce4d2be615eb31a4755f4d30 ] Commit 4fc427e05158 ("ipv6_route_seq_next should increase position index") tried to fix the issue where seq_file pos is not increased if a NULL element is returned with seq_ops->next(). See bug https://bugzilla.kernel.org/show_bug.cgi?id=206283 The commit effectively does: - increase pos for all seq_ops->start() - increase pos for all seq_ops->next() For ipv6_route, increasing pos for all seq_ops->next() is correct. But increasing pos for seq_ops->start() is not correct since pos is used to determine how many items to skip during seq_ops->start(): iter->skip = *pos; seq_ops->start() just fetches the *current* pos item. The item can be skipped only after seq_ops->show() which essentially is the beginning of seq_ops->next(). For example, I have 7 ipv6 route entries, root@arch-fb-vm1:~/net-next dd if=/proc/net/ipv6_route bs=4096 00000000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000400 00000001 00000000 00000001 eth0 fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000001 00000000 00000001 eth0 00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 00000000 00200200 lo 00000000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000003 00000000 80200001 lo fe800000000000002050e3fffebd3be8 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00000000 80200001 eth0 ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000004 00000000 00000001 eth0 00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 00000000 00200200 lo 0+1 records in 0+1 records out 1050 bytes (1.0 kB, 1.0 KiB) copied, 0.00707908 s, 148 kB/s root@arch-fb-vm1:~/net-next In the above, I specify buffer size 4096, so all records can be returned to user space with a single trip to the kernel. If I use buffer size 128, since each record size is 149, internally kernel seq_read() will read 149 into its internal buffer and return the data to user space in two read() syscalls. Then user read() syscall will trigger next seq_ops->start(). Since the current implementation increased pos even for seq_ops->start(), it will skip record #2, #4 and #6, assuming the first record is #1. root@arch-fb-vm1:~/net-next dd if=/proc/net/ipv6_route bs=128 00000000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000400 00000001 00000000 00000001 eth0 00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 00000000 00200200 lo fe800000000000002050e3fffebd3be8 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00000000 80200001 eth0 00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 00000000 00200200 lo 4+1 records in 4+1 records out 600 bytes copied, 0.00127758 s, 470 kB/s To fix the problem, create a fake pos pointer so seq_ops->start() won't actually increase seq_file pos. With this fix, the above `dd` command with `bs=128` will show correct result. Fixes: 4fc427e05158 ("ipv6_route_seq_next should increase position index") Cc: Alexei Starovoitov Suggested-by: Vasily Averin Reviewed-by: Vasily Averin Signed-off-by: Yonghong Song Acked-by: Martin KaFai Lau Acked-by: Andrii Nakryiko Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 48cc6381289869c7433f306adc25b80175f86ace Author: Marek Vasut Date: Tue Oct 6 15:52:53 2020 +0200 net: fec: Fix PHY init after phy_reset_after_clk_enable() [ Upstream commit 0da1ccbbefb662915228bc17e1c7d4ad28b3ddab ] The phy_reset_after_clk_enable() does a PHY reset, which means the PHY loses its register settings. The fec_enet_mii_probe() starts the PHY and does the necessary calls to configure the PHY via PHY framework, and loads the correct register settings into the PHY. Therefore, fec_enet_mii_probe() should be called only after the PHY has been reset, not before as it is now. Fixes: 1b0a83ac04e3 ("net: fec: add phy_reset_after_clk_enable() support") Reviewed-by: Andrew Lunn Tested-by: Richard Leitner Signed-off-by: Marek Vasut Cc: Christoph Niedermaier Cc: David S. Miller Cc: NXP Linux Team Cc: Shawn Guo Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ce88b5f42868ef4964c497d4dfcd25e88fd60c5b Author: Marek Vasut Date: Sat Oct 10 11:10:00 2020 +0200 net: fec: Fix phy_device lookup for phy_reset_after_clk_enable() [ Upstream commit 64a632da538a6827fad0ea461925cedb9899ebe2 ] The phy_reset_after_clk_enable() is always called with ndev->phydev, however that pointer may be NULL even though the PHY device instance already exists and is sufficient to perform the PHY reset. This condition happens in fec_open(), where the clock must be enabled first, then the PHY must be reset, and then the PHY IDs can be read out of the PHY. If the PHY still is not bound to the MAC, but there is OF PHY node and a matching PHY device instance already, use the OF PHY node to obtain the PHY device instance, and then use that PHY device instance when triggering the PHY reset. Fixes: 1b0a83ac04e3 ("net: fec: add phy_reset_after_clk_enable() support") Signed-off-by: Marek Vasut Cc: Christoph Niedermaier Cc: David S. Miller Cc: NXP Linux Team Cc: Richard Leitner Cc: Shawn Guo Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 100efd56d2fdfc1046fd6c65d7ba3b361176cf35 Author: Christian Eggers Date: Mon Oct 12 10:39:42 2020 +0200 net: dsa: microchip: fix race condition [ Upstream commit 8098bd69bc4e925070313b1b95d03510f4f24738 ] Between queuing the delayed work and finishing the setup of the dsa ports, the process may sleep in request_module() (via phy_device_create()) and the queued work may be executed prior to the switch net devices being registered. In ksz_mib_read_work(), a NULL dereference will happen within netof_carrier_ok(dp->slave). Not queuing the delayed work in ksz_init_mib_timer() makes things even worse because the work will now be queued for immediate execution (instead of 2000 ms) in ksz_mac_link_down() via dsa_port_link_register_of(). Call tree: ksz9477_i2c_probe() \--ksz9477_switch_register() \--ksz_switch_register() +--dsa_register_switch() | \--dsa_switch_probe() | \--dsa_tree_setup() | \--dsa_tree_setup_switches() | +--dsa_switch_setup() | | +--ksz9477_setup() | | | \--ksz_init_mib_timer() | | | |--/* Start the timer 2 seconds later. */ | | | \--schedule_delayed_work(&dev->mib_read, msecs_to_jiffies(2000)); | | \--__mdiobus_register() | | \--mdiobus_scan() | | \--get_phy_device() | | +--get_phy_id() | | \--phy_device_create() | | |--/* sleeping, ksz_mib_read_work() can be called meanwhile */ | | \--request_module() | | | \--dsa_port_setup() | +--/* Called for non-CPU ports */ | +--dsa_slave_create() | | +--/* Too late, ksz_mib_read_work() may be called beforehand */ | | \--port->slave = ... | ... | +--Called for CPU port */ | \--dsa_port_link_register_of() | \--ksz_mac_link_down() | +--/* mib_read must be initialized here */ | +--/* work is already scheduled, so it will be executed after 2000 ms */ | \--schedule_delayed_work(&dev->mib_read, 0); \-- /* here port->slave is setup properly, scheduling the delayed work should be safe */ Solution: 1. Do not queue (only initialize) delayed work in ksz_init_mib_timer(). 2. Only queue delayed work in ksz_mac_link_down() if init is completed. 3. Queue work once in ksz_switch_register(), after dsa_register_switch() has completed. Fixes: 7c6ff470aa86 ("net: dsa: microchip: add MIB counter reading support") Signed-off-by: Christian Eggers Reviewed-by: Florian Fainelli Reviewed-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e1a2e59d0319f9a97ca0cff43d1023560102e9c9 Author: Paolo Abeni Date: Fri Oct 9 19:00:01 2020 +0200 mptcp: subflows garbage collection [ Upstream commit 0e4f35d7880157ceccf0a58377d778b02762af82 ] The msk can close MP_JOIN subflows if the initial handshake fails. Currently such subflows are kept alive in the conn_list until the msk itself is closed. Beyond the wasted memory, we could end-up sending the DATA_FIN and the DATA_FIN ack on such socket, even after a reset. Fixes: 43b54c6ee382 ("mptcp: Use full MPTCP-level disconnect state machine") Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ea20fe4e91bc8616bf7fba3aaf9f0230281a49c6 Author: Paolo Abeni Date: Fri Oct 9 19:00:00 2020 +0200 mptcp: fix fallback for MP_JOIN subflows [ Upstream commit d582484726c4c46c8580923e855665fb91e3463e ] Additional/MP_JOIN subflows that do not pass some initial handshake tests currently causes fallback to TCP. That is an RFC violation: we should instead reset the subflow and leave the the msk untouched. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/91 Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests") Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8e9d575c3f9bdb7ccf2efe19ec3b2e87069e4b34 Author: Jonathan Lemon Date: Thu Oct 8 11:45:26 2020 -0700 mlx4: handle non-napi callers to napi_poll [ Upstream commit b2b8a92733b288128feb57ffa694758cf475106c ] netcons calls napi_poll with a budget of 0 to transmit packets. Handle this by: - skipping RX processing - do not try to recycle TX packets to the RX cache Signed-off-by: Jonathan Lemon Reviewed-by: Tariq Toukan Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 540718f26b5f09913e3b92f40d768e6971c6cec5 Author: David Ahern Date: Fri Oct 9 11:01:01 2020 -0700 ipv4: Restore flowi4_oif update before call to xfrm_lookup_route [ Upstream commit 874fb9e2ca949b443cc419a4f2227cafd4381d39 ] Tobias reported regressions in IPsec tests following the patch referenced by the Fixes tag below. The root cause is dropping the reset of the flowi4_oif after the fib_lookup. Apparently it is needed for xfrm cases, so restore the oif update to ip_route_output_flow right before the call to xfrm_lookup_route. Fixes: 2fbc6e89b2f1 ("ipv4: Update exception handling for multipath routes via same device") Reported-by: Tobias Brunner Signed-off-by: David Ahern Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3eb68005a7e7c041bc06c0a323c63ba7bde0a4eb Author: Herat Ramani Date: Tue Oct 13 15:01:29 2020 +0530 cxgb4: handle 4-tuple PEDIT to NAT mode translation [ Upstream commit 2ef813b8f405db3f72202b6fcae40a628ab80a53 ] The 4-tuple NAT offload via PEDIT always overwrites all the 4-tuple fields even if they had not been explicitly enabled. If any fields in the 4-tuple are not enabled, then the hardware overwrites the disabled fields with zeros, instead of ignoring them. So, add a parser that can translate the enabled 4-tuple PEDIT fields to one of the NAT mode combinations supported by the hardware and hence avoid overwriting disabled fields to 0. Any rule with unsupported NAT mode combination is rejected. Signed-off-by: Herat Ramani Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4b470a704b4e2873b066fba49767989b4ebd221a Author: David Wilder Date: Tue Oct 13 16:20:14 2020 -0700 ibmveth: Identify ingress large send packets. [ Upstream commit 413f142cc05cb03f2d1ea83388e40c1ddc0d74e9 ] Ingress large send packets are identified by either: The IBMVETH_RXQ_LRG_PKT flag in the receive buffer or with a -1 placed in the ip header checksum. The method used depends on firmware version. Frame geometry and sufficient header validation is performed by the hypervisor eliminating the need for further header checks here. Fixes: 7b5967389f5a ("ibmveth: set correct gso_size and gso_type") Signed-off-by: David Wilder Reviewed-by: Thomas Falcon Reviewed-by: Cristobal Forno Reviewed-by: Pradeep Satyanarayana Acked-by: Willem de Bruijn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 47762587877b65655c6613258ef5059397ca09fd Author: David Wilder Date: Tue Oct 13 16:20:13 2020 -0700 ibmveth: Switch order of ibmveth_helper calls. [ Upstream commit 5ce9ad815a296374ca21f43f3b1ab5083d202ee1 ] ibmveth_rx_csum_helper() must be called after ibmveth_rx_mss_helper() as ibmveth_rx_csum_helper() may alter ip and tcp checksum values. Fixes: 66aa0678efc2 ("ibmveth: Support to enable LSO/CSO for Trunk VEA.") Signed-off-by: David Wilder Reviewed-by: Thomas Falcon Reviewed-by: Cristobal Forno Reviewed-by: Pradeep Satyanarayana Acked-by: Willem de Bruijn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman