commit fe0d27d7358b89cd4cc43edda23044650827516e Author: Greg Kroah-Hartman Date: Wed Apr 7 15:02:36 2021 +0200 Linux 5.11.12 Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Jason Self Tested-by: Shuah Khan Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20210405085034.233917714@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 91a4e81029c37a56c4113746fcd3e3eb678608b5 Author: David S. Miller Date: Fri Mar 12 12:15:03 2021 -0800 Revert "net: bonding: fix error return code of bond_neigh_init()" commit 080bfa1e6d928a5d1f185cc44e5f3c251df06df5 upstream. This reverts commit 2055a99da8a253a357bdfd359b3338ef3375a26c. This change rejects legitimate configurations. A slave doesn't need to exist nor implement ndo_slave_setup. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a73c62a39dd73dcac7a403c07743ff09a84b53fa Author: Jens Axboe Date: Thu Mar 25 18:22:11 2021 -0600 Revert "kernel: freezer should treat PF_IO_WORKER like PF_KTHREAD for freezing" commit d3dc04cd81e0eaf50b2d09ab051a13300e587439 upstream. This reverts commit 15b2219facadec583c24523eed40fa45865f859f. Before IO threads accepted signals, the freezer using take signals to wake up an IO thread would cause them to loop without any way to clear the pending signal. That is no longer the case, so stop special casing PF_IO_WORKER in the freezer. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d1f9651028c12e7eee59cdcda784f247ea5c0a99 Author: Pavel Begunkov Date: Tue Mar 23 10:52:38 2021 +0000 io_uring: do ctx sqd ejection in a clear context commit a185f1db59f13de73aa470559030e90e50b34d93 upstream. WARNING: CPU: 1 PID: 27907 at fs/io_uring.c:7147 io_sq_thread_park+0xb5/0xd0 fs/io_uring.c:7147 CPU: 1 PID: 27907 Comm: iou-sqp-27905 Not tainted 5.12.0-rc4-syzkaller #0 RIP: 0010:io_sq_thread_park+0xb5/0xd0 fs/io_uring.c:7147 Call Trace: io_ring_ctx_wait_and_kill+0x214/0x700 fs/io_uring.c:8619 io_uring_release+0x3e/0x50 fs/io_uring.c:8646 __fput+0x288/0x920 fs/file_table.c:280 task_work_run+0xdd/0x1a0 kernel/task_work.c:140 io_run_task_work fs/io_uring.c:2238 [inline] io_run_task_work fs/io_uring.c:2228 [inline] io_uring_try_cancel_requests+0x8ec/0xc60 fs/io_uring.c:8770 io_uring_cancel_sqpoll+0x1cf/0x290 fs/io_uring.c:8974 io_sqpoll_cancel_cb+0x87/0xb0 fs/io_uring.c:8907 io_run_task_work_head+0x58/0xb0 fs/io_uring.c:1961 io_sq_thread+0x3e2/0x18d0 fs/io_uring.c:6763 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 May happen that last ctx ref is killed in io_uring_cancel_sqpoll(), so fput callback (i.e. io_uring_release()) is enqueued through task_work, and run by same cancellation. As it's deeply nested we can't do parking or taking sqd->lock there, because its state is unclear. So avoid ctx ejection from sqd list from io_ring_ctx_wait_and_kill() and do it in a clear context in io_ring_exit_work(). Fixes: f6d54255f423 ("io_uring: halt SQO submission on ctx exit") Reported-by: syzbot+e3a3f84f5cecf61f0583@syzkaller.appspotmail.com Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/e90df88b8ff2cabb14a7534601d35d62ab4cb8c7.1616496707.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit bb4f97aea0864d94c7f914a6af710077b2785cff Author: Ben Dooks Date: Mon Mar 29 10:57:49 2021 +0100 riscv: evaluate put_user() arg before enabling user access commit 285a76bb2cf51b0c74c634f2aaccdb93e1f2a359 upstream. The header has a problem with put_user(a, ptr) if the 'a' is not a simple variable, such as a function. This can lead to the compiler producing code as so: 1: enable_user_access() 2: evaluate 'a' into register 'r' 3: put 'r' to 'ptr' 4: disable_user_acess() The issue is that 'a' is now being evaluated with the user memory protections disabled. So we try and force the evaulation by assigning 'x' to __val at the start, and hoping the compiler barriers in enable_user_access() do the job of ordering step 2 before step 1. This has shown up in a bug where 'a' sleeps and thus schedules out and loses the SR_SUM flag. This isn't sufficient to fully fix, but should reduce the window of opportunity. The first instance of this we found is in scheudle_tail() where the code does: $ less -N kernel/sched/core.c 4263 if (current->set_child_tid) 4264 put_user(task_pid_vnr(current), current->set_child_tid); Here, the task_pid_vnr(current) is called within the block that has enabled the user memory access. This can be made worse with KASAN which makes task_pid_vnr() a rather large call with plenty of opportunity to sleep. Signed-off-by: Ben Dooks Reported-by: syzbot+e74b94fe601ab9552d69@syzkaller.appspotmail.com Suggested-by: Arnd Bergman Signed-off-by: Greg Kroah-Hartman -- Changes since v1: - fixed formatting and updated the patch description with more info Changes since v2: - fixed commenting on __put_user() (schwab@linux-m68k.org) Change since v3: - fixed RFC in patch title. Should be ready to merge. Signed-off-by: Palmer Dabbelt commit 4095574dc314ff998311a8e3d5dc8669f5a7d8e4 Author: Du Cheng Date: Fri Mar 12 16:14:21 2021 +0800 drivers: video: fbcon: fix NULL dereference in fbcon_cursor() commit 01faae5193d6190b7b3aa93dae43f514e866d652 upstream. add null-check on function pointer before dereference on ops->cursor Reported-by: syzbot+b67aaae8d3a927f68d20@syzkaller.appspotmail.com Cc: stable Signed-off-by: Du Cheng Link: https://lore.kernel.org/r/20210312081421.452405-1-ducheng2@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9e7a6633f8409a2d492088e5d099c582c8df4d9d Author: Ahmad Fatoum Date: Fri Mar 19 12:04:57 2021 +0100 driver core: clear deferred probe reason on probe retry commit f0acf637d60ffcef3ccb6e279f743e587b3c7359 upstream. When retrying a deferred probe, any old defer reason string should be discarded. Otherwise, if the probe is deferred again at a different spot, but without setting a message, the now incorrect probe reason will remain. This was observed with the i.MX I2C driver, which ultimately failed to probe due to lack of the GPIO driver. The probe defer for GPIO doesn't record a message, but a previous probe defer to clock_get did. This had the effect that /sys/kernel/debug/devices_deferred listed a misleading probe deferral reason. Cc: stable Fixes: d090b70ede02 ("driver core: add deferring probe reason to devices_deferred property") Reviewed-by: Andy Shevchenko Reviewed-by: Andrzej Hajda Signed-off-by: Ahmad Fatoum Link: https://lore.kernel.org/r/20210319110459.19966-1-a.fatoum@pengutronix.de Signed-off-by: Greg Kroah-Hartman commit b5fab3adcf0027a1a5e715a9f62c021192bdee62 Author: Atul Gopinathan Date: Tue Mar 23 17:04:14 2021 +0530 staging: rtl8192e: Change state information from u16 to u8 commit e78836ae76d20f38eed8c8c67f21db97529949da upstream. The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4 bytes in total while the operations performed on this array through-out the code base are only 2 bytes. The "CcxRmState" field is fed only 2 bytes of data using memcpy(): (In rtllib_rx.c:1972) memcpy(network->CcxRmState, &info_element->data[4], 2) With "info_element->data[]" being a u8 array, if 2 bytes are written into "CcxRmState" (whose one element is u16 size), then the 2 u8 elements from "data[]" gets squashed and written into the first element ("CcxRmState[0]") while the second element ("CcxRmState[1]") is never fed with any data. Same in file rtllib_rx.c:2522: memcpy(dst->CcxRmState, src->CcxRmState, 2); The above line duplicates "src" data to "dst" but only writes 2 bytes (and not 4, which is the actual size). Again, only 1st element gets the value while the 2nd element remains uninitialized. This later makes operations done with CcxRmState unpredictable in the following lines as the 1st element is having a squashed number while the 2nd element is having an uninitialized random number. rtllib_rx.c:1973: if (network->CcxRmState[0] != 0) rtllib_rx.c:1977: network->MBssidMask = network->CcxRmState[1] & 0x07; network->MBssidMask is also of type u8 and not u16. Fix this by changing the type of "CcxRmState" from u16 to u8 so that the data written into this array and read from it make sense and are not random values. NOTE: The wrong initialization of "CcxRmState" can be seen in the following commit: commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver") The above commit created a file `rtl8192e/ieee80211.h` which used to have the faulty line. The file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib.h` along with additional code in the commit 94a799425eee (tagged in Fixes). Fixes: 94a799425eee ("From: wlanfae [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan Link: https://lore.kernel.org/r/20210323113413.29179-2-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman commit c14876c9324a942bc5ba5ea58cdb92521b646b5f Author: Atul Gopinathan Date: Tue Mar 23 17:04:12 2021 +0530 staging: rtl8192e: Fix incorrect source in memcpy() commit 72ad25fbbb78930f892b191637359ab5b94b3190 upstream. The variable "info_element" is of the following type: struct rtllib_info_element *info_element defined in drivers/staging/rtl8192e/rtllib.h: struct rtllib_info_element { u8 id; u8 len; u8 data[]; } __packed; The "len" field defines the size of the "data[]" array. The code is supposed to check if "info_element->len" is greater than 4 and later equal to 6. If this is satisfied then, the last two bytes (the 4th and 5th element of u8 "data[]" array) are copied into "network->CcxRmState". Right now the code uses "memcpy()" with the source as "&info_element[4]" which would copy in wrong and unintended information. The struct "rtllib_info_element" has a size of 2 bytes for "id" and "len", therefore indexing will be done in interval of 2 bytes. So, "info_element[4]" would point to data which is beyond the memory allocated for this pointer (that is, at x+8, while "info_element" has been allocated only from x to x+7 (2 + 6 => 8 bytes)). This patch rectifies this error by using "&info_element->data[4]" which correctly copies the last two bytes of "data[]". NOTE: The faulty line of code came from the following commit: commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver") The above commit created the file `rtl8192e/ieee80211/ieee80211_rx.c` which had the faulty line of code. This file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib_rx.c` along with additional code in the commit 94a799425eee (tagged in Fixes). Fixes: 94a799425eee ("From: wlanfae [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan Link: https://lore.kernel.org/r/20210323113413.29179-1-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4c0a245222273174b63af22956be2821a96d925b Author: Roja Rani Yarubandi Date: Wed Mar 24 15:48:35 2021 +0530 soc: qcom-geni-se: Cleanup the code to remove proxy votes commit 29d96eb261345c8d888e248ae79484e681be2faa upstream. This reverts commit 048eb908a1f2 ("soc: qcom-geni-se: Add interconnect support to fix earlycon crash") ICC core and platforms drivers supports sync_state feature, which ensures that the default ICC BW votes from the bootloader is not removed until all it's consumers are probes. The proxy votes were needed in case other QUP child drivers I2C, SPI probes before UART, they can turn off the QUP-CORE clock which is shared resources for all QUP driver, this causes unclocked access to HW from earlycon. Given above support from ICC there is no longer need to maintain proxy votes on QUP-CORE ICC node from QUP wrapper driver for early console usecase, the default votes won't be removed until real console is probed. Cc: stable@vger.kernel.org Fixes: 266cd33b5913 ("interconnect: qcom: Ensure that the floor bandwidth value is enforced") Fixes: 7d3b0b0d8184 ("interconnect: qcom: Use icc_sync_state") Signed-off-by: Roja Rani Yarubandi Signed-off-by: Akash Asthana Reviewed-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20210324101836.25272-2-rojay@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 829f5db1cf550f138ed0a4f81325de47b71c49f5 Author: Wesley Cheng Date: Wed Mar 24 11:31:04 2021 -0700 usb: dwc3: gadget: Clear DEP flags after stop transfers in ep disable commit 5aef629704ad4d983ecf5c8a25840f16e45b6d59 upstream. Ensure that dep->flags are cleared until after stop active transfers is completed. Otherwise, the ENDXFER command will not be executed during ep disable. Fixes: f09ddcfcb8c5 ("usb: dwc3: gadget: Prevent EP queuing while stopping transfers") Cc: stable Reported-and-tested-by: Andy Shevchenko Tested-by: Marek Szyprowski Signed-off-by: Wesley Cheng Link: https://lore.kernel.org/r/1616610664-16495-1-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit ac523506d9f501e9dfc2e713e9ce610e5e1a6dd4 Author: Shawn Guo Date: Thu Mar 11 14:03:18 2021 +0800 usb: dwc3: qcom: skip interconnect init for ACPI probe commit 5e4010e36a58978e42b2ee13739ff9b50209c830 upstream. The ACPI probe starts failing since commit bea46b981515 ("usb: dwc3: qcom: Add interconnect support in dwc3 driver"), because there is no interconnect support for ACPI, and of_icc_get() call in dwc3_qcom_interconnect_init() will just return -EINVAL. Fix the problem by skipping interconnect init for ACPI probe, and then the NULL icc_path_ddr will simply just scheild all ICC calls. Fixes: bea46b981515 ("usb: dwc3: qcom: Add interconnect support in dwc3 driver") Signed-off-by: Shawn Guo Cc: stable Link: https://lore.kernel.org/r/20210311060318.25418-1-shawn.guo@linaro.org Signed-off-by: Greg Kroah-Hartman commit 79b09e4f9493804b55955e7901b7fbc304fe1a8d Author: Artur Petrosyan Date: Fri Mar 26 14:25:09 2021 +0400 usb: dwc2: Prevent core suspend when port connection flag is 0 commit 93f672804bf2d7a49ef3fd96827ea6290ca1841e upstream. In host mode port connection status flag is "0" when loading the driver. After loading the driver system asserts suspend which is handled by "_dwc2_hcd_suspend()" function. Before the system suspend the port connection status is "0". As result need to check the "port_connect_status" if it is "0", then skipping entering to suspend. Cc: # 5.2 Fixes: 6f6d70597c15 ("usb: dwc2: bus suspend/resume for hosts with DWC2_POWER_DOWN_PARAM_NONE") Signed-off-by: Artur Petrosyan Link: https://lore.kernel.org/r/20210326102510.BDEDEA005D@mailhost.synopsys.com Signed-off-by: Greg Kroah-Hartman commit 7be498bb74dc8b241b05652e654d2531f1adc1c6 Author: Artur Petrosyan Date: Fri Mar 26 14:24:46 2021 +0400 usb: dwc2: Fix HPRT0.PrtSusp bit setting for HiKey 960 board. commit 5e3bbae8ee3d677a0aa2919dc62b5c60ea01ba61 upstream. Increased the waiting timeout for HPRT0.PrtSusp register field to be set, because on HiKey 960 board HPRT0.PrtSusp wasn't generated with the existing timeout. Cc: # 4.18 Fixes: 22bb5cfdf13a ("usb: dwc2: Fix host exit from hibernation flow.") Signed-off-by: Artur Petrosyan Acked-by: Minas Harutyunyan Link: https://lore.kernel.org/r/20210326102447.8F7FEA005D@mailhost.synopsys.com Signed-off-by: Greg Kroah-Hartman commit 7411ca1485b3fef2f55fe6300d7b92270f2944bf Author: Tong Zhang Date: Wed Mar 17 19:04:00 2021 -0400 usb: gadget: udc: amd5536udc_pci fix null-ptr-dereference commit 72035f4954f0bca2d8c47cf31b3629c42116f5b7 upstream. init_dma_pools() calls dma_pool_create(...dev->dev) to create dma pool. however, dev->dev is actually set after calling init_dma_pools(), which effectively makes dma_pool_create(..NULL) and cause crash. To fix this issue, init dma only after dev->dev is set. [ 1.317993] RIP: 0010:dma_pool_create+0x83/0x290 [ 1.323257] Call Trace: [ 1.323390] ? pci_write_config_word+0x27/0x30 [ 1.323626] init_dma_pools+0x41/0x1a0 [snps_udc_core] [ 1.323899] udc_pci_probe+0x202/0x2b1 [amd5536udc_pci] Fixes: 7c51247a1f62 (usb: gadget: udc: Provide correct arguments for 'dma_pool_create') Cc: stable Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210317230400.357756-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3fc31a44e3db91a81658460e29c95f9562b3a4ce Author: Johan Hovold Date: Mon Mar 22 16:53:12 2021 +0100 USB: cdc-acm: fix use-after-free after probe failure commit 4e49bf376c0451ad2eae2592e093659cde12be9a upstream. If tty-device registration fails the driver would fail to release the data interface. When the device is later disconnected, the disconnect callback would still be called for the data interface and would go about releasing already freed resources. Fixes: c93d81955005 ("usb: cdc-acm: fix error handling in acm_probe()") Cc: stable@vger.kernel.org # 3.9 Cc: Alexey Khoroshilov Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210322155318.9837-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2439d152383ce3d5c16ac3020593c350f0195e11 Author: Johan Hovold Date: Mon Mar 22 16:53:11 2021 +0100 USB: cdc-acm: fix double free on probe failure commit 7180495cb3d0e2a2860d282a468b4146c21da78f upstream. If tty-device registration fails the driver copy of any Country Selection functional descriptor would end up being freed twice; first explicitly in the error path and then again in the tty-port destructor. Drop the first erroneous free that was left when fixing a tty-port resource leak. Fixes: cae2bc768d17 ("usb: cdc-acm: Decrement tty port's refcount if probe() fail") Cc: stable@vger.kernel.org # 4.19 Cc: Jaejoong Kim Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210322155318.9837-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit b89a56065f3e55220e17ee7f68634ee56805bd2f Author: Oliver Neukum Date: Thu Mar 11 14:01:26 2021 +0100 USB: cdc-acm: downgrade message to debug commit e4c77070ad45fc940af1d7fb1e637c349e848951 upstream. This failure is so common that logging an error here amounts to spamming log files. Reviewed-by: Bruno Thomsen Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20210311130126.15972-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 826a02e1e2d1ad93707478f48d07c2882914f841 Author: Oliver Neukum Date: Thu Mar 11 14:01:25 2021 +0100 USB: cdc-acm: untangle a circular dependency between callback and softint commit 6069e3e927c8fb3a1947b07d1a561644ea960248 upstream. We have a cycle of callbacks scheduling works which submit URBs with thos callbacks. This needs to be blocked, stopped and unblocked to untangle the circle. The issue leads to faults like: [ 55.068392] Unable to handle kernel paging request at virtual address 6b6b6c03 [ 55.075624] pgd = be866494 [ 55.078335] [6b6b6c03] *pgd=00000000 [ 55.081924] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 55.087238] Modules linked in: ppp_async crc_ccitt ppp_generic slhc xt_TCPMSS xt_tcpmss xt_hl nf_log_ipv6 nf_log_ipv4 nf_log_common xt_policy xt_limit xt_conntrack xt_tcpudp xt_pkttype ip6table_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle ip6table_filter ip6_tables iptable_filter ip_tables des_generic md5 sch_fq_codel cdc_mbim cdc_wdm cdc_ncm usbnet mii cdc_acm usb_storage ip_tunnel xfrm_user xfrm6_tunnel tunnel6 xfrm4_tunnel tunnel4 esp6 esp4 ah6 ah4 xfrm_algo xt_LOG xt_LED xt_comment x_tables ipv6 [ 55.134954] CPU: 0 PID: 82 Comm: kworker/0:2 Tainted: G T 5.8.17 #1 [ 55.142526] Hardware name: Freescale i.MX7 Dual (Device Tree) [ 55.148304] Workqueue: events acm_softint [cdc_acm] [ 55.153196] PC is at kobject_get+0x10/0xa4 [ 55.157302] LR is at usb_get_dev+0x14/0x1c [ 55.161402] pc : [<8047c06c>] lr : [<80560448>] psr: 20000193 [ 55.167671] sp : bca39ea8 ip : 00007374 fp : bf6cbd80 [ 55.172899] r10: 00000000 r9 : bdd92284 r8 : bdd92008 [ 55.178128] r7 : 6b6b6b6b r6 : fffffffe r5 : 60000113 r4 : 6b6b6be3 [ 55.184658] r3 : 6b6b6b6b r2 : 00000111 r1 : 00000000 r0 : 6b6b6be3 [ 55.191191] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none [ 55.198417] Control: 10c5387d Table: bcf0c06a DAC: 00000051 [ 55.204168] Process kworker/0:2 (pid: 82, stack limit = 0x9bdd2a89) [ 55.210439] Stack: (0xbca39ea8 to 0xbca3a000) [ 55.214805] 9ea0: bf6cbd80 80769a50 6b6b6b6b 80560448 bdeb0500 8056bfe8 [ 55.222991] 9ec0: 00000002 b76da000 00000000 bdeb0500 bdd92448 bca38000 bdeb0510 8056d69c [ 55.231177] 9ee0: bca38000 00000000 80c050fc 00000000 bca39f44 09d42015 00000000 00000001 [ 55.239363] 9f00: bdd92448 bdd92438 bdd92000 7f1158c4 bdd92448 bca2ee00 bf6cbd80 bf6cef00 [ 55.247549] 9f20: 00000000 00000000 00000000 801412d8 bf6cbd98 80c03d00 bca2ee00 bf6cbd80 [ 55.255735] 9f40: bca2ee14 bf6cbd98 80c03d00 00000008 bca38000 80141568 00000000 80c446ae [ 55.263921] 9f60: 00000000 bc9ed880 bc9f0700 bca38000 bc117eb4 80141524 bca2ee00 bc9ed8a4 [ 55.272107] 9f80: 00000000 80147cc8 00000000 bc9f0700 80147b84 00000000 00000000 00000000 [ 55.280292] 9fa0: 00000000 00000000 00000000 80100148 00000000 00000000 00000000 00000000 [ 55.288477] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 55.296662] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 55.304860] [<8047c06c>] (kobject_get) from [<80560448>] (usb_get_dev+0x14/0x1c) [ 55.312271] [<80560448>] (usb_get_dev) from [<8056bfe8>] (usb_hcd_unlink_urb+0x50/0xd8) [ 55.320286] [<8056bfe8>] (usb_hcd_unlink_urb) from [<8056d69c>] (usb_kill_urb.part.0+0x44/0xd0) [ 55.329004] [<8056d69c>] (usb_kill_urb.part.0) from [<7f1158c4>] (acm_softint+0x4c/0x10c [cdc_acm]) [ 55.338082] [<7f1158c4>] (acm_softint [cdc_acm]) from [<801412d8>] (process_one_work+0x19c/0x3e8) [ 55.346969] [<801412d8>] (process_one_work) from [<80141568>] (worker_thread+0x44/0x4dc) [ 55.355072] [<80141568>] (worker_thread) from [<80147cc8>] (kthread+0x144/0x180) [ 55.362481] [<80147cc8>] (kthread) from [<80100148>] (ret_from_fork+0x14/0x2c) [ 55.369706] Exception stack(0xbca39fb0 to 0xbca39ff8) Tested-by: Bruno Thomsen Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20210311130126.15972-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 9343cefaeb841f2582db0d2ae7ed5eb85c889015 Author: Oliver Neukum Date: Thu Mar 11 14:37:14 2021 +0100 cdc-acm: fix BREAK rx code path adding necessary calls commit 08dff274edda54310d6f1cf27b62fddf0f8d146e upstream. Counting break events is nice but we should actually report them to the tty layer. Fixes: 5a6a62bdb9257 ("cdc-acm: add TIOCMIWAIT") Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20210311133714.31881-1-oneukum@suse.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit d8f5fccdb6a954659f46335b26f3893e1bd1f4df Author: Chunfeng Yun Date: Tue Mar 23 15:02:46 2021 +0800 usb: xhci-mtk: fix broken streams issue on 0.96 xHCI commit 6f978a30c9bb12dab1302d0f06951ee290f5e600 upstream. The MediaTek 0.96 xHCI controller on some platforms does not support bulk stream even HCCPARAMS says supporting, due to MaxPSASize is set a default value 1 by mistake, here use XHCI_BROKEN_STREAMS quirk to fix it. Fixes: 94a631d91ad3 ("usb: xhci-mtk: check hcc_params after adding primary hcd") Cc: stable Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1616482975-17841-4-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit b535807543a95c9707b4944daaccda69627be088 Author: Tony Lindgren Date: Wed Mar 24 09:11:41 2021 +0200 usb: musb: Fix suspend with devices connected for a64 commit 92af4fc6ec331228aca322ca37c8aea7b150a151 upstream. Pinephone running on Allwinner A64 fails to suspend with USB devices connected as reported by Bhushan Shah . Reverting commit 5fbf7a253470 ("usb: musb: fix idling for suspend after disconnect interrupt") fixes the issue. Let's add suspend checks also for suspend after disconnect interrupt quirk handling like we already do elsewhere. Fixes: 5fbf7a253470 ("usb: musb: fix idling for suspend after disconnect interrupt") Reported-by: Bhushan Shah Tested-by: Bhushan Shah Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210324071142.42264-1-tony@atomide.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit b3c49b5c021d040d40b8915795d2bed2f081420e Author: Vincent Palatin Date: Fri Mar 19 13:48:02 2021 +0100 USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem commit 0bd860493f81eb2a46173f6f5e44cc38331c8dbd upstream. This LTE modem (M.2 card) has a bug in its power management: there is some kind of race condition for U3 wake-up between the host and the device. The modem firmware sometimes crashes/locks when both events happen at the same time and the modem fully drops off the USB bus (and sometimes re-enumerates, sometimes just gets stuck until the next reboot). Tested with the modem wired to the XHCI controller on an AMD 3015Ce platform. Without the patch, the modem dropped of the USB bus 5 times in 3 days. With the quirk, it stayed connected for a week while the 'runtime_suspended_time' counter incremented as excepted. Signed-off-by: Vincent Palatin Link: https://lore.kernel.org/r/20210319124802.2315195-1-vpalatin@chromium.org Cc: stable Signed-off-by: Greg Kroah-Hartman commit b324effa2201fbb5bfce35860984a86104ef601c Author: Shuah Khan Date: Wed Mar 24 17:06:54 2021 -0600 usbip: vhci_hcd fix shift out-of-bounds in vhci_hub_control() commit 1cc5ed25bdade86de2650a82b2730108a76de20c upstream. Fix shift out-of-bounds in vhci_hub_control() SetPortFeature handling. UBSAN: shift-out-of-bounds in drivers/usb/usbip/vhci_hcd.c:605:42 shift exponent 768 is too large for 32-bit type 'int' Reported-by: syzbot+3dea30b047f41084de66@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/20210324230654.34798-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 8936e89ffea69bc1e3bc9f4837b793d3231313c0 Author: Zheyu Ma Date: Sat Apr 3 06:58:36 2021 +0000 firewire: nosy: Fix a use-after-free bug in nosy_ioctl() [ Upstream commit 829933ef05a951c8ff140e814656d73e74915faf ] For each device, the nosy driver allocates a pcilynx structure. A use-after-free might happen in the following scenario: 1. Open nosy device for the first time and call ioctl with command NOSY_IOC_START, then a new client A will be malloced and added to doubly linked list. 2. Open nosy device for the second time and call ioctl with command NOSY_IOC_START, then a new client B will be malloced and added to doubly linked list. 3. Call ioctl with command NOSY_IOC_START for client A, then client A will be readded to the doubly linked list. Now the doubly linked list is messed up. 4. Close the first nosy device and nosy_release will be called. In nosy_release, client A will be unlinked and freed. 5. Close the second nosy device, and client A will be referenced, resulting in UAF. The root cause of this bug is that the element in the doubly linked list is reentered into the list. Fix this bug by adding a check before inserting a client. If a client is already in the linked list, don't insert it. The following KASAN report reveals it: BUG: KASAN: use-after-free in nosy_release+0x1ea/0x210 Write of size 8 at addr ffff888102ad7360 by task poc CPU: 3 PID: 337 Comm: poc Not tainted 5.12.0-rc5+ #6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: nosy_release+0x1ea/0x210 __fput+0x1e2/0x840 task_work_run+0xe8/0x180 exit_to_user_mode_prepare+0x114/0x120 syscall_exit_to_user_mode+0x1d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Allocated by task 337: nosy_open+0x154/0x4d0 misc_open+0x2ec/0x410 chrdev_open+0x20d/0x5a0 do_dentry_open+0x40f/0xe80 path_openat+0x1cf9/0x37b0 do_filp_open+0x16d/0x390 do_sys_openat2+0x11d/0x360 __x64_sys_open+0xfd/0x1a0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 337: kfree+0x8f/0x210 nosy_release+0x158/0x210 __fput+0x1e2/0x840 task_work_run+0xe8/0x180 exit_to_user_mode_prepare+0x114/0x120 syscall_exit_to_user_mode+0x1d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff888102ad7300 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 96 bytes inside of 128-byte region [ffff888102ad7300, ffff888102ad7380) [ Modified to use 'list_empty()' inside proper lock - Linus ] Link: https://lore.kernel.org/lkml/1617433116-5930-1-git-send-email-zheyuma97@gmail.com/ Reported-and-tested-by: 马哲宇 (Zheyu Ma) Signed-off-by: Zheyu Ma Cc: Greg Kroah-Hartman Cc: Stefan Richter Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 96fc113eac3e38567742cf8167a17c800782104c Author: Aneesh Kumar K.V Date: Fri Mar 26 12:37:55 2021 +0530 powerpc/mm/book3s64: Use the correct storage key value when calling H_PROTECT [ Upstream commit 53f1d31708f6240e4615b0927df31f182e389e2f ] H_PROTECT expects the flag value to include flags: AVPN, pp0, pp1, pp2, key0-key4, Noexec, CMO Option flags This patch updates hpte_updatepp() to fetch the storage key value from the linux page table and use the same in H_PROTECT hcall. native_hpte_updatepp() is not updated because the kernel doesn't clear the existing storage key value there. The kernel also doesn't use hpte_updatepp() callback for updating storage keys. This fixes the below kernel crash observed with KUAP enabled. BUG: Unable to handle kernel data access on write at 0xc009fffffc440000 Faulting instruction address: 0xc0000000000b7030 Key fault AMR: 0xfcffffffffffffff IAMR: 0xc0000077bc498100 Found HPTE: v = 0x40070adbb6fffc05 r = 0x1ffffffffff1194 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries ... CFAR: c000000000010100 DAR: c009fffffc440000 DSISR: 02200000 IRQMASK: 0 ... NIP memset+0x68/0x104 LR pcpu_alloc+0x54c/0xb50 Call Trace: pcpu_alloc+0x55c/0xb50 (unreliable) blk_stat_alloc_callback+0x94/0x150 blk_mq_init_allocated_queue+0x64/0x560 blk_mq_init_queue+0x54/0xb0 scsi_mq_alloc_queue+0x30/0xa0 scsi_alloc_sdev+0x1cc/0x300 scsi_probe_and_add_lun+0xb50/0x1020 __scsi_scan_target+0x17c/0x790 scsi_scan_channel+0x90/0xe0 scsi_scan_host_selected+0x148/0x1f0 do_scan_async+0x2c/0x2a0 async_run_entry_fn+0x78/0x220 process_one_work+0x264/0x540 worker_thread+0xa8/0x600 kthread+0x190/0x1a0 ret_from_kernel_thread+0x5c/0x6c With KUAP enabled the kernel uses storage key 3 for all its translations. But as shown by the debug print, in this specific case we have the hash page table entry created with key value 0. Found HPTE: v = 0x40070adbb6fffc05 r = 0x1ffffffffff1194 and DSISR indicates a key fault. This can happen due to parallel fault on the same EA by different CPUs: CPU 0 CPU 1 fault on X H_PAGE_BUSY set fault on X finish fault handling and clear H_PAGE_BUSY check for H_PAGE_BUSY continue with fault handling. This implies CPU1 will end up calling hpte_updatepp for address X and the kernel updated the hash pte entry with key 0 Fixes: d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation") Reported-by: Murilo Opsfelder Araujo Signed-off-by: Aneesh Kumar K.V Debugged-by: Michael Ellerman Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210326070755.304625-1-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin commit d5002b446a23c8b09ad0334721e99fa18a06745e Author: Lv Yunlong Date: Wed Mar 24 03:37:24 2021 -0700 video: hyperv_fb: Fix a double free in hvfb_probe [ Upstream commit 37df9f3fedb6aeaff5564145e8162aab912c9284 ] Function hvfb_probe() calls hvfb_getmem(), expecting upon return that info->apertures is either NULL or points to memory that should be freed by framebuffer_release(). But hvfb_getmem() is freeing the memory and leaving the pointer non-NULL, resulting in a double free if an error occurs or later if hvfb_remove() is called. Fix this by removing all kfree(info->apertures) calls in hvfb_getmem(). This will allow framebuffer_release() to free the memory, which follows the pattern of other fbdev drivers. Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.") Signed-off-by: Lv Yunlong Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20210324103724.4189-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit dfd8a2935d0203af431877c01ce582b13ea05ace Author: Andy Shevchenko Date: Mon Mar 22 14:52:44 2021 +0200 usb: dwc3: pci: Enable dis_uX_susphy_quirk for Intel Merrifield [ Upstream commit b522f830d35189e0283fa4d5b4b3ef8d7a78cfcb ] It seems that on Intel Merrifield platform the USB PHY shouldn't be suspended. Otherwise it can't be enabled by simply change the cable in the connector. Enable corresponding quirk for the platform in question. Fixes: e5f4ca3fce90 ("usb: dwc3: ulpi: Fix USB2.0 HS/FS/LS PHY suspend regression") Suggested-by: Serge Semin Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210322125244.79407-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d27639217d73419355b9b801c3b0cb54b3c20979 Author: Nathan Lynch Date: Mon Mar 15 03:00:45 2021 -0500 powerpc/pseries/mobility: handle premature return from H_JOIN [ Upstream commit 274cb1ca2e7ce02cab56f5f4c61a74aeb566f931 ] The pseries join/suspend sequence in its current form was written with the assumption that it was the only user of H_PROD and that it needn't handle spurious successful returns from H_JOIN. That's wrong; powerpc's paravirt spinlock code uses H_PROD, and CPUs entering do_join() can be woken prematurely from H_JOIN with a status of H_SUCCESS as a result. This causes all CPUs to exit the sequence early, preventing suspend from occurring at all. Add a 'done' boolean flag to the pseries_suspend_info struct, and have the waking thread set it before waking the other threads. Threads which receive H_SUCCESS from H_JOIN retry if the 'done' flag is still unset. Fixes: 9327dc0aeef3 ("powerpc/pseries/mobility: use stop_machine for join/suspend") Signed-off-by: Nathan Lynch Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210315080045.460331-3-nathanl@linux.ibm.com Signed-off-by: Sasha Levin commit 9963dfd873d1eddfba1af1657f43602eedf08ce1 Author: Nathan Lynch Date: Mon Mar 15 03:00:44 2021 -0500 powerpc/pseries/mobility: use struct for shared state [ Upstream commit e834df6cfc71d8e5ce2c27a0184145ea125c3f0f ] The atomic_t counter is the only shared state for the join/suspend sequence so far, but that will change. Contain it in a struct (pseries_suspend_info), and document its intended use. No functional change. Signed-off-by: Nathan Lynch Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210315080045.460331-2-nathanl@linux.ibm.com Signed-off-by: Sasha Levin commit bca42b2c646338c13f7f31b68468514735bfa174 Author: Richard Gong Date: Tue Feb 9 16:20:27 2021 -0600 firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0 [ Upstream commit 2e8496f31d0be8f43849b2980b069f3a9805d047 ] Clean up COMMAND_RECONFIG_FLAG_PARTIAL flag by resetting it to 0, which aligns with the firmware settings. Fixes: 36847f9e3e56 ("firmware: stratix10-svc: correct reconfig flag and timeout values") Signed-off-by: Richard Gong Reviewed-by: Tom Rix Signed-off-by: Moritz Fischer Signed-off-by: Sasha Levin commit ec8c8e7a2491c840082b155499bb55b9cfb435eb Author: Dinghao Liu Date: Tue Jan 19 16:10:55 2021 +0800 extcon: Fix error handling in extcon_dev_register [ Upstream commit d3bdd1c3140724967ca4136755538fa7c05c2b4e ] When devm_kcalloc() fails, we should execute device_unregister() to unregister edev->dev from system. Fixes: 046050f6e623e ("extcon: Update the prototype of extcon_register_notifier() with enum extcon") Signed-off-by: Dinghao Liu Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit ef523e9b6d350b328e4caf97eea5545ebdd32c89 Author: Krzysztof Kozlowski Date: Thu Dec 31 09:52:52 2020 +0100 extcon: Add stubs for extcon_register_notifier_all() functions [ Upstream commit c9570d4a5efd04479b3cd09c39b571eb031d94f4 ] Add stubs for extcon_register_notifier_all() function for !CONFIG_EXTCON case. This is useful for compile testing and for drivers which use EXTCON but do not require it (therefore do not depend on CONFIG_EXTCON). Fixes: 815429b39d94 ("extcon: Add new extcon_register_notifier_all() to monitor all external connectors") Reported-by: kernel test robot Signed-off-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 4f242e03d6afdeebbe7742c1f2b86d435fab4d55 Author: Arnd Bergmann Date: Tue Mar 23 14:17:13 2021 +0100 pinctrl: qcom: fix unintentional string concatenation commit 58b5ada8c465b5f1300bc021ebd3d3b8149124b4 upstream. clang is clearly correct to point out a typo in a silly array of strings: drivers/pinctrl/qcom/pinctrl-sdx55.c:426:61: error: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Werror,-Wstring-concatenation] "gpio14", "gpio15", "gpio16", "gpio17", "gpio18", "gpio19" "gpio20", "gpio21", "gpio22", ^ Add the missing comma that must have accidentally been removed. Fixes: ac43c44a7a37 ("pinctrl: qcom: Add SDX55 pincontrol driver") Signed-off-by: Arnd Bergmann Reviewed-by: Bjorn Andersson Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20210323131728.2702789-1-arnd@kernel.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit a9ee6fba5ac6881c33fdf200b2a572cd9793a5e9 Author: Jonathan Marek Date: Thu Mar 4 14:48:16 2021 -0500 pinctrl: qcom: lpass lpi: use default pullup/strength values commit 2a9be38099e338f597c14d3cb851849b01db05f6 upstream. If these fields are not set in dts, the driver will use these variables uninitialized to set the fields. Not only will it set garbage values for these fields, but it can overflow into other fields and break those. In the current sm8250 dts, the dmic01 entries do not have a pullup setting, and might not work without this change. Reported-by: kernel test robot Reported-by: Dan Carpenter Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver") Signed-off-by: Jonathan Marek Reviewed-by: Bjorn Andersson Reviewed-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210304194816.3843-1-jonathan@marek.ca Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 49187607efdc4f4238bf82d7befbe6c0a85471aa Author: Rajendra Nayak Date: Tue Mar 2 10:51:51 2021 +0530 pinctrl: qcom: sc7280: Fix SDC1_RCLK configurations commit d0f9f47c07fe52b34e2ff8590cf09e0a9d8d6f99 upstream. Fix SDC1_RCLK configurations which are in a different register so fix the offset from 0xb3000 to 0xb3004. Fixes: ecb454594c43: ("pinctrl: qcom: Add sc7280 pinctrl driver") Reported-by: Veerabhadrarao Badiganti Signed-off-by: Rajendra Nayak Acked-by: Bjorn Andersson Link: https://lore.kernel.org/r/1614662511-26519-2-git-send-email-rnayak@codeaurora.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit c1fd5af9397c7f1d63acc926e6517e56dbb98f90 Author: Rajendra Nayak Date: Tue Mar 2 10:51:50 2021 +0530 pinctrl: qcom: sc7280: Fix SDC_QDSD_PINGROUP and UFS_RESET offsets commit 07abd8db9358751107cc46d1cdbd44a92c76a934 upstream. The offsets for SDC_QDSD_PINGROUP and UFS_RESET were off by 0x100000 due to an issue in the scripts generating the data. Fixes: ecb454594c43: ("pinctrl: qcom: Add sc7280 pinctrl driver") Reported-by: Veerabhadrarao Badiganti Signed-off-by: Rajendra Nayak Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/1614662511-26519-1-git-send-email-rnayak@codeaurora.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 7274dd01df06e47f7c0af92d76a8203e6d094a70 Author: Wang Panzhenzhuan Date: Tue Feb 23 18:07:25 2021 +0800 pinctrl: rockchip: fix restore error in resume commit c971af25cda94afe71617790826a86253e88eab0 upstream. The restore in resume should match to suspend which only set for RK3288 SoCs pinctrl. Fixes: 8dca933127024 ("pinctrl: rockchip: save and restore gpio6_c6 pinmux in suspend/resume") Reviewed-by: Jianqun Xu Reviewed-by: Heiko Stuebner Signed-off-by: Wang Panzhenzhuan Signed-off-by: Jianqun Xu Link: https://lore.kernel.org/r/20210223100725.269240-1-jay.xu@rock-chips.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 2734474670324d5676042d2f96f05a6c2aadf345 Author: Lars Povlsen Date: Wed Feb 3 13:38:25 2021 +0100 pinctrl: microchip-sgpio: Fix wrong register offset for IRQ trigger commit 5d5f2919273d1089a00556cad68e7f462f3dd2eb upstream. This patch fixes using a wrong register offset when configuring an IRQ trigger type. Fixes: be2dc859abd4 ("pinctrl: pinctrl-microchip-sgpio: Add irq support (for sparx5)") Reported-by: Gustavo A. R. Silva Signed-off-by: Lars Povlsen Reviewed-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20210203123825.611576-1-lars.povlsen@microchip.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 7bf09c17e711ad1da30d883567c1d664565a03d9 Author: Jason Gunthorpe Date: Mon Mar 29 16:00:16 2021 -0300 vfio/nvlink: Add missing SPAPR_TCE_IOMMU depends commit e0146a108ce4d2c22b9510fd12268e3ee72a0161 upstream. Compiling the nvlink stuff relies on the SPAPR_TCE_IOMMU otherwise there are compile errors: drivers/vfio/pci/vfio_pci_nvlink2.c:101:10: error: implicit declaration of function 'mm_iommu_put' [-Werror,-Wimplicit-function-declaration] ret = mm_iommu_put(data->mm, data->mem); As PPC only defines these functions when the config is set. Previously this wasn't a problem by chance as SPAPR_TCE_IOMMU was the only IOMMU that could have satisfied IOMMU_API on POWERNV. Fixes: 179209fa1270 ("vfio: IOMMU_API should be selected") Reported-by: kernel test robot Signed-off-by: Jason Gunthorpe Message-Id: <0-v1-83dba9768fc3+419-vfio_nvlink2_kconfig_jgg@nvidia.com> Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit f3eb579f42658129dad62ead5986fdd7f590e56e Author: Thierry Reding Date: Fri Mar 19 14:17:22 2021 +0100 drm/tegra: sor: Grab runtime PM reference across reset commit ac097aecfef0bb289ca53d2fe0b73fc7e1612a05 upstream. The SOR resets are exclusively shared with the SOR power domain. This means that exclusive access can only be granted temporarily and in order for that to work, a rigorous sequence must be observed. To ensure that a single consumer gets exclusive access to a reset, each consumer must implement a rigorous protocol using the reset_control_acquire() and reset_control_release() functions. However, these functions alone don't provide any guarantees at the system level. Drivers need to ensure that the only a single consumer has access to the reset at the same time. In order for the SOR to be able to exclusively access its reset, it must therefore ensure that the SOR power domain is not powered off by holding on to a runtime PM reference to that power domain across the reset assert/deassert operation. This used to work fine by accident, but was revealed when recently more devices started to rely on the SOR power domain. Fixes: 11c632e1cfd3 ("drm/tegra: sor: Implement acquire/release for reset") Reported-by: Jonathan Hunter Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 68542bdb14fd6b5795548e3cdd69620aa3fa65ff Author: Thierry Reding Date: Fri Mar 19 08:06:37 2021 +0100 drm/tegra: dc: Restore coupling of display controllers commit a31500fe7055451ed9043c8fff938dfa6f70ee37 upstream. Coupling of display controllers used to rely on runtime PM to take the companion controller out of reset. Commit fd67e9c6ed5a ("drm/tegra: Do not implement runtime PM") accidentally broke this when runtime PM was removed. Restore this functionality by reusing the hierarchical host1x client suspend/resume infrastructure that's similar to runtime PM and which perfectly fits this use-case. Fixes: fd67e9c6ed5a ("drm/tegra: Do not implement runtime PM") Reported-by: Dmitry Osipenko Reported-by: Paul Fertser Tested-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 3f86a8e0a0247a4de7f574b37467aaa74afe68a7 Author: Pan Bian Date: Wed Jan 20 01:16:08 2021 -0800 drm/imx: fix memory leak when fails to init commit 69c3ed7282a143439bbc2d03dc00d49c68fcb629 upstream. Put DRM device on initialization failure path rather than directly return error code. Fixes: a67d5088ceb8 ("drm/imx: drop explicit drm_mode_config_cleanup") Signed-off-by: Pan Bian Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman commit 76458eb67ed509e22c46e6e80852aec849a6c194 Author: Tetsuo Handa Date: Sun Mar 21 23:37:49 2021 +0900 reiserfs: update reiserfs_xattrs_initialized() condition commit 5e46d1b78a03d52306f21f77a4e4a144b6d31486 upstream. syzbot is reporting NULL pointer dereference at reiserfs_security_init() [1], for commit ab17c4f02156c4f7 ("reiserfs: fixup xattr_root caching") is assuming that REISERFS_SB(s)->xattr_root != NULL in reiserfs_xattr_jcreate_nblocks() despite that commit made REISERFS_SB(sb)->priv_root != NULL && REISERFS_SB(s)->xattr_root == NULL case possible. I guess that commit 6cb4aff0a77cc0e6 ("reiserfs: fix oops while creating privroot with selinux enabled") wanted to check xattr_root != NULL before reiserfs_xattr_jcreate_nblocks(), for the changelog is talking about the xattr root. The issue is that while creating the privroot during mount reiserfs_security_init calls reiserfs_xattr_jcreate_nblocks which dereferences the xattr root. The xattr root doesn't exist, so we get an oops. Therefore, update reiserfs_xattrs_initialized() to check both the privroot and the xattr root. Link: https://syzkaller.appspot.com/bug?id=8abaedbdeb32c861dc5340544284167dd0e46cde # [1] Reported-and-tested-by: syzbot Signed-off-by: Tetsuo Handa Fixes: 6cb4aff0a77c ("reiserfs: fix oops while creating privroot with selinux enabled") Acked-by: Jeff Mahoney Acked-by: Jan Kara Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ca168fa359da0d87591547e2794e977c3f6e6744 Author: Xℹ Ruoyao Date: Tue Mar 30 23:33:34 2021 +0800 drm/amdgpu: check alignment on CPU page for bo map commit e3512fb67093fabdf27af303066627b921ee9bd8 upstream. The page table of AMDGPU requires an alignment to CPU page so we should check ioctl parameters for it. Return -EINVAL if some parameter is unaligned to CPU page, instead of corrupt the page table sliently. Reviewed-by: Christian König Signed-off-by: Xi Ruoyao Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 91f2477f6f0f16f59054e172638c527afe22031f Author: Huacai Chen Date: Tue Mar 30 23:33:33 2021 +0800 drm/amdgpu: Set a suitable dev_info.gart_page_size commit 566c6e25f957ebdb0b6e8073ee291049118f47fb upstream. In Mesa, dev_info.gart_page_size is used for alignment and it was set to AMDGPU_GPU_PAGE_SIZE(4KB). However, the page table of AMDGPU driver requires an alignment on CPU pages. So, for non-4KB page system, gart_page_size should be max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE). Signed-off-by: Rui Wang Signed-off-by: Huacai Chen Link: https://github.com/loongson-community/linux-stable/commit/caa9c0a1 [Xi: rebased for drm-next, use max_t for checkpatch, and reworded commit message.] Signed-off-by: Xi Ruoyao BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549 Tested-by: Dan Horák Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 28903eb893a5a3500479f9cedd4a2abaa3f82514 Author: Nirmoy Das Date: Fri Mar 26 16:08:10 2021 +0100 drm/amdgpu: fix offset calculation in amdgpu_vm_bo_clear_mappings() commit 5e61b84f9d3ddfba73091f9fbc940caae1c9eb22 upstream. Offset calculation wasn't correct as start addresses are in pfn not in bytes. CC: stable@vger.kernel.org Signed-off-by: Nirmoy Das Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit fabbabab4e62a73cde1de89a3ecc3103103eb98c Author: Alex Deucher Date: Fri Mar 26 16:56:07 2021 -0400 drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in suspend commit 6951c3e4a260f65a16433833d2511e8796dc8625 upstream. Do the same thing we do for Renoir. We can check, but since the sbios has started DPM, it will always return true which causes the driver to skip some of the SMU init when it shouldn't. Reviewed-by: Zhan Liu Acked-by: Evan Quan Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit cb300f33800942a8dd324440155fdbcf8635931a Author: Evan Quan Date: Tue Mar 23 16:30:38 2021 +0800 drm/amd/pm: no need to force MCLK to highest when no display connected commit acc7baafeb0b52a5b91be64c4776f827a163dda1 upstream. Correct the check for vblank short. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Tested-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e812976ef3e9d72013ed0ba811331f941a22e8e6 Author: Qu Huang Date: Thu Jan 28 20:14:25 2021 +0800 drm/amdkfd: dqm fence memory corruption commit e92049ae4548ba09e53eaa9c8f6964b07ea274c9 upstream. Amdgpu driver uses 4-byte data type as DQM fence memory, and transmits GPU address of fence memory to microcode through query status PM4 message. However, query status PM4 message definition and microcode processing are all processed according to 8 bytes. Fence memory only allocates 4 bytes of memory, but microcode does write 8 bytes of memory, so there is a memory corruption. Changes since v1: * Change dqm->fence_addr as a u64 pointer to fix this issue, also fix up query_status and amdkfd_fence_wait_timeout function uses 64 bit fence value to make them consistent. Signed-off-by: Qu Huang Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ce292c9ad1bc837b82608d432855289ca01b1fb6 Author: Ilya Lipnitskiy Date: Mon Mar 29 21:42:08 2021 -0700 mm: fix race by making init_zero_pfn() early_initcall commit e720e7d0e983bf05de80b231bccc39f1487f0f16 upstream. There are code paths that rely on zero_pfn to be fully initialized before core_initcall. For example, wq_sysfs_init() is a core_initcall function that eventually results in a call to kernel_execve, which causes a page fault with a subsequent mmput. If zero_pfn is not initialized by then it may not get cleaned up properly and result in an error: BUG: Bad rss-counter state mm:(ptrval) type:MM_ANONPAGES val:1 Here is an analysis of the race as seen on a MIPS device. On this particular MT7621 device (Ubiquiti ER-X), zero_pfn is PFN 0 until initialized, at which point it becomes PFN 5120: 1. wq_sysfs_init calls into kobject_uevent_env at core_initcall: kobject_uevent_env+0x7e4/0x7ec kset_register+0x68/0x88 bus_register+0xdc/0x34c subsys_virtual_register+0x34/0x78 wq_sysfs_init+0x1c/0x4c do_one_initcall+0x50/0x1a8 kernel_init_freeable+0x230/0x2c8 kernel_init+0x10/0x100 ret_from_kernel_thread+0x14/0x1c 2. kobject_uevent_env() calls call_usermodehelper_exec() which executes kernel_execve asynchronously. 3. Memory allocations in kernel_execve cause a page fault, bumping the MM reference counter: add_mm_counter_fast+0xb4/0xc0 handle_mm_fault+0x6e4/0xea0 __get_user_pages.part.78+0x190/0x37c __get_user_pages_remote+0x128/0x360 get_arg_page+0x34/0xa0 copy_string_kernel+0x194/0x2a4 kernel_execve+0x11c/0x298 call_usermodehelper_exec_async+0x114/0x194 4. In case zero_pfn has not been initialized yet, zap_pte_range does not decrement the MM_ANONPAGES RSS counter and the BUG message is triggered shortly afterwards when __mmdrop checks the ref counters: __mmdrop+0x98/0x1d0 free_bprm+0x44/0x118 kernel_execve+0x160/0x1d8 call_usermodehelper_exec_async+0x114/0x194 ret_from_kernel_thread+0x14/0x1c To avoid races such as described above, initialize init_zero_pfn at early_initcall level. Depending on the architecture, ZERO_PAGE is either constant or gets initialized even earlier, at paging_init, so there is no issue with initializing zero_pfn earlier. Link: https://lkml.kernel.org/r/CALCv0x2YqOXEAy2Q=hafjhHCtTHVodChv1qpM=niAXOpqEbt7w@mail.gmail.com Signed-off-by: Ilya Lipnitskiy Cc: Hugh Dickins Cc: "Eric W. Biederman" Cc: stable@vger.kernel.org Tested-by: 周琰杰 (Zhou Yanjie) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8ab963bac5e82924351a2c73f61997b2a08c5ba0 Author: Christian König Date: Fri Mar 12 09:34:39 2021 +0100 drm/ttm: make ttm_bo_unpin more defensive commit 6c5403173a13a08ff61dbdafa4c0ed4a9dedbfe0 upstream. We seem to have some more driver bugs than thought. Signed-off-by: Christian König Fixes: deb0814b43f3 ("drm/ttm: add ttm_bo_pin()/ttm_bo_unpin() v2") Acked-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20210312093810.2202-1-christian.koenig@amd.com Signed-off-by: Greg Kroah-Hartman commit 359841c0f04f72e3134f1b532cc42e5d667cd751 Author: Heiko Carstens Date: Wed Mar 24 20:22:42 2021 +0100 s390/vdso: fix tod_steering_delta type commit b24bacd67ffddd9192c4745500fd6f73dbfe565e upstream. The s390 specific vdso function __arch_get_hw_counter() is supposed to consider tod clock steering. If a tod clock steering event happens and the tod clock is set to a new value __arch_get_hw_counter() will not return the real tod clock value but slowly drift it from the old delta until the returned value finally matches the real tod clock value again. Unfortunately the type of tod_steering_delta unsigned while it is supposed to be signed. It depends on if tod_steering_delta is negative or positive in which direction the vdso code drifts the clock value. Worst case is now that instead of drifting the clock slowly it will jump into the opposite direction by a factor of two. Fix this by simply making tod_steering_delta signed. Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO") Cc: # 5.10 Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit c983f0b4f7842ffee387390783e2fecb5a0f9f96 Author: Heiko Carstens Date: Tue Mar 23 21:40:11 2021 +0100 s390/vdso: copy tod_steering_delta value to vdso_data page commit 72bbc226ed2ef0a46c165a482861fff00dd6d4e1 upstream. When converting the vdso assembler code to C it was forgotten to actually copy the tod_steering_delta value to vdso_data page. Which in turn means that tod clock steering will not work correctly. Fix this by simply copying the value whenever it is updated. Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO") Cc: # 5.10 Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 9a48524bd099214b7d6dd98a5e234dd6e24f9810 Author: Steven Rostedt (VMware) Date: Thu Apr 1 13:54:40 2021 -0400 tracing: Fix stack trace event size commit 9deb193af69d3fd6dd8e47f292b67c805a787010 upstream. Commit cbc3b92ce037 fixed an issue to modify the macros of the stack trace event so that user space could parse it properly. Originally the stack trace format to user space showed that the called stack was a dynamic array. But it is not actually a dynamic array, in the way that other dynamic event arrays worked, and this broke user space parsing for it. The update was to make the array look to have 8 entries in it. Helper functions were added to make it parse it correctly, as the stack was dynamic, but was determined by the size of the event stored. Although this fixed user space on how it read the event, it changed the internal structure used for the stack trace event. It changed the array size from [0] to [8] (added 8 entries). This increased the size of the stack trace event by 8 words. The size reserved on the ring buffer was the size of the stack trace event plus the number of stack entries found in the stack trace. That commit caused the amount to be 8 more than what was needed because it did not expect the caller field to have any size. This produced 8 entries of garbage (and reading random data) from the stack trace event: -0 [002] d... 1976396.837549: => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify => 0xc8c5e150ffff93de => 0xffff93de => 0 => 0 => 0xc8c5e17800000000 => 0x1f30affff93de => 0x00000004 => 0x200000000 Instead, subtract the size of the caller field from the size of the event to make sure that only the amount needed to store the stack trace is reserved. Link: https://lore.kernel.org/lkml/your-ad-here.call-01617191565-ext-9692@work.hours/ Cc: stable@vger.kernel.org Fixes: cbc3b92ce037 ("tracing: Set kernel_stack's caller size properly") Reported-by: Vasily Gorbik Tested-by: Vasily Gorbik Acked-by: Vasily Gorbik Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit d0c537873218929667526ecd2a335843f3b4d897 Author: Adrian Hunter Date: Fri Mar 26 12:56:18 2021 +0200 PM: runtime: Fix ordering in pm_runtime_get_suppliers() commit c0c33442f7203704aef345647e14c2fb86071001 upstream. rpm_active indicates how many times the supplier usage_count has been incremented. Consequently it must be updated after pm_runtime_get_sync() of the supplier, not before. Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance") Signed-off-by: Adrian Hunter Cc: 5.1+ # 5.1+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 2a59577a9d9e70d40f78bd61f9186cd4defac280 Author: Adrian Hunter Date: Fri Mar 26 12:56:19 2021 +0200 PM: runtime: Fix race getting/putting suppliers at probe commit 9dfacc54a8661bc8be6e08cffee59596ec59f263 upstream. pm_runtime_put_suppliers() must not decrement rpm_active unless the consumer is suspended. That is because, otherwise, it could suspend suppliers for an active consumer. That can happen as follows: static int driver_probe_device(struct device_driver *drv, struct device *dev) { int ret = 0; if (!device_is_registered(dev)) return -ENODEV; dev->can_match = true; pr_debug("bus: '%s': %s: matched device %s with driver %s\n", drv->bus->name, __func__, dev_name(dev), drv->name); pm_runtime_get_suppliers(dev); if (dev->parent) pm_runtime_get_sync(dev->parent); At this point, dev can runtime suspend so rpm_put_suppliers() can run, rpm_active becomes 1 (the lowest value). pm_runtime_barrier(dev); if (initcall_debug) ret = really_probe_debug(dev, drv); else ret = really_probe(dev, drv); Probe callback can have runtime resumed dev, and then runtime put so dev is awaiting autosuspend, but rpm_active is 2. pm_request_idle(dev); if (dev->parent) pm_runtime_put(dev->parent); pm_runtime_put_suppliers(dev); Now pm_runtime_put_suppliers() will put the supplier i.e. rpm_active 2 -> 1, but consumer can still be active. return ret; } Fix by checking the runtime status. For any status other than RPM_SUSPENDED, rpm_active can be considered to be "owned" by rpm_[get/put]_suppliers() and pm_runtime_put_suppliers() need do nothing. Reported-by: Asutosh Das Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance") Signed-off-by: Adrian Hunter Cc: 5.1+ # 5.1+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit efb56c5a3211e4ea8cc34dc1fee2d7bb3a56bd59 Author: Paolo Bonzini Date: Wed Mar 31 06:28:01 2021 -0400 KVM: SVM: ensure that EFER.SVME is set when running nested guest or on nested vmexit commit 3c346c0c60ab06a021d1c0884a0ef494bc4ee3a7 upstream. Fixing nested_vmcb_check_save to avoid all TOC/TOU races is a bit harder in released kernels, so do the bare minimum by avoiding that EFER.SVME is cleared. This is problematic because svm_set_efer frees the data structures for nested virtualization if EFER.SVME is cleared. Also check that EFER.SVME remains set after a nested vmexit; clearing it could happen if the bit is zero in the save area that is passed to KVM_SET_NESTED_STATE (the save area of the nested state corresponds to the nested hypervisor's state and is restored on the next nested vmexit). Cc: stable@vger.kernel.org Fixes: 2fcf4876ada ("KVM: nSVM: implement on demand allocation of the nested state") Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c90804920978faba6b5fa91e82edc58e5ffd7d30 Author: Paolo Bonzini Date: Wed Mar 31 06:24:43 2021 -0400 KVM: SVM: load control fields from VMCB12 before checking them commit a58d9166a756a0f4a6618e4f593232593d6df134 upstream. Avoid races between check and use of the nested VMCB controls. This for example ensures that the VMRUN intercept is always reflected to the nested hypervisor, instead of being processed by the host. Without this patch, it is possible to end up with svm->nested.hsave pointing to the MSR permission bitmap for nested guests. This bug is CVE-2021-29657. Reported-by: Felix Wilhelm Cc: stable@vger.kernel.org Fixes: 2fcf4876ada ("KVM: nSVM: implement on demand allocation of the nested state") Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5905a127d1fcfaf88d4c7023614df66f651445d6 Author: Max Filippov Date: Thu Feb 25 11:42:46 2021 -0800 xtensa: move coprocessor_flush to the .text section commit ab5eb336411f18fd449a1fb37d36a55ec422603f upstream. coprocessor_flush is not a part of fast exception handlers, but it uses parts of fast coprocessor handling code that's why it's in the same source file. It uses call0 opcode to invoke those parts so there are no limitations on their relative location, but the rest of the code calls coprocessor_flush with call8 and that doesn't work when vectors are placed in a different gigabyte-aligned area than the rest of the kernel. Move coprocessor_flush from the .exception.text section to the .text so that it's reachable from the rest of the kernel with call8. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit dfb1cbe10d6778759a4cd081f2585868140f058f Author: Max Filippov Date: Sun Feb 7 04:57:58 2021 -0800 xtensa: fix uaccess-related livelock in do_page_fault commit 7b9acbb6aad4f54623dcd4bd4b1a60fe0c727b09 upstream. If a uaccess (e.g. get_user()) triggers a fault and there's a fault signal pending, the handler will return to the uaccess without having performed a uaccess fault fixup, and so the CPU will immediately execute the uaccess instruction again, whereupon it will livelock bouncing between that instruction and the fault handler. https://lore.kernel.org/lkml/20210121123140.GD48431@C02TD0UTHF1T.local/ Cc: stable@vger.kernel.org Reported-by: Mark Rutland Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit c8b157ed13075031802909eda1388b0519c6d246 Author: Jeremy Szu Date: Tue Mar 30 19:44:27 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs for HP 640 G8 commit 417eadfdd9e25188465280edf3668ed163fda2d0 upstream. The HP EliteBook 640 G8 Notebook PC is using ALC236 codec which is using 0x02 to control mute LED and 0x01 to control micmute LED. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20210330114428.40490-1-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 179029edb5fa21e671f82a813588cf3d240e460f Author: Hui Wang Date: Sat Mar 20 17:15:42 2021 +0800 ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook commit e54f30befa7990b897189b44a56c1138c6bfdbb5 upstream. We found the alc_update_headset_mode() is not called on some machines when unplugging the headset, as a result, the mode of the ALC_HEADSET_MODE_UNPLUGGED can't be set, then the current_headset_type is not cleared, if users plug a differnt type of headset next time, the determine_headset_type() will not be called and the audio jack is set to the headset type of previous time. On the Dell machines which connect the dmic to the PCH, if we open the gnome-sound-setting and unplug the headset, this issue will happen. Those machines disable the auto-mute by ucm and has no internal mic in the input source, so the update_headset_mode() will not be called by cap_sync_hook or automute_hook when unplugging, and because the gnome-sound-setting is opened, the codec will not enter the runtime_suspend state, so the update_headset_mode() will not be called by alc_resume when unplugging. In this case the hp_automute_hook is called when unplugging, so add update_headset_mode() calling to this function. Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20210320091542.6748-2-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7ad4bd2c87a38610d357a8bc8d0249acce09adff Author: Hui Wang Date: Sat Mar 20 17:15:41 2021 +0800 ALSA: hda/realtek: fix a determine_headset_type issue for a Dell AIO commit febf22565549ea7111e7d45e8f2d64373cc66b11 upstream. We found a recording issue on a Dell AIO, users plug a headset-mic and select headset-mic from UI, but can't record any sound from headset-mic. The root cause is the determine_headset_type() returns a wrong type, e.g. users plug a ctia type headset, but that function returns omtp type. On this machine, the internal mic is not connected to the codec, the "Input Source" is headset mic by default. And when users plug a headset, the determine_headset_type() will be called immediately, the codec on this AIO is alc274, the delay time for this codec in the determine_headset_type() is only 80ms, the delay is too short to correctly determine the headset type, the fail rate is nearly 99% when users plug the headset with the normal speed. Other codecs set several hundred ms delay time, so here I change the delay time to 850ms for alc2x4 series, after this change, the fail rate is zero unless users plug the headset slowly on purpose. Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20210320091542.6748-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 74cecb7b1ee908e1070aa0e7503f2bfc570607d6 Author: Takashi Iwai Date: Mon Mar 29 13:30:59 2021 +0200 ALSA: hda: Add missing sanity checks in PM prepare/complete callbacks commit 66affb7bb0dc0905155a1b2475261aa704d1ddb5 upstream. The recently added PM prepare and complete callbacks don't have the sanity check whether the card instance has been properly initialized, which may potentially lead to Oops. This patch adds the azx_is_pm_ready() call in each place appropriately like other PM callbacks. Fixes: f5dac54d9d93 ("ALSA: hda: Separate runtime and system suspend") Cc: Link: https://lore.kernel.org/r/20210329113059.25035-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 216d853084b98821dabd65cf68aed7747a59b220 Author: Takashi Iwai Date: Mon Mar 29 13:30:58 2021 +0200 ALSA: hda: Re-add dropped snd_poewr_change_state() calls commit c8f79808cd8eb5bc8d14de129bd6d586d3fce0aa upstream. The card power state change via snd_power_change_state() at the system suspend/resume seems dropped mistakenly during the PM code rewrite. The card power state doesn't play much role nowadays but it's still referred in a few places such as the HDMI codec driver. This patch restores them, but in a more appropriate place now in the prepare and complete callbacks. Fixes: f5dac54d9d93 ("ALSA: hda: Separate runtime and system suspend") Cc: Link: https://lore.kernel.org/r/20210329113059.25035-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b1ad37b3a6916ee9c4397c83624a6d36eef51464 Author: Ikjoon Jang Date: Wed Mar 24 18:51:52 2021 +0800 ALSA: usb-audio: Apply sample rate quirk to Logitech Connect commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream. Logitech ConferenceCam Connect is a compound USB device with UVC and UAC. Not 100% reproducible but sometimes it keeps responding STALL to every control transfer once it receives get_freq request. This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419 Signed-off-by: Ikjoon Jang Cc: Link: https://lore.kernel.org/r/20210324105153.2322881-1-ikjn@chromium.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 440b4aa514ccab651d0a1ac1ea1b1ccac79719e9 Author: Hans de Goede Date: Tue Mar 30 20:49:32 2021 +0200 ACPI: scan: Fix _STA getting called on devices with unmet dependencies commit 3e759425cc3cf9a43392309819d34c65a3644c59 upstream. Commit 71da201f38df ("ACPI: scan: Defer enumeration of devices with _DEP lists") dropped the following 2 lines from acpi_init_device_object(): /* Assume there are unmet deps until acpi_device_dep_initialize() runs */ device->dep_unmet = 1; Leaving the initial value of dep_unmet at the 0 from the kzalloc(). This causes the acpi_bus_get_status() call in acpi_add_single_object() to actually call _STA, even though there maybe unmet deps, leading to errors like these: [ 0.123579] ACPI Error: No handler for Region [ECRM] (00000000ba9edc4c) [GenericSerialBus] (20170831/evregion-166) [ 0.123601] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20170831/exfldio-299) [ 0.123618] ACPI Error: Method parse/execution failed \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550) Fix this by re-adding the dep_unmet = 1 initialization to acpi_init_device_object() and modifying acpi_bus_check_add() to make sure that dep_unmet always gets setup there, overriding the initial 1 value. This re-fixes the issue initially fixed by commit 63347db0affa ("ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devs"), which introduced the removed "device->dep_unmet = 1;" statement. This issue was noticed; and the fix tested on a Dell Venue 10 Pro 5055. Fixes: 71da201f38df ("ACPI: scan: Defer enumeration of devices with _DEP lists") Suggested-by: Rafael J. Wysocki Signed-off-by: Hans de Goede Cc: 5.11+ # 5.11+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit da38248486d02ea40eedc74c4e0040b98c3c599c Author: Vitaly Kuznetsov Date: Wed Mar 24 16:22:19 2021 +0100 ACPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead() commit 8cdddd182bd7befae6af49c5fd612893f55d6ccb upstream. Commit 496121c02127 ("ACPI: processor: idle: Allow probing on platforms with one ACPI C-state") broke CPU0 hotplug on certain systems, e.g. I'm observing the following on AWS Nitro (e.g r5b.xlarge but other instance types are affected as well): # echo 0 > /sys/devices/system/cpu/cpu0/online # echo 1 > /sys/devices/system/cpu/cpu0/online <10 seconds delay> -bash: echo: write error: Input/output error In fact, the above mentioned commit only revealed the problem and did not introduce it. On x86, to wakeup CPU an NMI is being used and hlt_play_dead()/mwait_play_dead() loops are prepared to handle it: /* * If NMI wants to wake up CPU0, start CPU0. */ if (wakeup_cpu0()) start_cpu0(); cpuidle_play_dead() -> acpi_idle_play_dead() (which is now being called on systems where it wasn't called before the above mentioned commit) serves the same purpose but it doesn't have a path for CPU0. What happens now on wakeup is: - NMI is sent to CPU0 - wakeup_cpu0_nmi() works as expected - we get back to while (1) loop in acpi_idle_play_dead() - safe_halt() puts CPU0 to sleep again. The straightforward/minimal fix is add the special handling for CPU0 on x86 and that's what the patch is doing. Fixes: 496121c02127 ("ACPI: processor: idle: Allow probing on platforms with one ACPI C-state") Signed-off-by: Vitaly Kuznetsov Cc: 5.10+ # 5.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 060aed762992a73c5d878b5bb63232fb561a68b0 Author: Rafael J. Wysocki Date: Tue Mar 23 20:26:52 2021 +0100 ACPI: tables: x86: Reserve memory occupied by ACPI tables commit 1a1c130ab7575498eed5bcf7220037ae09cd1f8a upstream. The following problem has been reported by George Kennedy: Since commit 7fef431be9c9 ("mm/page_alloc: place pages to tail in __free_pages_core()") the following use after free occurs intermittently when ACPI tables are accessed. BUG: KASAN: use-after-free in ibft_init+0x134/0xc49 Read of size 4 at addr ffff8880be453004 by task swapper/0/1 CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1-7a7fd0d #1 Call Trace: dump_stack+0xf6/0x158 print_address_description.constprop.9+0x41/0x60 kasan_report.cold.14+0x7b/0xd4 __asan_report_load_n_noabort+0xf/0x20 ibft_init+0x134/0xc49 do_one_initcall+0xc4/0x3e0 kernel_init_freeable+0x5af/0x66b kernel_init+0x16/0x1d0 ret_from_fork+0x22/0x30 ACPI tables mapped via kmap() do not have their mapped pages reserved and the pages can be "stolen" by the buddy allocator. Apparently, on the affected system, the ACPI table in question is not located in "reserved" memory, like ACPI NVS or ACPI Data, that will not be used by the buddy allocator, so the memory occupied by that table has to be explicitly reserved to prevent the buddy allocator from using it. In order to address this problem, rearrange the initialization of the ACPI tables on x86 to locate the initial tables earlier and reserve the memory occupied by them. The other architectures using ACPI should not be affected by this change. Link: https://lore.kernel.org/linux-acpi/1614802160-29362-1-git-send-email-george.kennedy@oracle.com/ Reported-by: George Kennedy Tested-by: George Kennedy Signed-off-by: Rafael J. Wysocki Reviewed-by: Mike Rapoport Cc: 5.10+ # 5.10+ Signed-off-by: Greg Kroah-Hartman commit 70e923f30e0c07cf6335e0875dbcd1bd83d14fd7 Author: Jesper Dangaard Brouer Date: Tue Feb 9 14:38:09 2021 +0100 bpf: Remove MTU check in __bpf_skb_max_len commit 6306c1189e77a513bf02720450bb43bd4ba5d8ae upstream. Multiple BPF-helpers that can manipulate/increase the size of the SKB uses __bpf_skb_max_len() as the max-length. This function limit size against the current net_device MTU (skb->dev->mtu). When a BPF-prog grow the packet size, then it should not be limited to the MTU. The MTU is a transmit limitation, and software receiving this packet should be allowed to increase the size. Further more, current MTU check in __bpf_skb_max_len uses the MTU from ingress/current net_device, which in case of redirects uses the wrong net_device. This patch keeps a sanity max limit of SKB_MAX_ALLOC (16KiB). The real limit is elsewhere in the system. Jesper's testing[1] showed it was not possible to exceed 8KiB when expanding the SKB size via BPF-helper. The limiting factor is the define KMALLOC_MAX_CACHE_SIZE which is 8192 for SLUB-allocator (CONFIG_SLUB) in-case PAGE_SIZE is 4096. This define is in-effect due to this being called from softirq context see code __gfp_pfmemalloc_flags() and __do_kmalloc_node(). Jakub's testing showed that frames above 16KiB can cause NICs to reset (but not crash). Keep this sanity limit at this level as memory layer can differ based on kernel config. [1] https://github.com/xdp-project/bpf-examples/tree/master/MTU-tests Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/161287788936.790810.2937823995775097177.stgit@firesoul Signed-off-by: Greg Kroah-Hartman commit db49a8ac4e99fb7bb41964701335c281cff0e1e4 Author: Jisheng Zhang Date: Tue Mar 2 17:19:32 2021 +0800 net: 9p: advance iov on empty read [ Upstream commit d65614a01d24704b016635abf5cc028a54e45a62 ] I met below warning when cating a small size(about 80bytes) txt file on 9pfs(msize=2097152 is passed to 9p mount option), the reason is we miss iov_iter_advance() if the read count is 0 for zerocopy case, so we didn't truncate the pipe, then iov_iter_pipe() thinks the pipe is full. Fix it by removing the exception for 0 to ensure to call iov_iter_advance() even on empty read for zerocopy case. [ 8.279568] WARNING: CPU: 0 PID: 39 at lib/iov_iter.c:1203 iov_iter_pipe+0x31/0x40 [ 8.280028] Modules linked in: [ 8.280561] CPU: 0 PID: 39 Comm: cat Not tainted 5.11.0+ #6 [ 8.281260] RIP: 0010:iov_iter_pipe+0x31/0x40 [ 8.281974] Code: 2b 42 54 39 42 5c 76 22 c7 07 20 00 00 00 48 89 57 18 8b 42 50 48 c7 47 08 b [ 8.283169] RSP: 0018:ffff888000cbbd80 EFLAGS: 00000246 [ 8.283512] RAX: 0000000000000010 RBX: ffff888000117d00 RCX: 0000000000000000 [ 8.283876] RDX: ffff88800031d600 RSI: 0000000000000000 RDI: ffff888000cbbd90 [ 8.284244] RBP: ffff888000cbbe38 R08: 0000000000000000 R09: ffff8880008d2058 [ 8.284605] R10: 0000000000000002 R11: ffff888000375510 R12: 0000000000000050 [ 8.284964] R13: ffff888000cbbe80 R14: 0000000000000050 R15: ffff88800031d600 [ 8.285439] FS: 00007f24fd8af600(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 8.285844] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.286150] CR2: 00007f24fd7d7b90 CR3: 0000000000c97000 CR4: 00000000000406b0 [ 8.286710] Call Trace: [ 8.288279] generic_file_splice_read+0x31/0x1a0 [ 8.289273] ? do_splice_to+0x2f/0x90 [ 8.289511] splice_direct_to_actor+0xcc/0x220 [ 8.289788] ? pipe_to_sendpage+0xa0/0xa0 [ 8.290052] do_splice_direct+0x8b/0xd0 [ 8.290314] do_sendfile+0x1ad/0x470 [ 8.290576] do_syscall_64+0x2d/0x40 [ 8.290818] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 8.291409] RIP: 0033:0x7f24fd7dca0a [ 8.292511] Code: c3 0f 1f 80 00 00 00 00 4c 89 d2 4c 89 c6 e9 bd fd ff ff 0f 1f 44 00 00 31 8 [ 8.293360] RSP: 002b:00007ffc20932818 EFLAGS: 00000206 ORIG_RAX: 0000000000000028 [ 8.293800] RAX: ffffffffffffffda RBX: 0000000001000000 RCX: 00007f24fd7dca0a [ 8.294153] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001 [ 8.294504] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 [ 8.294867] R10: 0000000001000000 R11: 0000000000000206 R12: 0000000000000003 [ 8.295217] R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000 [ 8.295782] ---[ end trace 63317af81b3ca24b ]--- Signed-off-by: Jisheng Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2f4b1d9a8cd2822c406dc49482dc55e6ba7ea7d7 Author: Tong Zhang Date: Mon Feb 15 14:17:56 2021 -0500 net: wan/lmc: unregister device when no matching device is found [ Upstream commit 62e69bc419772638369eff8ff81340bde8aceb61 ] lmc set sc->lmc_media pointer when there is a matching device. However, when no matching device is found, this pointer is NULL and the following dereference will result in a null-ptr-deref. To fix this issue, unregister the hdlc device and return an error. [ 4.569359] BUG: KASAN: null-ptr-deref in lmc_init_one.cold+0x2b6/0x55d [lmc] [ 4.569748] Read of size 8 at addr 0000000000000008 by task modprobe/95 [ 4.570102] [ 4.570187] CPU: 0 PID: 95 Comm: modprobe Not tainted 5.11.0-rc7 #94 [ 4.570527] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-preb4 [ 4.571125] Call Trace: [ 4.571261] dump_stack+0x7d/0xa3 [ 4.571445] kasan_report.cold+0x10c/0x10e [ 4.571667] ? lmc_init_one.cold+0x2b6/0x55d [lmc] [ 4.571932] lmc_init_one.cold+0x2b6/0x55d [lmc] [ 4.572186] ? lmc_mii_readreg+0xa0/0xa0 [lmc] [ 4.572432] local_pci_probe+0x6f/0xb0 [ 4.572639] pci_device_probe+0x171/0x240 [ 4.572857] ? pci_device_remove+0xe0/0xe0 [ 4.573080] ? kernfs_create_link+0xb6/0x110 [ 4.573315] ? sysfs_do_create_link_sd.isra.0+0x76/0xe0 [ 4.573598] really_probe+0x161/0x420 [ 4.573799] driver_probe_device+0x6d/0xd0 [ 4.574022] device_driver_attach+0x82/0x90 [ 4.574249] ? device_driver_attach+0x90/0x90 [ 4.574485] __driver_attach+0x60/0x100 [ 4.574694] ? device_driver_attach+0x90/0x90 [ 4.574931] bus_for_each_dev+0xe1/0x140 [ 4.575146] ? subsys_dev_iter_exit+0x10/0x10 [ 4.575387] ? klist_node_init+0x61/0x80 [ 4.575602] bus_add_driver+0x254/0x2a0 [ 4.575812] driver_register+0xd3/0x150 [ 4.576021] ? 0xffffffffc0018000 [ 4.576202] do_one_initcall+0x84/0x250 [ 4.576411] ? trace_event_raw_event_initcall_finish+0x150/0x150 [ 4.576733] ? unpoison_range+0xf/0x30 [ 4.576938] ? ____kasan_kmalloc.constprop.0+0x84/0xa0 [ 4.577219] ? unpoison_range+0xf/0x30 [ 4.577423] ? unpoison_range+0xf/0x30 [ 4.577628] do_init_module+0xf8/0x350 [ 4.577833] load_module+0x3fe6/0x4340 [ 4.578038] ? vm_unmap_ram+0x1d0/0x1d0 [ 4.578247] ? ____kasan_kmalloc.constprop.0+0x84/0xa0 [ 4.578526] ? module_frob_arch_sections+0x20/0x20 [ 4.578787] ? __do_sys_finit_module+0x108/0x170 [ 4.579037] __do_sys_finit_module+0x108/0x170 [ 4.579278] ? __ia32_sys_init_module+0x40/0x40 [ 4.579523] ? file_open_root+0x200/0x200 [ 4.579742] ? do_sys_open+0x85/0xe0 [ 4.579938] ? filp_open+0x50/0x50 [ 4.580125] ? exit_to_user_mode_prepare+0xfc/0x130 [ 4.580390] do_syscall_64+0x33/0x40 [ 4.580586] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 4.580859] RIP: 0033:0x7f1a724c3cf7 [ 4.581054] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d6 48 891 [ 4.582043] RSP: 002b:00007fff44941c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 4.582447] RAX: ffffffffffffffda RBX: 00000000012ada70 RCX: 00007f1a724c3cf7 [ 4.582827] RDX: 0000000000000000 RSI: 00000000012ac9e0 RDI: 0000000000000003 [ 4.583207] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000001 [ 4.583587] R10: 00007f1a72527300 R11: 0000000000000246 R12: 00000000012ac9e0 [ 4.583968] R13: 0000000000000000 R14: 00000000012acc90 R15: 0000000000000001 [ 4.584349] ================================================================== Signed-off-by: Tong Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bf30fa1028276476773a6ae8528ac981d9389e4c Author: Alex Elder Date: Fri Feb 12 08:34:00 2021 -0600 net: ipa: fix register write command validation [ Upstream commit 2d65ed76924bc772d3974b0894d870b1aa63b34a ] In ipa_cmd_register_write_valid() we verify that values we will supply to a REGISTER_WRITE IPA immediate command will fit in the fields that need to hold them. This patch fixes some issues in that function and ipa_cmd_register_write_offset_valid(). The dev_err() call in ipa_cmd_register_write_offset_valid() has some printf format errors: - The name of the register (corresponding to the string format specifier) was not supplied. - The IPA base offset and offset need to be supplied separately to match the other format specifiers. Also make the ~0 constant used there to compute the maximum supported offset value explicitly unsigned. There are two other issues in ipa_cmd_register_write_valid(): - There's no need to check the hash flush register for platforms (like IPA v4.2) that do not support hashed tables - The highest possible endpoint number, whose status register offset is computed, is COUNT - 1, not COUNT. Fix these problems, and add some additional commentary. Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 48570abd72231404f6e3233548f4c253022bcaa3 Author: Alex Elder Date: Fri Feb 12 08:33:58 2021 -0600 net: ipa: use a separate pointer for adjusted GSI memory [ Upstream commit 571b1e7e58ad30b3a842254aea50d2e83b2396e1 ] This patch actually fixes a bug, though it doesn't affect the two platforms supported currently. The fix implements GSI memory pointers a bit differently. For IPA version 4.5 and above, the address space for almost all GSI registers is adjusted downward by a fixed amount. This is currently handled by adjusting the I/O virtual address pointer after it has been mapped. The bug is that the pointer is not "de-adjusted" as it should be when it's unmapped. This patch fixes that error, but it does so by maintaining one "raw" pointer for the mapped memory range. This is assigned when the memory is mapped and used to unmap the memory. This pointer is also used to access the two registers that do *not* sit in the "adjusted" memory space. Rather than adjusting *that* pointer, we maintain a separate pointer that's an adjusted copy of the "raw" pointer, and that is used for most GSI register accesses. Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6cd491c019c6f267351126b7a62442826b950001 Author: Alex Elder Date: Fri Feb 5 16:10:57 2021 -0600 net: ipa: remove two unused register definitions [ Upstream commit d5bc5015eb9d64cbd14e467db1a56db1472d0d6c ] We do not support inter-EE channel or event ring commands. Inter-EE interrupts are disabled (and never re-enabled) for all channels and event rings, so we have no need for the GSI registers that clear those interrupt conditions. So remove their definitions. Signed-off-by: Alex Elder Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b9780369ae6564df343cb7d40d18f727d45e3fff Author: Doug Brown Date: Thu Feb 11 21:27:54 2021 -0800 appletalk: Fix skb allocation size in loopback case [ Upstream commit 39935dccb21c60f9bbf1bb72d22ab6fd14ae7705 ] If a DDP broadcast packet is sent out to a non-gateway target, it is also looped back. There is a potential for the loopback device to have a longer hardware header length than the original target route's device, which can result in the skb not being created with enough room for the loopback device's hardware header. This patch fixes the issue by determining that a loopback will be necessary prior to allocating the skb, and if so, ensuring the skb has enough room. This was discovered while testing a new driver that creates a LocalTalk network interface (LTALK_HLEN = 1). It caused an skb_under_panic. Signed-off-by: Doug Brown Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e10999a0212ce5cbdba29c8f7f8e81e8d2e77196 Author: Nathan Rossi Date: Thu Feb 11 05:17:57 2021 +0000 net: ethernet: aquantia: Handle error cleanup of start on open [ Upstream commit 8a28af7a3e85ddf358f8c41e401a33002f7a9587 ] The aq_nic_start function can fail in a variety of cases which leaves the device in broken state. An example case where the start function fails is the request_threaded_irq which can be interrupted, resulting in a EINTR result. This can be manually triggered by bringing the link up (e.g. ip link set up) and triggering a SIGINT on the initiating process (e.g. Ctrl+C). This would put the device into a half configured state. Subsequently bringing the link up again would cause the napi_enable to BUG. In order to correctly clean up the failed attempt to start a device call aq_nic_stop. Signed-off-by: Nathan Rossi Reviewed-by: Igor Russkikh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cce51ee88fb2bfc12df8faa112ebd1cb6f470693 Author: Shuah Khan Date: Wed Feb 10 14:21:07 2021 -0700 ath10k: hold RCU lock when calling ieee80211_find_sta_by_ifaddr() [ Upstream commit 09078368d516918666a0122f2533dc73676d3d7e ] ieee80211_find_sta_by_ifaddr() must be called under the RCU lock and the resulting pointer is only valid under RCU lock as well. Fix ath10k_wmi_tlv_op_pull_peer_stats_info() to hold RCU lock before it calls ieee80211_find_sta_by_ifaddr() and release it when the resulting pointer is no longer needed. This problem was found while reviewing code to debug RCU warn from ath10k_wmi_tlv_parse_peer_stats_info(). Link: https://lore.kernel.org/linux-wireless/7230c9e5-2632-b77e-c4f9-10eca557a5bb@linuxfoundation.org/ Signed-off-by: Shuah Khan Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210210212107.40373-1-skhan@linuxfoundation.org Signed-off-by: Sasha Levin commit 6159f947fb047fd8ecbfbcbcc86a8337e801bd10 Author: Johannes Berg Date: Wed Feb 10 13:56:27 2021 +0200 iwlwifi: pcie: don't disable interrupts for reg_lock [ Upstream commit 874020f8adce535cd318af1768ffe744251b6593 ] The only thing we do touching the device in hard interrupt context is, at most, writing an interrupt ACK register, which isn't racing in with anything protected by the reg_lock. Thus, avoid disabling interrupts here for potentially long periods of time, particularly long periods have been observed with dumping of firmware memory (leading to lockup warnings on some devices.) Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210210135352.da916ab91298.I064c3e7823b616647293ed97da98edefb9ce9435@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit cc7e97e1c4b4d201930d3f34ee1fd38e795b4682 Author: Ido Schimmel Date: Sun Feb 7 10:22:55 2021 +0200 netdevsim: dev: Initialize FIB module after debugfs [ Upstream commit f57ab5b75f7193e194c83616cd104f41c8350f68 ] Initialize the dummy FIB offload module after debugfs, so that the FIB module could create its own directory there. Signed-off-by: Amit Cohen Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 367ad7fa74f0bdf70eadc3b907bd5dd4c644a8cb Author: Guo-Feng Fan Date: Tue Feb 2 13:50:10 2021 +0800 rtw88: coex: 8821c: correct antenna switch function [ Upstream commit adba838af159914eb98fcd55bfd3a89c9a7d41a8 ] This patch fixes a defect that uses incorrect function to access registers. Use 8 and 32 bit access function to access 8 and 32 bit long data respectively. Signed-off-by: Guo-Feng Fan Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210202055012.8296-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit 48b8b6ad3d1597ee4caf61c20ead586be7bcaa99 Author: Wen Gong Date: Mon Jan 18 18:26:00 2021 +0200 ath11k: add ieee80211_unregister_hw to avoid kernel crash caused by NULL pointer [ Upstream commit 0d96968315d7ffbd70d608b29e9bea084210b96d ] When function return fail to __ath11k_mac_register after success called ieee80211_register_hw, then it set wiphy->dev.parent to NULL by SET_IEEE80211_DEV(ar->hw, NULL) in end of __ath11k_mac_register, then cfg80211_get_drvinfo will be called by below call stack, but the wiphy->dev.parent is NULL, so kernel crash. Call stack to cfg80211_get_drvinfo: NetworkManager 826 [001] 6696.731371: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) ffffffffc107d8f1 cfg80211_get_drvinfo+0x1 (/lib/modules/5.10.0-rc1-wt-ath+/kernel/net/wireless-back/cfg80211.ko) ffffffff9d8fc529 ethtool_get_drvinfo+0x99 (vmlinux) ffffffff9d90080e dev_ethtool+0x1dbe (vmlinux) ffffffff9d8b88f7 dev_ioctl+0xb7 (vmlinux) ffffffff9d8668de sock_do_ioctl+0xae (vmlinux) ffffffff9d866d60 sock_ioctl+0x350 (vmlinux) ffffffff9d2ca30e __x64_sys_ioctl+0x8e (vmlinux) ffffffff9da0dda3 do_syscall_64+0x33 (vmlinux) ffffffff9dc0008c entry_SYSCALL_64_after_hwframe+0x44 (vmlinux) 7feb5f673007 __GI___ioctl+0x7 (/lib/x86_64-linux-gnu/libc-2.23.so) 0 [unknown] ([unknown]) Code of cfg80211_get_drvinfo, the pdev which is wiphy->dev.parent is NULL when kernel crash: void cfg80211_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { struct wireless_dev *wdev = dev->ieee80211_ptr; struct device *pdev = wiphy_dev(wdev->wiphy); if (pdev->driver) .... kernel crash log: [ 973.619550] ath11k_pci 0000:05:00.0: failed to perform regd update : -16 [ 973.619555] ath11k_pci 0000:05:00.0: ath11k regd update failed: -16 [ 973.619566] ath11k_pci 0000:05:00.0: failed register the radio with mac80211: -16 [ 973.619618] ath11k_pci 0000:05:00.0: failed to create pdev core: -16 [ 973.636035] BUG: kernel NULL pointer dereference, address: 0000000000000068 [ 973.636046] #PF: supervisor read access in kernel mode [ 973.636050] #PF: error_code(0x0000) - not-present page [ 973.636054] PGD 800000012452e067 P4D 800000012452e067 PUD 12452d067 PMD 0 [ 973.636064] Oops: 0000 [#1] SMP PTI [ 973.636072] CPU: 3 PID: 848 Comm: NetworkManager Kdump: loaded Tainted: G W OE 5.10.0-rc1-wt-ath+ #24 [ 973.636076] Hardware name: LENOVO 418065C/418065C, BIOS 83ET63WW (1.33 ) 07/29/2011 [ 973.636161] RIP: 0010:cfg80211_get_drvinfo+0x25/0xd0 [cfg80211] [ 973.636169] Code: e9 c9 fe ff ff 66 66 66 66 90 55 53 ba 20 00 00 00 48 8b af 08 03 00 00 48 89 f3 48 8d 7e 04 48 8b 45 00 48 8b 80 90 01 00 00 <48> 8b 40 68 48 85 c0 0f 84 8d 00 00 00 48 8b 30 e8 a6 cc 72 c7 48 [ 973.636174] RSP: 0018:ffffaafb4040bbe0 EFLAGS: 00010286 [ 973.636180] RAX: 0000000000000000 RBX: ffffaafb4040bbfc RCX: 0000000000000000 [ 973.636184] RDX: 0000000000000020 RSI: ffffaafb4040bbfc RDI: ffffaafb4040bc00 [ 973.636188] RBP: ffff8a84c9568950 R08: 722d302e30312e35 R09: 74612d74772d3163 [ 973.636192] R10: 3163722d302e3031 R11: 2b6874612d74772d R12: ffffaafb4040bbfc [ 973.636196] R13: 00007ffe453707c0 R14: ffff8a84c9568000 R15: 0000000000000000 [ 973.636202] FS: 00007fd3d179b940(0000) GS:ffff8a84fa2c0000(0000) knlGS:0000000000000000 [ 973.636206] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 973.636211] CR2: 0000000000000068 CR3: 00000001153b6002 CR4: 00000000000606e0 [ 973.636215] Call Trace: [ 973.636234] ethtool_get_drvinfo+0x99/0x1f0 [ 973.636246] dev_ethtool+0x1dbe/0x2be0 [ 973.636256] ? mntput_no_expire+0x35/0x220 [ 973.636264] ? inet_ioctl+0x1ce/0x200 [ 973.636274] ? tomoyo_path_number_perm+0x68/0x1d0 [ 973.636282] ? kmem_cache_alloc+0x3cb/0x430 [ 973.636290] ? dev_ioctl+0xb7/0x570 [ 973.636295] dev_ioctl+0xb7/0x570 [ 973.636307] sock_do_ioctl+0xae/0x150 [ 973.636315] ? sock_ioctl+0x350/0x3c0 [ 973.636319] sock_ioctl+0x350/0x3c0 [ 973.636332] ? __x64_sys_ioctl+0x8e/0xd0 [ 973.636339] ? dlci_ioctl_set+0x30/0x30 [ 973.636346] __x64_sys_ioctl+0x8e/0xd0 [ 973.636359] do_syscall_64+0x33/0x80 [ 973.636368] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sequence of function call when wlan load for success case when function __ath11k_mac_register return 0: kworker/u16:3-e 2922 [001] 6696.729734: probe:ieee80211_register_hw: (ffffffffc116ae60) kworker/u16:3-e 2922 [001] 6696.730210: probe:ieee80211_if_add: (ffffffffc1185cc0) NetworkManager 826 [001] 6696.731345: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) NetworkManager 826 [001] 6696.731371: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) NetworkManager 826 [001] 6696.731639: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) NetworkManager 826 [001] 6696.731653: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) NetworkManager 826 [001] 6696.732866: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) NetworkManager 826 [001] 6696.732893: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) systemd-udevd 3850 [003] 6696.737199: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) systemd-udevd 3850 [003] 6696.737226: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) NetworkManager 826 [000] 6696.759950: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) NetworkManager 826 [000] 6696.759967: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) NetworkManager 826 [000] 6696.760057: probe:ethtool_get_drvinfo: (ffffffff9d8fc490) NetworkManager 826 [000] 6696.760062: probe:cfg80211_get_drvinfo: (ffffffffc107d8f0) After apply this patch, kernel crash gone, and below is the test case's sequence of function call and log when wlan load with fail by function ath11k_regd_update, and __ath11k_mac_register return fail: kworker/u16:5-e 192 [001] 215.174388: probe:ieee80211_register_hw: (ffffffffc1131e60) kworker/u16:5-e 192 [000] 215.174973: probe:ieee80211_if_add: (ffffffffc114ccc0) NetworkManager 846 [001] 215.175857: probe:ethtool_get_drvinfo: (ffffffff928fc490) kworker/u16:5-e 192 [000] 215.175867: probe:ieee80211_unregister_hw: (ffffffffc1131970) NetworkManager 846 [001] 215.175880: probe:cfg80211_get_drvinfo: (ffffffffc107f8f0) NetworkManager 846 [001] 215.176105: probe:ethtool_get_drvinfo: (ffffffff928fc490) NetworkManager 846 [001] 215.176118: probe:cfg80211_get_drvinfo: (ffffffffc107f8f0) [ 215.175859] ath11k_pci 0000:05:00.0: ath11k regd update failed: -16 NetworkManager 846 [001] 215.196420: probe:ethtool_get_drvinfo: (ffffffff928fc490) NetworkManager 846 [001] 215.196430: probe:cfg80211_get_drvinfo: (ffffffffc107f8f0) [ 215.258598] ath11k_pci 0000:05:00.0: failed register the radio with mac80211: -16 [ 215.258613] ath11k_pci 0000:05:00.0: failed to create pdev core: -16 When ath11k_regd_update or ath11k_debugfs_register return fail, function ieee80211_unregister_hw of mac80211 will be called, then it will wait untill cfg80211_get_drvinfo finished, the wiphy->dev.parent is not NULL at this moment, after that, it set wiphy->dev.parent to NULL by SET_IEEE80211_DEV(ar->hw, NULL) in end of __ath11k_mac_register, so not happen kernel crash. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Wen Gong Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1608607824-16067-1-git-send-email-wgong@codeaurora.org Signed-off-by: Sasha Levin commit ef46db055becefb9ce5e24df1eb5ab91b8188810 Author: Luca Pesce Date: Thu Dec 24 11:51:59 2020 +0100 brcmfmac: clear EAP/association status bits on linkdown events [ Upstream commit e862a3e4088070de352fdafe9bd9e3ae0a95a33c ] This ensure that previous association attempts do not leave stale statuses on subsequent attempts. This fixes the WARN_ON(!cr->bss)) from __cfg80211_connect_result() when connecting to an AP after a previous connection failure (e.g. where EAP fails due to incorrect psk but association succeeded). In some scenarios, indeed, brcmf_is_linkup() was reporting a link up event too early due to stale BRCMF_VIF_STATUS_ASSOC_SUCCESS bit, thus reporting to cfg80211 a connection result with a zeroed bssid (vif->profile.bssid is still empty), causing the WARN_ON due to the call to cfg80211_get_bss() with the empty bssid. Signed-off-by: Luca Pesce Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1608807119-21785-1-git-send-email-luca.pesce@vimar.com Signed-off-by: Sasha Levin commit 8af9b1696c4406b15049a38b400e4c426f584ed2 Author: Sasha Levin Date: Wed Mar 31 19:13:21 2021 -0400 can: tcan4x5x: fix max register value [ Upstream commit 6e1caaf8ed22eb700cc47ec353816eee33186c1c ] This patch fixes the max register value for the regmap. Reviewed-by: Dan Murphy Tested-by: Sean Nyekjaer Link: https://lore.kernel.org/r/20201215231746.1132907-12-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 5d3ba18a67b2af9fae07535c8c785cbf91e88fa9 Author: Dan Carpenter Date: Fri Mar 12 10:41:12 2021 +0300 mptcp: fix bit MPTCP_PUSH_PENDING tests [ Upstream commit 2e5de7e0c8d2caa860e133ef71fc94671cb8e0bf ] The MPTCP_PUSH_PENDING define is 6 and these tests should be testing if BIT(6) is set. Fixes: c2e6048fa1cf ("mptcp: fix race in release_cb") Signed-off-by: Dan Carpenter Reviewed-by: Matthieu Baerts Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8323677c534b390a35e6f3ab0a0e4e723a33ea50 Author: Jia-Ju Bai Date: Sun Mar 7 19:11:02 2021 -0800 net: bonding: fix error return code of bond_neigh_init() [ Upstream commit 2055a99da8a253a357bdfd359b3338ef3375a26c ] When slave is NULL or slave_ops->ndo_neigh_setup is NULL, no error return code of bond_neigh_init() is assigned. To fix this bug, ret is assigned with -EINVAL in these cases. Fixes: 9e99bfefdbce ("bonding: fix bond_neigh_init()") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9a958f67453e624b133248a411be71046d466ddc Author: Paolo Abeni Date: Thu Mar 4 13:32:14 2021 -0800 mptcp: fix race in release_cb [ Upstream commit c2e6048fa1cf2228063aec299f93ac6eb256b457 ] If we receive a MPTCP_PUSH_PENDING even from a subflow when mptcp_release_cb() is serving the previous one, the latter will be delayed up to the next release_sock(msk). Address the issue implementing a test/serve loop for such event. Additionally rename the push helper to __mptcp_push_pending() to be more consistent with the existing code. Fixes: 6e628cd3a8f7 ("mptcp: use mptcp release_cb for delayed tasks") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 96340078d50a54f6a1252c62596bc44321c8bff9 Author: Oleksij Rempel Date: Tue Feb 23 08:01:26 2021 +0100 net: introduce CAN specific pointer in the struct net_device [ Upstream commit 4e096a18867a5a989b510f6999d9c6b6622e8f7b ] Since 20dd3850bcf8 ("can: Speed up CAN frame receiption by using ml_priv") the CAN framework uses per device specific data in the AF_CAN protocol. For this purpose the struct net_device->ml_priv is used. Later the ml_priv usage in CAN was extended for other users, one of them being CAN_J1939. Later in the kernel ml_priv was converted to an union, used by other drivers. E.g. the tun driver started storing it's stats pointer. Since tun devices can claim to be a CAN device, CAN specific protocols will wrongly interpret this pointer, which will cause system crashes. Mostly this issue is visible in the CAN_J1939 stack. To fix this issue, we request a dedicated CAN pointer within the net_device struct. Reported-by: syzbot+5138c4dd15a0401bec7b@syzkaller.appspotmail.com Fixes: 20dd3850bcf8 ("can: Speed up CAN frame receiption by using ml_priv") Fixes: ffd956eef69b ("can: introduce CAN midlayer private and allocate it automatically") Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Fixes: 497a5757ce4e ("tun: switch to net core provided statistics counters") Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20210223070127.4538-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit af0a6521bcd0cacde854e37025c563e4c1c5d128 Author: Marc Kleine-Budde Date: Mon Jan 11 15:19:17 2021 +0100 can: dev: move driver related infrastructure into separate subdir [ Upstream commit 3e77f70e734584e0ad1038e459ed3fd2400f873a ] This patch moves the CAN driver related infrastructure into a separate subdir. It will be split into more files in the coming patches. Reviewed-by: Vincent Mailhol Link: https://lore.kernel.org/r/20210111141930.693847-3-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit a3156379cdb6c4b266994389a0e6d7360e3dae3b Author: Florian Westphal Date: Fri Feb 19 18:35:39 2021 +0100 mptcp: provide subflow aware release function [ Upstream commit ad98dd37051e14fa8c785609430d907fcfd518ba ] mptcp re-used inet(6)_release, so the subflow sockets are ignored. Need to invoke ip(v6)_mc_drop_socket function to ensure mcast join resources get free'd. Fixes: 717e79c867ca5 ("mptcp: Add setsockopt()/getsockopt() socket operations") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/110 Acked-by: Paolo Abeni Signed-off-by: Florian Westphal Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c7d6b898095a5935d5cc47d56133776c13e3da09 Author: Paolo Abeni Date: Fri Feb 19 18:35:37 2021 +0100 mptcp: fix DATA_FIN processing for orphaned sockets [ Upstream commit 341c65242fe18aac8900e4291d472df9f7ba7bc7 ] Currently we move orphaned msk sockets directly from FIN_WAIT2 state to CLOSE, with the rationale that incoming additional data could be just dropped by the TCP stack/TW sockets. Anyhow we miss sending MPTCP-level ack on incoming DATA_FIN, and that may hang the peers. Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close") Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aa0ff16e24049d2a8e42dc8f637c54f04b251d6c Author: Davide Caratti Date: Fri Feb 12 16:12:25 2021 +0100 flow_dissector: fix TTL and TOS dissection on IPv4 fragments [ Upstream commit d2126838050ccd1dadf310ffb78b2204f3b032b9 ] the following command: # tc filter add dev $h2 ingress protocol ip pref 1 handle 101 flower \ $tcflags dst_ip 192.0.2.2 ip_ttl 63 action drop doesn't drop all IPv4 packets that match the configured TTL / destination address. In particular, if "fragment offset" or "more fragments" have non zero value in the IPv4 header, setting of FLOW_DISSECTOR_KEY_IP is simply ignored. Fix this dissecting IPv4 TTL and TOS before fragment info; while at it, add a selftest for tc flower's match on 'ip_ttl' that verifies the correct behavior. Fixes: 518d8a2e9bad ("net/flow_dissector: add support for dissection of misc ip header fields") Reported-by: Shuang Li Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3020469bb5fd5d1cc5f78b7d91f9be128e80daf9 Author: Paolo Abeni Date: Thu Feb 11 15:30:42 2021 -0800 mptcp: add a missing retransmission timer scheduling [ Upstream commit d09d818ec2ed31bce94fdcfcc4700233e01f8498 ] Currently we do not schedule the MPTCP retransmission timer after pushing the data when such action happens in the subflow context. This may cause hang-up on active-backup scenarios, or even when only single subflow msks are involved, if we lost some peer's ack. Fixes: 6e628cd3a8f7 ("mptcp: use mptcp release_cb for delayed tasks") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 26b7b496766c8fb5b7971e8251cd648fb84ad0a9 Author: Paolo Abeni Date: Thu Feb 11 15:30:40 2021 -0800 mptcp: init mptcp request socket earlier [ Upstream commit d8b59efa64060d17b7b61f97d891de2d9f2bd9f0 ] The mptcp subflow route_req() callback performs the subflow req initialization after the route_req() check. If the latter fails, mptcp-specific bits of the current request sockets are left uninitialized. The above causes bad things at req socket disposal time, when the mptcp resources are cleared. This change addresses the issue by splitting subflow_init_req() into the actual initialization and the mptcp-specific checks. The initialization is moved before any possibly failing check. Reported-by: Christoph Paasch Fixes: 7ea851d19b23 ("tcp: merge 'init_req' and 'route_req' functions") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8523cb39e46590da7aa69a8ccbf14818eb2e4f4c Author: Paolo Abeni Date: Thu Feb 11 15:30:38 2021 -0800 mptcp: fix poll after shutdown [ Upstream commit dd913410b0a442a53d41a9817ed2208850858e99 ] The current mptcp_poll() implementation gives unexpected results after shutdown(SEND_SHUTDOWN) and when the msk status is TCP_CLOSE. Set the correct mask. Fixes: 8edf08649eed ("mptcp: rework poll+nospace handling") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c8ad65cb5051498b8a58be40499db9e930f0092e Author: Paolo Abeni Date: Thu Feb 11 15:30:37 2021 -0800 mptcp: deliver ssk errors to msk [ Upstream commit 15cc10453398c22f78f6c2b897119ecce5e5dd89 ] Currently all errors received on msk subflows are ignored. We need to catch at least the errors on connect() and on fallback sockets. Use a custom sk_error_report callback at subflow level, and do the real action under the msk socket lock - via the usual sock_owned_by_user()/release_callback() schema. Fixes: 6e628cd3a8f7 ("mptcp: use mptcp release_cb for delayed tasks") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d5d8a0f9813984713d9cedc9d5d124b46cb373f3 Author: Sasha Levin Date: Wed Mar 31 19:11:09 2021 -0400 net: mvpp2: fix interrupt mask/unmask skip condition [ Upstream commit 7867299cde34e9c2d2c676f2a384a9d5853b914d ] The condition should be skipped if CPU ID equal to nthreads. The patch doesn't fix any actual issue since nthreads = min_t(unsigned int, num_present_cpus(), MVPP2_MAX_THREADS). On all current Armada platforms, the number of CPU's is less than MVPP2_MAX_THREADS. Fixes: e531f76757eb ("net: mvpp2: handle cases where more CPUs are available than s/w threads") Reported-by: Russell King Signed-off-by: Stefan Chulski Reviewed-by: Russell King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 137f475b4095d1ef1d1c1bcfe683e08efee8af73 Author: Stefan Metzmacher Date: Sat Mar 20 20:33:36 2021 +0100 io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALL [ Upstream commit 0031275d119efe16711cd93519b595e6f9b4b330 ] Without that it's not safe to use them in a linked combination with others. Now combinations like IORING_OP_SENDMSG followed by IORING_OP_SPLICE should be possible. We already handle short reads and writes for the following opcodes: - IORING_OP_READV - IORING_OP_READ_FIXED - IORING_OP_READ - IORING_OP_WRITEV - IORING_OP_WRITE_FIXED - IORING_OP_WRITE - IORING_OP_SPLICE - IORING_OP_TEE Now we have it for these as well: - IORING_OP_SENDMSG - IORING_OP_SEND - IORING_OP_RECVMSG - IORING_OP_RECV For IORING_OP_RECVMSG we also check for the MSG_TRUNC and MSG_CTRUNC flags in order to call req_set_fail_links(). There might be applications arround depending on the behavior that even short send[msg]()/recv[msg]() retuns continue an IOSQE_IO_LINK chain. It's very unlikely that such applications pass in MSG_WAITALL, which is only defined in 'man 2 recvmsg', but not in 'man 2 sendmsg'. It's expected that the low level sock_sendmsg() call just ignores MSG_WAITALL, as MSG_ZEROCOPY is also ignored without explicitly set SO_ZEROCOPY. We also expect the caller to know about the implicit truncation to MAX_RW_COUNT, which we don't detect. cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/c4e1a4cc0d905314f4d5dc567e65a7b09621aab3.1615908477.git.metze@samba.org Signed-off-by: Stefan Metzmacher Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 62973258de061561821940a07558d04d321faa4f Author: zhangyi (F) Date: Wed Mar 3 21:17:03 2021 +0800 ext4: do not iput inode under running transaction in ext4_rename() [ Upstream commit 5dccdc5a1916d4266edd251f20bbbb113a5c495f ] In ext4_rename(), when RENAME_WHITEOUT failed to add new entry into directory, it ends up dropping new created whiteout inode under the running transaction. After commit <9b88f9fb0d2> ("ext4: Do not iput inode under running transaction"), we follow the assumptions that evict() does not get called from a transaction context but in ext4_rename() it breaks this suggestion. Although it's not a real problem, better to obey it, so this patch add inode to orphan list and stop transaction before final iput(). Signed-off-by: zhangyi (F) Link: https://lore.kernel.org/r/20210303131703.330415-2-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 9117da5160143fbc69751672aeeab2b8cc34d71a Author: Peter Zijlstra Date: Thu Mar 18 11:29:56 2021 +0100 static_call: Align static_call_is_init() patching condition [ Upstream commit 698bacefe993ad2922c9d3b1380591ad489355e9 ] The intent is to avoid writing init code after init (because the text might have been freed). The code is needlessly different between jump_label and static_call and not obviously correct. The existing code relies on the fact that the module loader clears the init layout, such that within_module_init() always fails, while jump_label relies on the module state which is more obvious and matches the kernel logic. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Jarkko Sakkinen Tested-by: Sumit Garg Link: https://lkml.kernel.org/r/20210318113610.636651340@infradead.org Signed-off-by: Sasha Levin commit 914a468da029748d942889f35ffeb434e5301c86 Author: Tobias Klausmann Date: Sat Mar 13 23:21:59 2021 +0100 nouveau: Skip unvailable ttm page entries [ Upstream commit e94c55b8e0a0bbe9a026250cf31e2fa45957d776 ] Starting with commit f295c8cfec833c2707ff1512da10d65386dde7af ("drm/nouveau: fix dma syncing warning with debugging on.") the following oops occures: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 1013 Comm: Xorg.bin Tainted: G E 5.11.0-desktop-rc0+ #2 Hardware name: Acer Aspire VN7-593G/Pluto_KLS, BIOS V1.11 08/01/2018 RIP: 0010:nouveau_bo_sync_for_device+0x40/0xb0 [nouveau] Call Trace: nouveau_bo_validate+0x5d/0x80 [nouveau] nouveau_gem_ioctl_pushbuf+0x662/0x1120 [nouveau] ? nouveau_gem_ioctl_new+0xf0/0xf0 [nouveau] drm_ioctl_kernel+0xa6/0xf0 [drm] drm_ioctl+0x1f4/0x3a0 [drm] ? nouveau_gem_ioctl_new+0xf0/0xf0 [nouveau] nouveau_drm_ioctl+0x50/0xa0 [nouveau] __x64_sys_ioctl+0x7e/0xb0 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae ---[ end trace ccfb1e7f4064374f ]--- RIP: 0010:nouveau_bo_sync_for_device+0x40/0xb0 [nouveau] The underlying problem is not introduced by the commit, yet it uncovered the underlying issue. The cited commit relies on valid pages. This is not given for due to some bugs. For now, just warn and work around the issue by just ignoring the bad ttm objects. Below is some debug info gathered while debugging this issue: nouveau 0000:01:00.0: DRM: ttm_dma->num_pages: 2048 nouveau 0000:01:00.0: DRM: ttm_dma->pages is NULL nouveau 0000:01:00.0: DRM: ttm_dma: 00000000e96058e7 nouveau 0000:01:00.0: DRM: ttm_dma->page_flags: nouveau 0000:01:00.0: DRM: ttm_dma: Populated: 1 nouveau 0000:01:00.0: DRM: ttm_dma: No Retry: 0 nouveau 0000:01:00.0: DRM: ttm_dma: SG: 256 nouveau 0000:01:00.0: DRM: ttm_dma: Zero Alloc: 0 nouveau 0000:01:00.0: DRM: ttm_dma: Swapped: 0 Signed-off-by: Tobias Klausmann Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20210313222159.3346-1-tobias.klausmann@freenet.de Signed-off-by: Sasha Levin commit c9927987decdc2cc25b2218c3e51c2f7a8a522ca Author: Josef Bacik Date: Tue Mar 16 22:17:48 2021 -0400 Revert "PM: ACPI: reboot: Use S5 for reboot" [ Upstream commit 9d3fcb28f9b9750b474811a2964ce022df56336e ] This reverts commit d60cd06331a3566d3305b3c7b566e79edf4e2095. This patch causes a panic when rebooting my Dell Poweredge r440. I do not have the full panic log as it's lost at that stage of the reboot and I do not have a serial console. Reverting this patch makes my system able to reboot again. Signed-off-by: Josef Bacik Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f4d729ed3497241fece0b481680d8287f30982cd Author: Stefan Metzmacher Date: Tue Mar 16 16:33:27 2021 +0100 io_uring: imply MSG_NOSIGNAL for send[msg]()/recv[msg]() calls [ Upstream commit 76cd979f4f38a27df22efb5773a0d567181a9392 ] We never want to generate any SIGPIPE, -EPIPE only is much better. Signed-off-by: Stefan Metzmacher Link: https://lore.kernel.org/r/38961085c3ec49fd21550c7788f214d1ff02d2d4.1615908477.git.metze@samba.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3b3d1dba0ac6ff89c52d2a517b9e541d75d279c6 Author: Elad Grupi Date: Tue Mar 16 17:44:25 2021 +0200 nvmet-tcp: fix kmap leak when data digest in use [ Upstream commit bac04454ef9fada009f0572576837548b190bf94 ] When data digest is enabled we should unmap pdu iovec before handling the data digest pdu. Signed-off-by: Elad Grupi Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 41bf5bfe66ab00780d196c0f77e063ee2ffd595e Author: Waiman Long Date: Tue Mar 16 11:31:17 2021 -0400 locking/ww_mutex: Fix acquire/release imbalance in ww_acquire_init()/ww_acquire_fini() [ Upstream commit bee645788e07eea63055d261d2884ea45c2ba857 ] In ww_acquire_init(), mutex_acquire() is gated by CONFIG_DEBUG_LOCK_ALLOC. The dep_map in the ww_acquire_ctx structure is also gated by the same config. However mutex_release() in ww_acquire_fini() is gated by CONFIG_DEBUG_MUTEXES. It is possible to set CONFIG_DEBUG_MUTEXES without setting CONFIG_DEBUG_LOCK_ALLOC though it is an unlikely configuration. That may cause a compilation error as dep_map isn't defined in this case. Fix this potential problem by enclosing mutex_release() inside CONFIG_DEBUG_LOCK_ALLOC. Signed-off-by: Waiman Long Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210316153119.13802-3-longman@redhat.com Signed-off-by: Sasha Levin commit 714c7a5f184376581dc836bf668a0d8fc979ad6a Author: Waiman Long Date: Tue Mar 16 11:31:16 2021 -0400 locking/ww_mutex: Simplify use_ww_ctx & ww_ctx handling [ Upstream commit 5de2055d31ea88fd9ae9709ac95c372a505a60fa ] The use_ww_ctx flag is passed to mutex_optimistic_spin(), but the function doesn't use it. The frequent use of the (use_ww_ctx && ww_ctx) combination is repetitive. In fact, ww_ctx should not be used at all if !use_ww_ctx. Simplify ww_mutex code by dropping use_ww_ctx from mutex_optimistic_spin() an clear ww_ctx if !use_ww_ctx. In this way, we can replace (use_ww_ctx && ww_ctx) by just (ww_ctx). Signed-off-by: Waiman Long Signed-off-by: Ingo Molnar Acked-by: Davidlohr Bueso Link: https://lore.kernel.org/r/20210316153119.13802-2-longman@redhat.com Signed-off-by: Sasha Levin commit 3a822fabef9ea742232986610e7fa0fd65786063 Author: Manaf Meethalavalappu Pallikunhi Date: Tue Dec 8 00:23:01 2020 +0530 thermal/core: Add NULL pointer check before using cooling device stats [ Upstream commit 2046a24ae121cd107929655a6aaf3b8c5beea01f ] There is a possible chance that some cooling device stats buffer allocation fails due to very high cooling device max state value. Later cooling device update sysfs can try to access stats data for the same cooling device. It will lead to NULL pointer dereference issue. Add a NULL pointer check before accessing thermal cooling device stats data. It fixes the following bug [ 26.812833] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 27.122960] Call trace: [ 27.122963] do_raw_spin_lock+0x18/0xe8 [ 27.122966] _raw_spin_lock+0x24/0x30 [ 27.128157] thermal_cooling_device_stats_update+0x24/0x98 [ 27.128162] cur_state_store+0x88/0xb8 [ 27.128166] dev_attr_store+0x40/0x58 [ 27.128169] sysfs_kf_write+0x50/0x68 [ 27.133358] kernfs_fop_write+0x12c/0x1c8 [ 27.133362] __vfs_write+0x54/0x160 [ 27.152297] vfs_write+0xcc/0x188 [ 27.157132] ksys_write+0x78/0x108 [ 27.162050] ksys_write+0xf8/0x108 [ 27.166968] __arm_smccc_hvc+0x158/0x4b0 [ 27.166973] __arm_smccc_hvc+0x9c/0x4b0 [ 27.186005] el0_svc+0x8/0xc Signed-off-by: Manaf Meethalavalappu Pallikunhi Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/1607367181-24589-1-git-send-email-manafm@codeaurora.org Signed-off-by: Sasha Levin commit 279f56492820e9e5a019418e3e39fbe49207dba2 Author: Bard Liao Date: Tue Mar 16 08:52:54 2021 +0800 ASoC: rt711: add snd_soc_component remove callback [ Upstream commit 899b12542b0897f92de9ba30944937c39ebb246d ] We do some IO operations in the snd_soc_component_set_jack callback function and snd_soc_component_set_jack() will be called when soc component is removed. However, we should not access SoundWire registers when the bus is suspended. So set regcache_cache_only(regmap, true) to avoid accessing in the soc component removal process. Signed-off-by: Bard Liao Reviewed-by: Kai Vehmanen Reviewed-by: Rander Wang Link: https://lore.kernel.org/r/20210316005254.29699-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e5f278d111665f08b41cd91e71d27cdd3150fc8d Author: Sameer Pujar Date: Mon Mar 15 23:01:32 2021 +0530 ASoC: rt5659: Update MCLK rate in set_sysclk() [ Upstream commit dbf54a9534350d6aebbb34f5c1c606b81a4f35dd ] Simple-card/audio-graph-card drivers do not handle MCLK clock when it is specified in the codec device node. The expectation here is that, the codec should actually own up the MCLK clock and do necessary setup in the driver. Suggested-by: Mark Brown Suggested-by: Michael Walle Signed-off-by: Sameer Pujar Link: https://lore.kernel.org/r/1615829492-8972-3-git-send-email-spujar@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ee5a0171c861a490a309f2297b0cd1191b26faad Author: Tong Zhang Date: Mon Mar 15 15:58:12 2021 -0400 staging: comedi: cb_pcidas64: fix request_irq() warn [ Upstream commit d2d106fe3badfc3bf0dd3899d1c3f210c7203eab ] request_irq() wont accept a name which contains slash so we need to repalce it with something else -- otherwise it will trigger a warning and the entry in /proc/irq/ will not be created since the .name might be used by userspace and we don't want to break userspace, so we are changing the parameters passed to request_irq() [ 1.565966] name 'pci-das6402/16' [ 1.566149] WARNING: CPU: 0 PID: 184 at fs/proc/generic.c:180 __xlate_proc_name+0x93/0xb0 [ 1.568923] RIP: 0010:__xlate_proc_name+0x93/0xb0 [ 1.574200] Call Trace: [ 1.574722] proc_mkdir+0x18/0x20 [ 1.576629] request_threaded_irq+0xfe/0x160 [ 1.576859] auto_attach+0x60a/0xc40 [cb_pcidas64] Suggested-by: Ian Abbott Reviewed-by: Ian Abbott Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210315195814.4692-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d116f85e216423cccffdffe837f48c0f7ab01a18 Author: Tong Zhang Date: Mon Mar 15 15:59:14 2021 -0400 staging: comedi: cb_pcidas: fix request_irq() warn [ Upstream commit 2e5848a3d86f03024ae096478bdb892ab3d79131 ] request_irq() wont accept a name which contains slash so we need to repalce it with something else -- otherwise it will trigger a warning and the entry in /proc/irq/ will not be created since the .name might be used by userspace and we don't want to break userspace, so we are changing the parameters passed to request_irq() [ 1.630764] name 'pci-das1602/16' [ 1.630950] WARNING: CPU: 0 PID: 181 at fs/proc/generic.c:180 __xlate_proc_name+0x93/0xb0 [ 1.634009] RIP: 0010:__xlate_proc_name+0x93/0xb0 [ 1.639441] Call Trace: [ 1.639976] proc_mkdir+0x18/0x20 [ 1.641946] request_threaded_irq+0xfe/0x160 [ 1.642186] cb_pcidas_auto_attach+0xf4/0x610 [cb_pcidas] Suggested-by: Ian Abbott Reviewed-by: Ian Abbott Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210315195914.4801-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dfcd3b061cab2d961acca5739cfa5915ad992ce6 Author: Alexey Dobriyan Date: Sun Mar 14 18:32:46 2021 +0300 scsi: qla2xxx: Fix broken #endif placement [ Upstream commit 5999b9e5b1f8a2f5417b755130919b3ac96f5550 ] Only half of the file is under include guard because terminating #endif is placed too early. Link: https://lore.kernel.org/r/YE4snvoW1SuwcXAn@localhost.localdomain Reviewed-by: Himanshu Madhani Signed-off-by: Alexey Dobriyan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 62a68b899c356e3fa70c7bbcdd92fae3707da2a2 Author: Lv Yunlong Date: Wed Mar 10 22:46:36 2021 -0800 scsi: st: Fix a use after free in st_open() [ Upstream commit c8c165dea4c8f5ad67b1240861e4f6c5395fa4ac ] In st_open(), if STp->in_use is true, STp will be freed by scsi_tape_put(). However, STp is still used by DEBC_printk() after. It is better to DEBC_printk() before scsi_tape_put(). Link: https://lore.kernel.org/r/20210311064636.10522-1-lyl2019@mail.ustc.edu.cn Acked-by: Kai Mäkisara Signed-off-by: Lv Yunlong Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 55aafb46c682879300dfaad3ede0706f0c2800e1 Author: Pavel Begunkov Date: Sun Mar 14 20:57:11 2021 +0000 io_uring: halt SQO submission on ctx exit [ Upstream commit f6d54255f4235448d4bbe442362d4caa62da97d5 ] io_sq_thread_finish() is called in io_ring_ctx_free(), so SQPOLL task is potentially running submitting new requests. It's not a disaster because of using a "try" variant of percpu_ref_get, but is far from nice. Remove ctx from the sqd ctx list earlier, before cancellation loop, so SQPOLL can't find it and so won't submit new requests. Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 29bc3de1cf8a5e33b87ad8e3f51ed8594ca3116e Author: Pavel Begunkov Date: Sun Mar 14 20:57:08 2021 +0000 io_uring: fix ->flags races by linked timeouts [ Upstream commit efe814a471e0e58f28f1efaf430c8784a4f36626 ] It's racy to modify req->flags from a not owning context, e.g. linked timeout calling req_set_fail_links() for the master request might race with that request setting/clearing flags while being executed concurrently. Just remove req_set_fail_links(prev) from io_link_timeout_fn(), io_async_find_and_cancel() and functions down the line take care of setting the fail bit. Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5913eef4bf6c81d9105bf6641c672d0c79847b34 Author: Laurent Vivier Date: Fri Mar 12 15:09:13 2021 +0100 vhost: Fix vhost_vq_reset() [ Upstream commit beb691e69f4dec7bfe8b81b509848acfd1f0dbf9 ] vhost_reset_is_le() is vhost_init_is_le(), and in the case of cross-endian legacy, vhost_init_is_le() depends on vq->user_be. vq->user_be is set by vhost_disable_cross_endian(). But in vhost_vq_reset(), we have: vhost_reset_is_le(vq); vhost_disable_cross_endian(vq); And so user_be is used before being set. To fix that, reverse the lines order as there is no other dependency between them. Signed-off-by: Laurent Vivier Link: https://lore.kernel.org/r/20210312140913.788592-1-lvivier@redhat.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit e48fc4dac0d11c959396fd36a228102ddeaf8e7d Author: Jens Axboe Date: Fri Mar 12 20:20:42 2021 -0700 kernel: freezer should treat PF_IO_WORKER like PF_KTHREAD for freezing [ Upstream commit 15b2219facadec583c24523eed40fa45865f859f ] Don't send fake signals to PF_IO_WORKER threads, they don't accept signals. Just treat them like kthreads in this regard, all they need is a wakeup as no forced kernel/user transition is needed. Suggested-by: Linus Torvalds Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5539cdceb9c81fa127028eda0be7b1e05e2ecf2b Author: Jiaxin Yu Date: Fri Mar 12 10:26:45 2021 +0800 ASoC: mediatek: mt8192: fix tdm out data is valid on rising edge [ Upstream commit 8d06b9633a66f41fed520f6eebd163189518ba79 ] This patch correct tdm out bck inverse register to AUDIO_TOP_CON3[3]. Signed-off-by: Jiaxin Yu Link: https://lore.kernel.org/r/1615516005-781-1-git-send-email-jiaxin.yu@mediatek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6ceb22f49331def973279ebe6538da8890ae35c8 Author: Olga Kornievskaia Date: Thu Mar 11 10:55:00 2021 -0500 NFSD: fix error handling in NFSv4.0 callbacks [ Upstream commit b4250dd868d1b42c0a65de11ef3afbee67ba5d2f ] When the server tries to do a callback and a client fails it due to authentication problems, we need the server to set callback down flag in RENEW so that client can recover. Suggested-by: Bruce Fields Signed-off-by: Olga Kornievskaia Signed-off-by: Chuck Lever Tested-by: Benjamin Coddington Link: https://lore.kernel.org/linux-nfs/FB84E90A-1A03-48B3-8BF7-D9D10AC2C9FE@oracle.com/T/#t Signed-off-by: Sasha Levin commit 232079a59eecf0eacb566e619fc95af2e0c6a3ad Author: Lucas Tanure Date: Fri Mar 5 17:34:32 2021 +0000 ASoC: cs42l42: Always wait at least 3ms after reset [ Upstream commit 19325cfea04446bc79b36bffd4978af15f46a00e ] This delay is part of the power-up sequence defined in the datasheet. A runtime_resume is a power-up so must also include the delay. Signed-off-by: Lucas Tanure Link: https://lore.kernel.org/r/20210305173442.195740-6-tanureal@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 50afa98b2658e39af8c90e2480f17150edc7b161 Author: Lucas Tanure Date: Fri Mar 5 17:34:30 2021 +0000 ASoC: cs42l42: Fix mixer volume control [ Upstream commit 72d904763ae6a8576e7ad034f9da4f0e3c44bf24 ] The minimum value is 0x3f (-63dB), which also is mute Signed-off-by: Lucas Tanure Link: https://lore.kernel.org/r/20210305173442.195740-4-tanureal@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a7ed29e0b482150d43ee73f7cfb40fdb9cd9b17f Author: Lucas Tanure Date: Fri Mar 5 17:34:29 2021 +0000 ASoC: cs42l42: Fix channel width support [ Upstream commit 2bdc4f5c6838f7c3feb4fe68e4edbeea158ec0a2 ] Remove the hard coded 32 bits width and replace with the correct width calculated by params_width. Signed-off-by: Lucas Tanure Link: https://lore.kernel.org/r/20210305173442.195740-3-tanureal@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9e9ecae487e5f2d5fdb247ff30d91dbdb2a3b2f3 Author: Lucas Tanure Date: Fri Mar 5 17:34:28 2021 +0000 ASoC: cs42l42: Fix Bitclock polarity inversion [ Upstream commit e793c965519b8b7f2fea51a48398405e2a501729 ] The driver was setting bit clock polarity opposite to intended polarity. Also simplify the code by grouping ADC and DAC clock configurations into a single field. Signed-off-by: Lucas Tanure Link: https://lore.kernel.org/r/20210305173442.195740-2-tanureal@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 47cf9fdb52cbaf015905462acc39e5af0f7af92c Author: Jon Hunter Date: Wed Mar 3 11:55:26 2021 +0000 ASoC: soc-core: Prevent warning if no DMI table is present [ Upstream commit 7de14d581dbed57c2b3c6afffa2c3fdc6955a3cd ] Many systems do not use ACPI and hence do not provide a DMI table. On non-ACPI systems a warning, such as the following, is printed on boot. WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name! The variable 'dmi_available' is not exported and so currently cannot be used by kernel modules without adding an accessor. However, it is possible to use the function is_acpi_device_node() to determine if the sound card is an ACPI device and hence indicate if we expect a DMI table to be present. Therefore, call is_acpi_device_node() to see if we are using ACPI and only parse the DMI table if we are booting with ACPI. Signed-off-by: Jon Hunter Link: https://lore.kernel.org/r/20210303115526.419458-1-jonathanh@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit eebdf37f90c053f386aadea7969b6494a6f54585 Author: Hans de Goede Date: Sun Feb 28 17:04:41 2021 +0100 ASoC: es8316: Simplify adc_pga_gain_tlv table [ Upstream commit bb18c678754ce1514100fb4c0bf6113b5af36c48 ] Most steps in this table are steps of 3dB (300 centi-dB), so we can simplify the table. This not only reduces the amount of space it takes inside the kernel, this also makes alsa-lib's mixer code actually accept the table, where as before this change alsa-lib saw the "ADC PGA Gain" control as a control without a dB scale. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210228160441.241110-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fe070840bf4928446f94c2d24029bd57bdc4ac63 Author: Benjamin Rood Date: Fri Feb 19 13:33:08 2021 -0500 ASoC: sgtl5000: set DAP_AVC_CTRL register to correct default value on probe [ Upstream commit f86f58e3594fb0ab1993d833d3b9a2496f3c928c ] According to the SGTL5000 datasheet [1], the DAP_AVC_CTRL register has the following bit field definitions: | BITS | FIELD | RW | RESET | DEFINITION | | 15 | RSVD | RO | 0x0 | Reserved | | 14 | RSVD | RW | 0x1 | Reserved | | 13:12 | MAX_GAIN | RW | 0x1 | Max Gain of AVC in expander mode | | 11:10 | RSVD | RO | 0x0 | Reserved | | 9:8 | LBI_RESP | RW | 0x1 | Integrator Response | | 7:6 | RSVD | RO | 0x0 | Reserved | | 5 | HARD_LMT_EN | RW | 0x0 | Enable hard limiter mode | | 4:1 | RSVD | RO | 0x0 | Reserved | | 0 | EN | RW | 0x0 | Enable/Disable AVC | The original default value written to the DAP_AVC_CTRL register during sgtl5000_i2c_probe() was 0x0510. This would incorrectly write values to bits 4 and 10, which are defined as RESERVED. It would also not set bits 12 and 14 to their correct RESET values of 0x1, and instead set them to 0x0. While the DAP_AVC module is effectively disabled because the EN bit is 0, this default value is still writing invalid values to registers that are marked as read-only and RESERVED as well as not setting bits 12 and 14 to their correct default values as defined by the datasheet. The correct value that should be written to the DAP_AVC_CTRL register is 0x5100, which configures the register bits to the default values defined by the datasheet, and prevents any writes to bits defined as 'read-only'. Generally speaking, it is best practice to NOT attempt to write values to registers/bits defined as RESERVED, as it generally produces unwanted/undefined behavior, or errors. Also, all credit for this patch should go to my colleague Dan MacDonald for finding this error in the first place. [1] https://www.nxp.com/docs/en/data-sheet/SGTL5000.pdf Signed-off-by: Benjamin Rood Reviewed-by: Fabio Estevam Link: https://lore.kernel.org/r/20210219183308.GA2117@ubuntu-dev Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit eda720c10114bb8dca07e307f0ae36d2320170c9 Author: Hans de Goede Date: Fri Feb 26 15:38:14 2021 +0100 ASoC: rt5651: Fix dac- and adc- vol-tlv values being off by a factor of 10 [ Upstream commit eee51df776bd6cac10a76b2779a9fdee3f622b2b ] The adc_vol_tlv volume-control has a range from -17.625 dB to +30 dB, not -176.25 dB to + 300 dB. This wrong scale is esp. a problem in userspace apps which translate the dB scale to a linear scale. With the logarithmic dB scale being of by a factor of 10 we loose all precision in the lower area of the range when apps translate things to a linear scale. E.g. the 0 dB default, which corresponds with a value of 47 of the 0 - 127 range for the control, would be shown as 0/100 in alsa-mixer. Since the centi-dB values used in the TLV struct cannot represent the 0.375 dB step size used by these controls, change the TLV definition for them to specify a min and max value instead of min + stepsize. Note this mirrors commit 3f31f7d9b540 ("ASoC: rt5670: Fix dac- and adc- vol-tlv values being off by a factor of 10") which made the exact same change to the rt5670 codec driver. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210226143817.84287-3-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e51305da601ea9c4894a3765f97f0f32479cf2e6 Author: Hans de Goede Date: Fri Feb 26 15:38:13 2021 +0100 ASoC: rt5640: Fix dac- and adc- vol-tlv values being off by a factor of 10 [ Upstream commit cfa26ed1f9f885c2fd8f53ca492989d1e16d0199 ] The adc_vol_tlv volume-control has a range from -17.625 dB to +30 dB, not -176.25 dB to + 300 dB. This wrong scale is esp. a problem in userspace apps which translate the dB scale to a linear scale. With the logarithmic dB scale being of by a factor of 10 we loose all precision in the lower area of the range when apps translate things to a linear scale. E.g. the 0 dB default, which corresponds with a value of 47 of the 0 - 127 range for the control, would be shown as 0/100 in alsa-mixer. Since the centi-dB values used in the TLV struct cannot represent the 0.375 dB step size used by these controls, change the TLV definition for them to specify a min and max value instead of min + stepsize. Note this mirrors commit 3f31f7d9b540 ("ASoC: rt5670: Fix dac- and adc- vol-tlv values being off by a factor of 10") which made the exact same change to the rt5670 codec driver. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210226143817.84287-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5090e22d53c6f82b70dc0e7be5b64fc859893a4e Author: Jack Yu Date: Mon Feb 22 17:00:56 2021 +0800 ASoC: rt1015: fix i2c communication error [ Upstream commit 9e0bdaa9fcb8c64efc1487a7fba07722e7bc515e ] Remove 0x100 cache re-sync to solve i2c communication error. Signed-off-by: Jack Yu Link: https://lore.kernel.org/r/20210222090057.29532-1-jack.yu@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit de53b43684fa864960dee15baf393d7a7edc3a93 Author: Ritesh Harjani Date: Tue Mar 9 09:29:11 2021 -0800 iomap: Fix negative assignment to unsigned sis->pages in iomap_swapfile_activate [ Upstream commit 5808fecc572391867fcd929662b29c12e6d08d81 ] In case if isi.nr_pages is 0, we are making sis->pages (which is unsigned int) a huge value in iomap_swapfile_activate() by assigning -1. This could cause a kernel crash in kernel v4.18 (with below signature). Or could lead to unknown issues on latest kernel if the fake big swap gets used. Fix this issue by returning -EINVAL in case of nr_pages is 0, since it is anyway a invalid swapfile. Looks like this issue will be hit when we have pagesize < blocksize type of configuration. I was able to hit the issue in case of a tiny swap file with below test script. https://raw.githubusercontent.com/riteshharjani/LinuxStudy/master/scripts/swap-issue.sh kernel crash analysis on v4.18 ============================== On v4.18 kernel, it causes a kernel panic, since sis->pages becomes a huge value and isi.nr_extents is 0. When 0 is returned it is considered as a swapfile over NFS and SWP_FILE is set (sis->flags |= SWP_FILE). Then when swapoff was getting called it was calling a_ops->swap_deactivate() if (sis->flags & SWP_FILE) is true. Since a_ops->swap_deactivate() is NULL in case of XFS, it causes below panic. Panic signature on v4.18 kernel: ======================================= root@qemu:/home/qemu# [ 8291.723351] XFS (loop2): Unmounting Filesystem [ 8292.123104] XFS (loop2): Mounting V5 Filesystem [ 8292.132451] XFS (loop2): Ending clean mount [ 8292.263362] Adding 4294967232k swap on /mnt1/test/swapfile. Priority:-2 extents:1 across:274877906880k [ 8292.277834] Unable to handle kernel paging request for instruction fetch [ 8292.278677] Faulting instruction address: 0x00000000 cpu 0x19: Vector: 400 (Instruction Access) at [c0000009dd5b7ad0] pc: 0000000000000000 lr: c0000000003eb9dc: destroy_swap_extents+0xfc/0x120 sp: c0000009dd5b7d50 msr: 8000000040009033 current = 0xc0000009b6710080 paca = 0xc00000003ffcb280 irqmask: 0x03 irq_happened: 0x01 pid = 5604, comm = swapoff Linux version 4.18.0 (riteshh@xxxxxxx) (gcc version 8.4.0 (Ubuntu 8.4.0-1ubuntu1~18.04)) #57 SMP Wed Mar 3 01:33:04 CST 2021 enter ? for help [link register ] c0000000003eb9dc destroy_swap_extents+0xfc/0x120 [c0000009dd5b7d50] c0000000025a7058 proc_poll_event+0x0/0x4 (unreliable) [c0000009dd5b7da0] c0000000003f0498 sys_swapoff+0x3f8/0x910 [c0000009dd5b7e30] c00000000000bbe4 system_call+0x5c/0x70 Exception: c01 (System Call) at 00007ffff7d208d8 Signed-off-by: Ritesh Harjani [djwong: rework the comment to provide more details] Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f8b09ac5c3c3b6623be5b7a855c228071ed63968 Author: J. Bruce Fields Date: Tue Mar 2 10:48:38 2021 -0500 rpc: fix NULL dereference on kmalloc failure [ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ] I think this is unlikely but possible: svc_authenticate sets rq_authop and calls svcauth_gss_accept. The kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL, and returning SVC_DENIED. This causes svc_process_common to go to err_bad_auth, and eventually call svc_authorise. That calls ->release == svcauth_gss_release, which tries to dereference rq_auth_data. Signed-off-by: J. Bruce Fields Link: https://lore.kernel.org/linux-nfs/3F1B347F-B809-478F-A1E9-0BE98E22B0F0@oracle.com/T/#t Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit fbf2a8f69f7caafa8d7d18d23f30062212459198 Author: Julian Braha Date: Fri Feb 19 16:56:10 2021 -0500 fs: nfsd: fix kconfig dependency warning for NFSD_V4 [ Upstream commit 7005227369079963d25fb2d5d736d0feb2c44cf6 ] When NFSD_V4 is enabled and CRYPTO is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for CRYPTO_SHA256 Depends on [n]: CRYPTO [=n] Selected by [y]: - NFSD_V4 [=y] && NETWORK_FILESYSTEMS [=y] && NFSD [=y] && PROC_FS [=y] WARNING: unmet direct dependencies detected for CRYPTO_MD5 Depends on [n]: CRYPTO [=n] Selected by [y]: - NFSD_V4 [=y] && NETWORK_FILESYSTEMS [=y] && NFSD [=y] && PROC_FS [=y] This is because NFSD_V4 selects CRYPTO_MD5 and CRYPTO_SHA256, without depending on or selecting CRYPTO, despite those config options being subordinate to CRYPTO. Signed-off-by: Julian Braha Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit ebf57bcf5e3d520fe748e18349c3e57791f6ff0b Author: Zhaolong Zhang Date: Tue Mar 2 17:42:31 2021 +0800 ext4: fix bh ref count on error paths [ Upstream commit c915fb80eaa6194fa9bd0a4487705cd5b0dda2f1 ] __ext4_journalled_writepage should drop bhs' ref count on error paths Signed-off-by: Zhaolong Zhang Link: https://lore.kernel.org/r/1614678151-70481-1-git-send-email-zhangzl2013@126.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 5bcd6d6f3ff4d50fa7d05e3f8a69608217b0791b Author: Eric Whitney Date: Thu Feb 18 10:11:32 2021 -0500 ext4: shrink race window in ext4_should_retry_alloc() [ Upstream commit efc61345274d6c7a46a0570efbc916fcbe3e927b ] When generic/371 is run on kvm-xfstests using 5.10 and 5.11 kernels, it fails at significant rates on the two test scenarios that disable delayed allocation (ext3conv and data_journal) and force actual block allocation for the fallocate and pwrite functions in the test. The failure rate on 5.10 for both ext3conv and data_journal on one test system typically runs about 85%. On 5.11, the failure rate on ext3conv sometimes drops to as low as 1% while the rate on data_journal increases to nearly 100%. The observed failures are largely due to ext4_should_retry_alloc() cutting off block allocation retries when s_mb_free_pending (used to indicate that a transaction in progress will free blocks) is 0. However, free space is usually available when this occurs during runs of generic/371. It appears that a thread attempting to allocate blocks is just missing transaction commits in other threads that increase the free cluster count and reset s_mb_free_pending while the allocating thread isn't running. Explicitly testing for free space availability avoids this race. The current code uses a post-increment operator in the conditional expression that determines whether the retry limit has been exceeded. This means that the conditional expression uses the value of the retry counter before it's increased, resulting in an extra retry cycle. The current code actually retries twice before hitting its retry limit rather than once. Increasing the retry limit to 3 from the current actual maximum retry count of 2 in combination with the change described above reduces the observed failure rate to less that 0.1% on both ext3conv and data_journal with what should be limited impact on users sensitive to the overhead caused by retries. A per filesystem percpu counter exported via sysfs is added to allow users or developers to track the number of times the retry limit is exceeded without resorting to debugging methods. This should provide some insight into worst case retry behavior. Signed-off-by: Eric Whitney Link: https://lore.kernel.org/r/20210218151132.19678-1-enwlinux@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit f2cc0312f7affcb174874ea50c9d6540c2926b5b Author: Vivek Goyal Date: Tue Feb 9 17:47:54 2021 -0500 virtiofs: Fail dax mount if device does not support it [ Upstream commit 3f9b9efd82a84f27e95d0414f852caf1fa839e83 ] Right now "mount -t virtiofs -o dax myfs /mnt/virtiofs" succeeds even if filesystem deivce does not have a cache window and hence DAX can't be supported. This gives a false sense to user that they are using DAX with virtiofs but fact of the matter is that they are not. Fix this by returning error if dax can't be supported and user has asked for it. Signed-off-by: Vivek Goyal Reviewed-by: Stefan Hajnoczi Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 44b161598feb60634d937e2d2bf816bc5aced601 Author: Pavel Tatashin Date: Mon Mar 29 10:28:47 2021 -0400 arm64: mm: correct the inside linear map range during hotplug check [ Upstream commit ee7febce051945be28ad86d16a15886f878204de ] Memory hotplug may fail on systems with CONFIG_RANDOMIZE_BASE because the linear map range is not checked correctly. The start physical address that linear map covers can be actually at the end of the range because of randomization. Check that and if so reduce it to 0. This can be verified on QEMU with setting kaslr-seed to ~0ul: memstart_offset_seed = 0xffff START: __pa(_PAGE_OFFSET(vabits_actual)) = ffff9000c0000000 END: __pa(PAGE_END - 1) = 1000bfffffff Signed-off-by: Pavel Tatashin Fixes: 58284a901b42 ("arm64/mm: Validate hotplug range before creating linear mapping") Tested-by: Tyler Hicks Reviewed-by: Anshuman Khandual Link: https://lore.kernel.org/r/20210216150351.129018-2-pasha.tatashin@soleen.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin