commit fe024e004fa31dc64d18440c006b02cd8d722a03 Author: Greg Kroah-Hartman Date: Wed Oct 20 11:57:59 2021 +0200 Linux 5.14.14 Link: https://lore.kernel.org/r/20211018132340.682786018@linuxfoundation.org Tested-by: Fox Chen Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20211019061402.629202866@linuxfoundation.org Tested-by: Fox Chen Tested-by: Linux Kernel Functional Testing Tested-by: Salvatore Bonaccorso Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 9513ce07f05bfb6ccaad3bf61d0a4103bf3bbd86 Author: Shannon Nelson Date: Fri Oct 8 12:38:01 2021 -0700 ionic: don't remove netdev->dev_addr when syncing uc list commit 5c976a56570f29aaf4a2f9a1bf99789c252183c9 upstream. Bridging, and possibly other upper stack gizmos, adds the lower device's netdev->dev_addr to its own uc list, and then requests it be deleted when the upper bridge device is removed. This delete request also happens with the bridging vlan_filtering is enabled and then disabled. Bonding has a similar behavior with the uc list, but since it also uses set_mac to manage netdev->dev_addr, it doesn't have the same the failure case. Because we store our netdev->dev_addr in our uc list, we need to ignore the delete request from dev_uc_sync so as to not lose the address and all hope of communicating. Note that ndo_set_mac_address is expressly changing netdev->dev_addr, so no limitation is set there. Fixes: 2a654540be10 ("ionic: Add Rx filter and rx_mode ndo support") Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6b55eadb0b1da827f198364c426ace72c16c49b0 Author: Vladimir Oltean Date: Tue Oct 12 14:40:44 2021 +0300 net: dsa: felix: break at first CPU port during init and teardown commit 8d5f7954b7c8de54902a8beda141064a7e2e6ee0 upstream. The NXP LS1028A switch has two Ethernet ports towards the CPU, but only one of them is capable of acting as an NPI port at a time (inject and extract packets using DSA tags). However, using the alternative ocelot-8021q tagging protocol, it should be possible to use both CPU ports symmetrically, but for that we need to mark both ports in the device tree as DSA masters. In the process of doing that, it can be seen that traffic to/from the network stack gets broken, and this is because the Felix driver iterates through all DSA CPU ports and configures them as NPI ports. But since there can only be a single NPI port, we effectively end up in a situation where DSA thinks the default CPU port is the first one, but the hardware port configured to be an NPI is the last one. I would like to treat this as a bug, because if the updated device trees are going to start circulating, it would be really good for existing kernels to support them, too. Fixes: adb3dccf090b ("net: dsa: felix: convert to the new .change_tag_protocol DSA API") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9d2cec10ea9e1275138517c57c811982490b3bce Author: Vladimir Oltean Date: Tue Oct 12 14:40:39 2021 +0300 net: mscc: ocelot: cross-check the sequence id from the timestamp FIFO with the skb PTP header commit ebb4c6a990f786d7e0e4618a0d3766cd660125d8 upstream. The sad reality is that when a PTP frame with a TX timestamping request is transmitted, it isn't guaranteed that it will make it all the way to the wire (due to congestion inside the switch), and that a timestamp will be taken by the hardware and placed in the timestamp FIFO where an IRQ will be raised for it. The implication is that if enough PTP frames are silently dropped by the hardware such that the timestamp ID has rolled over, it is possible to match a timestamp to an old skb. Furthermore, nobody will match on the real skb corresponding to this timestamp, since we stupidly matched on a previous one that was stale in the queue, and stopped there. So PTP timestamping will be broken and there will be no way to recover. It looks like the hardware parses the sequenceID from the PTP header, and also provides that metadata for each timestamp. The driver currently ignores this, but it shouldn't. As an extra resiliency measure, do the following: - check whether the PTP sequenceID also matches between the skb and the timestamp, treat the skb as stale otherwise and free it - if we see a stale skb, don't stop there and try to match an skb one more time, chances are there's one more skb in the queue with the same timestamp ID, otherwise we wouldn't have ever found the stale one (it is by timestamp ID that we matched it). While this does not prevent PTP packet drops, it at least prevents the catastrophic consequences of incorrect timestamp matching. Since we already call ptp_classify_raw in the TX path, save the result in the skb->cb of the clone, and just use that result in the interrupt code path. Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support") Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 23a6801c058591b39564249b64ea97c6c64ef1be Author: Vladimir Oltean Date: Tue Oct 12 14:40:38 2021 +0300 net: mscc: ocelot: deny TX timestamping of non-PTP packets commit fba01283d85a09e0e2ef552c6e764b903111d90a upstream. It appears that Ocelot switches cannot timestamp non-PTP frames, I tested this using the isochron program at: https://github.com/vladimiroltean/tsn-scripts with the result that the driver increments the ocelot_port->ts_id counter as expected, puts it in the REW_OP, but the hardware seems to not timestamp these packets at all, since no IRQ is emitted. Therefore check whether we are sending PTP frames, and refuse to populate REW_OP otherwise. Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support") Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit de32ef6d79ddd3f4975e54a2e998e23bce8432d4 Author: Vladimir Oltean Date: Tue Oct 12 14:40:37 2021 +0300 net: mscc: ocelot: warn when a PTP IRQ is raised for an unknown skb commit 9fde506e0c53b8309f69b18b4b8144c544b4b3b1 upstream. When skb_match is NULL, it means we received a PTP IRQ for a timestamp ID that the kernel has no idea about, since there is no skb in the timestamping queue with that timestamp ID. This is a grave error and not something to just "continue" over. So print a big warning in case this happens. Also, move the check above ocelot_get_hwtimestamp(), there is no point in reading the full 64-bit current PTP time if we're not going to do anything with it anyway for this skb. Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3b4241817601a2f59beea471baa51763d7262232 Author: Vladimir Oltean Date: Tue Oct 12 14:40:36 2021 +0300 net: mscc: ocelot: avoid overflowing the PTP timestamp FIFO commit 52849bcf0029ccc553be304e4f804938a39112e2 upstream. PTP packets with 2-step TX timestamp requests are matched to packets based on the egress port number and a 6-bit timestamp identifier. All PTP timestamps are held in a common FIFO that is 128 entry deep. This patch ensures that back-to-back timestamping requests cannot exceed the hardware FIFO capacity. If that happens, simply send the packets without requesting a TX timestamp to be taken (in the case of felix, since the DSA API has a void return code in ds->ops->port_txtstamp) or drop them (in the case of ocelot). I've moved the ts_id_lock from a per-port basis to a per-switch basis, because we need separate accounting for both numbers of PTP frames in flight. And since we need locking to inc/dec the per-switch counter, that also offers protection for the per-port counter and hence there is no reason to have a per-port counter anymore. Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support") Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 34fd7a2e375a213c360b4707afaaf73d1ce2d1ed Author: Vladimir Oltean Date: Tue Oct 12 14:40:35 2021 +0300 net: mscc: ocelot: make use of all 63 PTP timestamp identifiers commit c57fe0037a4e3863d9b740f8c14df9c51ac31aa1 upstream. At present, there is a problem when user space bombards a port with PTP event frames which have TX timestamping requests (or when a tc-taprio offload is installed on a port, which delays the TX timestamps by a significant amount of time). The driver will happily roll over the 2-bit timestamp ID and this will cause incorrect matches between an skb and the TX timestamp collected from the FIFO. The Ocelot switches have a 6-bit PTP timestamp identifier, and the value 63 is reserved, so that leaves identifiers 0-62 to be used. The timestamp identifiers are selected by the REW_OP packet field, and are actually shared between CPU-injected frames and frames which match a VCAP IS2 rule that modifies the REW_OP. The hardware supports partitioning between the two uses of the REW_OP field through the PTP_ID_LOW and PTP_ID_HIGH registers, and by default reserves the PTP IDs 0-3 for CPU-injected traffic and the rest for VCAP IS2. The driver does not use VCAP IS2 to set REW_OP for 2-step timestamping, and it also writes 0xffffffff to both PTP_ID_HIGH and PTP_ID_LOW in ocelot_init_timestamp() which makes all timestamp identifiers available to CPU injection. Therefore, we can make use of all 63 timestamp identifiers, which should allow more timestampable packets to be in flight on each port. This is only part of the solution, more issues will be addressed in future changes. Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support") Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f7697d70d76b19b324e25ce5bee4a3bb05f18e0c Author: Baowen Zheng Date: Tue Oct 12 14:48:50 2021 +0200 nfp: flow_offload: move flow_indr_dev_register from app init to app start commit 60d950f443a52d950126ad664fbd4a1eb8353dc9 upstream. In commit 74fc4f828769 ("net: Fix offloading indirect devices dependency on qdisc order creation"), it adds a process to trigger the callback to setup the bo callback when the driver regists a callback. In our current implement, we are not ready to run the callback when nfp call the function flow_indr_dev_register, then there will be error message as: kernel: Oops: 0000 [#1] SMP PTI kernel: CPU: 0 PID: 14119 Comm: kworker/0:0 Tainted: G kernel: Workqueue: events work_for_cpu_fn kernel: RIP: 0010:nfp_flower_indr_setup_tc_cb+0x258/0x410 kernel: RSP: 0018:ffffbc1e02c57bf8 EFLAGS: 00010286 kernel: RAX: 0000000000000000 RBX: ffff9c761fabc000 RCX: 0000000000000001 kernel: RDX: 0000000000000001 RSI: fffffffffffffff0 RDI: ffffffffc0be9ef1 kernel: RBP: ffffbc1e02c57c58 R08: ffffffffc08f33aa R09: ffff9c6db7478800 kernel: R10: 0000009c003f6e00 R11: ffffbc1e02800000 R12: ffffbc1e000d9000 kernel: R13: ffffbc1e000db428 R14: ffff9c6db7478800 R15: ffff9c761e884e80 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: fffffffffffffff0 CR3: 00000009e260a004 CR4: 00000000007706f0 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 kernel: PKRU: 55555554 kernel: Call Trace: kernel: ? flow_indr_dev_register+0xab/0x210 kernel: ? __cond_resched+0x15/0x30 kernel: ? kmem_cache_alloc_trace+0x44/0x4b0 kernel: ? nfp_flower_setup_tc+0x1d0/0x1d0 [nfp] kernel: flow_indr_dev_register+0x158/0x210 kernel: ? tcf_block_unbind+0xe0/0xe0 kernel: nfp_flower_init+0x40b/0x650 [nfp] kernel: nfp_net_pci_probe+0x25f/0x960 [nfp] kernel: ? nfp_rtsym_read_le+0x76/0x130 [nfp] kernel: nfp_pci_probe+0x6a9/0x820 [nfp] kernel: local_pci_probe+0x45/0x80 So we need to call flow_indr_dev_register in app start process instead of init stage. Fixes: 74fc4f828769 ("net: Fix offloading indirect devices dependency on qdisc order creation") Signed-off-by: Baowen Zheng Signed-off-by: Simon Horman Signed-off-by: Louis Peens Link: https://lore.kernel.org/r/20211012124850.13025-1-louis.peens@corigine.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9d162f541ba3fd36a571dac74b604e57323ded4a Author: Dan Carpenter Date: Tue Oct 12 11:44:43 2021 +0300 block/rnbd-clt-sysfs: fix a couple uninitialized variable bugs commit 7904022decc260a19dd65b56ac896387f5da6f8c upstream. These variables are printed on the error path if match_int() fails so they have to be initialized. Fixes: 2958a995edc9 ("block/rnbd-clt: Support polling mode for IO latency optimization") Fixes: 1eb54f8f5dd8 ("block/rnbd: client: sysfs interface functions") Signed-off-by: Dan Carpenter Acked-by: Gioh Kim Link: https://lore.kernel.org/r/20211012084443.GA31472@kili Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 61616be899975404df44c20ab902464b60882cd7 Author: Jacob Keller Date: Mon Oct 11 13:48:06 2021 -0700 ice: fix locking for Tx timestamp tracking flush commit 4d4a223a86afe658cd878800f09458e8bb54415d upstream. Commit 4dd0d5c33c3e ("ice: add lock around Tx timestamp tracker flush") added a lock around the Tx timestamp tracker flow which is used to cleanup any left over SKBs and prepare for device removal. This lock is problematic because it is being held around a call to ice_clear_phy_tstamp. The clear function takes a mutex to send a PHY write command to firmware. This could lead to a deadlock if the mutex actually sleeps, and causes the following warning on a kernel with preemption debugging enabled: [ 715.419426] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:573 [ 715.427900] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 3100, name: rmmod [ 715.435652] INFO: lockdep is turned off. [ 715.439591] Preemption disabled at: [ 715.439594] [<0000000000000000>] 0x0 [ 715.446678] CPU: 52 PID: 3100 Comm: rmmod Tainted: G W OE 5.15.0-rc4+ #42 bdd7ec3018e725f159ca0d372ce8c2c0e784891c [ 715.458058] Hardware name: Intel Corporation S2600STQ/S2600STQ, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020 [ 715.468483] Call Trace: [ 715.470940] dump_stack_lvl+0x6a/0x9a [ 715.474613] ___might_sleep.cold+0x224/0x26a [ 715.478895] __mutex_lock+0xb3/0x1440 [ 715.482569] ? stack_depot_save+0x378/0x500 [ 715.486763] ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.494979] ? kfree+0xc1/0x520 [ 715.498128] ? mutex_lock_io_nested+0x12a0/0x12a0 [ 715.502837] ? kasan_set_free_info+0x20/0x30 [ 715.507110] ? __kasan_slab_free+0x10b/0x140 [ 715.511385] ? slab_free_freelist_hook+0xc7/0x220 [ 715.516092] ? kfree+0xc1/0x520 [ 715.519235] ? ice_deinit_lag+0x16c/0x220 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.527359] ? ice_remove+0x1cf/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.535133] ? pci_device_remove+0xab/0x1d0 [ 715.539318] ? __device_release_driver+0x35b/0x690 [ 715.544110] ? driver_detach+0x214/0x2f0 [ 715.548035] ? bus_remove_driver+0x11d/0x2f0 [ 715.552309] ? pci_unregister_driver+0x26/0x250 [ 715.556840] ? ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.564799] ? __do_sys_delete_module.constprop.0+0x2d8/0x4e0 [ 715.570554] ? do_syscall_64+0x3b/0x90 [ 715.574303] ? entry_SYSCALL_64_after_hwframe+0x44/0xae [ 715.579529] ? start_flush_work+0x542/0x8f0 [ 715.583719] ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.591923] ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.599960] ? wait_for_completion_io+0x250/0x250 [ 715.604662] ? lock_acquire+0x196/0x200 [ 715.608504] ? do_raw_spin_trylock+0xa5/0x160 [ 715.612864] ice_sbq_rw_reg+0x1e6/0x2f0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.620813] ? ice_reset+0x130/0x130 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.628497] ? __debug_check_no_obj_freed+0x1e8/0x3c0 [ 715.633550] ? trace_hardirqs_on+0x1c/0x130 [ 715.637748] ice_write_phy_reg_e810+0x70/0xf0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.646220] ? do_raw_spin_trylock+0xa5/0x160 [ 715.650581] ? ice_ptp_release+0x910/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.658797] ? ice_ptp_release+0x255/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.667013] ice_clear_phy_tstamp+0x2c/0x110 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.675403] ice_ptp_release+0x408/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.683440] ice_remove+0x560/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.691037] ? _raw_spin_unlock_irqrestore+0x46/0x73 [ 715.696005] pci_device_remove+0xab/0x1d0 [ 715.700018] __device_release_driver+0x35b/0x690 [ 715.704637] driver_detach+0x214/0x2f0 [ 715.708389] bus_remove_driver+0x11d/0x2f0 [ 715.712489] pci_unregister_driver+0x26/0x250 [ 715.716857] ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.724637] __do_sys_delete_module.constprop.0+0x2d8/0x4e0 [ 715.730210] ? free_module+0x6d0/0x6d0 [ 715.733963] ? task_work_run+0xe1/0x170 [ 715.737803] ? exit_to_user_mode_loop+0x17f/0x1d0 [ 715.742509] ? rcu_read_lock_sched_held+0x12/0x80 [ 715.747215] ? trace_hardirqs_on+0x1c/0x130 [ 715.751401] do_syscall_64+0x3b/0x90 [ 715.754981] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 715.760033] RIP: 0033:0x7f4dfe59000b [ 715.763612] Code: 73 01 c3 48 8b 0d 6d 1e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 1e 0c 00 f7 d8 64 89 01 48 [ 715.782357] RSP: 002b:00007ffe8c891708 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 715.789923] RAX: ffffffffffffffda RBX: 00005558a20468b0 RCX: 00007f4dfe59000b [ 715.797054] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005558a2046918 [ 715.804189] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 715.811319] R10: 00007f4dfe603ac0 R11: 0000000000000206 R12: 00007ffe8c891940 [ 715.818455] R13: 00007ffe8c8920a3 R14: 00005558a20462a0 R15: 00005558a20468b0 Notice that this is the only case where we use the lock in this way. In the cleanup kthread and work kthread the lock is only taken around the bit accesses. This was done intentionally to avoid this kind of issue. The way the lock is used, we only protect ordering of bit sets vs bit clears. The Tx writers in the hot path don't need to be protected against the entire kthread loop. The Tx queues threads only need to ensure that they do not re-use an index that is currently in use. The cleanup loop does not need to block all new set bits, since it will re-queue itself if new timestamps are present. Fix the tracker flow so that it uses the same flow as the standard cleanup thread. In addition, ensure the in_use bitmap actually gets cleared properly. This fixes the warning and also avoids the potential deadlock that might have occurred otherwise. Fixes: 4dd0d5c33c3e ("ice: add lock around Tx timestamp tracker flush") Signed-off-by: Jacob Keller Signed-off-by: Tony Nguyen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 99eef638a32736017456aae46401bb2c11bd3568 Author: Vegard Nossum Date: Mon Oct 11 17:22:49 2021 +0200 r8152: select CRC32 and CRYPTO/CRYPTO_HASH/CRYPTO_SHA256 commit 9973a43012b6ad1720dbc4d5faf5302c28635b8c upstream. Fix the following build/link errors by adding a dependency on CRYPTO, CRYPTO_HASH, CRYPTO_SHA256 and CRC32: ld: drivers/net/usb/r8152.o: in function `rtl8152_fw_verify_checksum': r8152.c:(.text+0x2b2a): undefined reference to `crypto_alloc_shash' ld: r8152.c:(.text+0x2bed): undefined reference to `crypto_shash_digest' ld: r8152.c:(.text+0x2c50): undefined reference to `crypto_destroy_tfm' ld: drivers/net/usb/r8152.o: in function `_rtl8152_set_rx_mode': r8152.c:(.text+0xdcb0): undefined reference to `crc32_le' Fixes: 9370f2d05a2a1 ("r8152: support request_firmware for RTL8153") Fixes: ac718b69301c7 ("net/usb: new driver for RTL8152") Signed-off-by: Vegard Nossum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 821dca5635e2c02221bc0f5a8d1aa45a09f3c013 Author: chongjiapeng Date: Sat Oct 9 16:09:26 2021 +0800 qed: Fix missing error code in qed_slowpath_start() commit a5a14ea7b4e55604acb0dc9d88fdb4cb6945bc77 upstream. The error code is missing in this code scenario, add the error code '-EINVAL' to the return value 'rc'. Eliminate the follow smatch warning: drivers/net/ethernet/qlogic/qed/qed_main.c:1298 qed_slowpath_start() warn: missing error code 'rc'. Reported-by: Abaci Robot Fixes: d51e4af5c209 ("qed: aRFS infrastructure support") Signed-off-by: chongjiapeng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1a4554e94f0deff9fc1dc5addf93fa579cc29711 Author: Paolo Abeni Date: Thu Oct 7 15:05:00 2021 -0700 mptcp: fix possible stall on recvmsg() commit 612f71d7328c14369924384ad2170aae2a6abd92 upstream. recvmsg() can enter an infinite loop if the caller provides the MSG_WAITALL, the data present in the receive queue is not sufficient to fulfill the request, and no more data is received by the peer. When the above happens, mptcp_wait_data() will always return with no wait, as the MPTCP_DATA_READY flag checked by such function is set and never cleared in such code path. Leveraging the above syzbot was able to trigger an RCU stall: rcu: INFO: rcu_preempt self-detected stall on CPU rcu: 0-...!: (10499 ticks this GP) idle=0af/1/0x4000000000000000 softirq=10678/10678 fqs=1 (t=10500 jiffies g=13089 q=109) rcu: rcu_preempt kthread starved for 10497 jiffies! g13089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. rcu: RCU grace-period kthread stack dump: task:rcu_preempt state:R running task stack:28696 pid: 14 ppid: 2 flags:0x00004000 Call Trace: context_switch kernel/sched/core.c:4955 [inline] __schedule+0x940/0x26f0 kernel/sched/core.c:6236 schedule+0xd3/0x270 kernel/sched/core.c:6315 schedule_timeout+0x14a/0x2a0 kernel/time/timer.c:1881 rcu_gp_fqs_loop+0x186/0x810 kernel/rcu/tree.c:1955 rcu_gp_kthread+0x1de/0x320 kernel/rcu/tree.c:2128 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 rcu: Stack dump where RCU GP kthread last ran: Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 8510 Comm: syz-executor827 Not tainted 5.15.0-rc2-next-20210920-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:84 [inline] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:102 [inline] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:128 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:159 [inline] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline] RIP: 0010:kasan_check_range+0xc8/0x180 mm/kasan/generic.c:189 Code: 38 00 74 ed 48 8d 50 08 eb 09 48 83 c0 01 48 39 d0 74 7a 80 38 00 74 f2 48 89 c2 b8 01 00 00 00 48 85 d2 75 56 5b 5d 41 5c c3 <48> 85 d2 74 5e 48 01 ea eb 09 48 83 c0 01 48 39 d0 74 50 80 38 00 RSP: 0018:ffffc9000cd676c8 EFLAGS: 00000283 RAX: ffffed100e9a110e RBX: ffffed100e9a110f RCX: ffffffff88ea062a RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888074d08870 RBP: ffffed100e9a110e R08: 0000000000000001 R09: ffff888074d08877 R10: ffffed100e9a110e R11: 0000000000000000 R12: ffff888074d08000 R13: ffff888074d08000 R14: ffff888074d08088 R15: ffff888074d08000 FS: 0000555556d8e300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 S: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000068909000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: instrument_atomic_read_write include/linux/instrumented.h:101 [inline] test_and_clear_bit include/asm-generic/bitops/instrumented-atomic.h:83 [inline] mptcp_release_cb+0x14a/0x210 net/mptcp/protocol.c:3016 release_sock+0xb4/0x1b0 net/core/sock.c:3204 mptcp_wait_data net/mptcp/protocol.c:1770 [inline] mptcp_recvmsg+0xfd1/0x27b0 net/mptcp/protocol.c:2080 inet6_recvmsg+0x11b/0x5e0 net/ipv6/af_inet6.c:659 sock_recvmsg_nosec net/socket.c:944 [inline] ____sys_recvmsg+0x527/0x600 net/socket.c:2626 ___sys_recvmsg+0x127/0x200 net/socket.c:2670 do_recvmmsg+0x24d/0x6d0 net/socket.c:2764 __sys_recvmmsg net/socket.c:2843 [inline] __do_sys_recvmmsg net/socket.c:2866 [inline] __se_sys_recvmmsg net/socket.c:2859 [inline] __x64_sys_recvmmsg+0x20b/0x260 net/socket.c:2859 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fc200d2dc39 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc5758e5a8 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc200d2dc39 RDX: 0000000000000002 RSI: 00000000200017c0 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000f0b5ff R10: 0000000000000100 R11: 0000000000000246 R12: 0000000000000003 R13: 00007ffc5758e5d0 R14: 00007ffc5758e5c0 R15: 0000000000000003 Fix the issue by replacing the MPTCP_DATA_READY bit with direct inspection of the msk receive queue. Reported-and-tested-by: syzbot+3360da629681aa0d22fe@syzkaller.appspotmail.com Fixes: 7a6a6cbc3e59 ("mptcp: recvmsg() can drain data from multiple subflow") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4fd74935619f37f00fb9a84a7aabccffe2e13390 Author: Sebastian Andrzej Siewior Date: Thu Oct 7 19:49:57 2021 +0200 mqprio: Correct stats in mqprio_dump_class_stats(). commit 14132690860e4d06aa3e1c4d7d8e9866ba7756dd upstream. Introduction of lockless subqueues broke the class statistics. Before the change stats were accumulated in `bstats' and `qstats' on the stack which was then copied to struct gnet_dump. After the change the `bstats' and `qstats' are initialized to 0 and never updated, yet still fed to gnet_dump. The code updates the global qdisc->cpu_bstats and qdisc->cpu_qstats instead, clobbering them. Most likely a copy-paste error from the code in mqprio_dump(). __gnet_stats_copy_basic() and __gnet_stats_copy_queue() accumulate the values for per-CPU case but for global stats they overwrite the value, so only stats from the last loop iteration / tc end up in sch->[bq]stats. Use the on-stack [bq]stats variables again and add the stats manually in the global case. Fixes: ce679e8df7ed2 ("net: sched: add support for TCQ_F_NOLOCK subqueues to sch_mqprio") Cc: John Fastabend Signed-off-by: Sebastian Andrzej Siewior https://lore.kernel.org/all/20211007175000.2334713-2-bigeasy@linutronix.de/ Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 395218b5c7e0c0e21382a2bc9a7469a0bf7a7bd0 Author: Prashant Malani Date: Tue Sep 28 03:19:30 2021 -0700 platform/x86: intel_scu_ipc: Fix busy loop expiry time commit 41512e4dc0b84525495e784295092592adb87f1b upstream. The macro IPC_TIMEOUT is already in jiffies (it is also used like that elsewhere in the file when calling wait_for_completion_timeout()). Don’t convert it using helper functions for the purposes of calculating the busy loop expiry time. Fixes: e7b7ab3847c9 (“platform/x86: intel_scu_ipc: Sleeping is fine when polling”) Signed-off-by: Prashant Malani Cc: Benson Leung Reviewed-by: Mika Westerberg Link: https://lore.kernel.org/r/20210928101932.2543937-2-pmalani@chromium.org Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit b4fb645a7412193267d9865ef6ce25671b967d4b Author: Jackie Liu Date: Mon Aug 23 17:25:26 2021 +0800 acpi/arm64: fix next_platform_timer() section mismatch error commit 596143e3aec35c93508d6b7a05ddc999ee209b61 upstream. Fix modpost Section mismatch error in next_platform_timer(). [...] WARNING: modpost: vmlinux.o(.text.unlikely+0x26e60): Section mismatch in reference from the function next_platform_timer() to the variable .init.data:acpi_gtdt_desc The function next_platform_timer() references the variable __initdata acpi_gtdt_desc. This is often because next_platform_timer lacks a __initdata annotation or the annotation of acpi_gtdt_desc is wrong. WARNING: modpost: vmlinux.o(.text.unlikely+0x26e64): Section mismatch in reference from the function next_platform_timer() to the variable .init.data:acpi_gtdt_desc The function next_platform_timer() references the variable __initdata acpi_gtdt_desc. This is often because next_platform_timer lacks a __initdata annotation or the annotation of acpi_gtdt_desc is wrong. ERROR: modpost: Section mismatches detected. Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them. make[1]: *** [scripts/Makefile.modpost:59: vmlinux.symvers] Error 1 make[1]: *** Deleting file 'vmlinux.symvers' make: *** [Makefile:1176: vmlinux] Error 2 [...] Fixes: a712c3ed9b8a ("acpi/arm64: Add memory-mapped timer support in GTDT driver") Signed-off-by: Jackie Liu Acked-by: Hanjun Guo Link: https://lore.kernel.org/r/20210823092526.2407526-1-liu.yun@linux.dev Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 6302ce26ecebfd483c7ec516057a1990c793d575 Author: Dan Carpenter Date: Fri Oct 1 15:34:09 2021 +0300 drm/msm/dsi: fix off by one in dsi_bus_clk_enable error handling commit c8f01ffc83923a91e8087aaa077de13354a7aa59 upstream. This disables a lock which wasn't enabled and it does not disable the first lock in the array. Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list") Signed-off-by: Dan Carpenter Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20211001123409.GG2283@kili Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 3c403c4c058005054b3a704257aabc31b8fd6e59 Author: Dan Carpenter Date: Fri Oct 1 15:33:08 2021 +0300 drm/msm/dsi: Fix an error code in msm_dsi_modeset_init() commit 739b4e7756d3301dd673ca517afca46a5f635562 upstream. Return an error code if msm_dsi_manager_validate_current_config(). Don't return success. Fixes: 8b03ad30e314 ("drm/msm/dsi: Use one connector for dual DSI mode") Signed-off-by: Dan Carpenter Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20211001123308.GF2283@kili Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit f1457eea4ccd00429301454456a21db622cf5ec3 Author: Marijn Suijten Date: Mon Sep 6 22:25:51 2021 +0200 drm/msm/dsi: dsi_phy_14nm: Take ready-bit into account in poll_for_ready commit 90b7c1c66132c20e8a550006011a3cbfb73dbfc1 upstream. The downstream driver models this PLL lock check as an if-elseif-else. The only way to reach the else case where pll_locked=true [1] is by succeeding both readl_poll_timeout_atomic calls (which return zero on success) in the if _and_ elseif condition. Hence both the "lock" and "ready" bit need to be tested in the SM_READY_STATUS register before considering the PLL locked and ready to go. Tested on the Sony Xperia XA2 Ultra (nile-discovery, sdm630). [1]: https://source.codeaurora.org/quic/la/kernel/msm-4.19/tree/drivers/clk/qcom/mdss/mdss-dsi-pll-14nm-util.c?h=LA.UM.9.2.1.r1-08000-sdm660.0#n302 Fixes: f079f6d999cb ("drm/msm/dsi: Add PHY/PLL for 8x96") Signed-off-by: Marijn Suijten Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210906202552.824598-1-marijn.suijten@somainline.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit d59e44e7821a8f2bb6f2e846b9167397a5f01608 Author: Dan Carpenter Date: Fri Oct 1 15:59:04 2021 +0300 drm/msm/a3xx: fix error handling in a3xx_gpu_init() commit 3eda901995371d390ef82d0b6462f4ea8efbcfdf upstream. These error paths returned 1 on failure, instead of a negative error code. This would lead to an Oops in the caller. A second problem is that the check for "if (ret != -ENODATA)" did not work because "ret" was set to 1. Fixes: 5785dd7a8ef0 ("drm/msm: Fix duplicate gpu node in icc summary") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20211001125904.GK2283@kili Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 3962d626eb3e3b23ebb2e2a61537fa764acbfe11 Author: Dan Carpenter Date: Fri Oct 1 15:57:59 2021 +0300 drm/msm/a4xx: fix error handling in a4xx_gpu_init() commit 980d74e7d03ccf2eaa11d133416946bd880c7c08 upstream. This code returns 1 on error instead of a negative error. It leads to an Oops in the caller. A second problem is that the check for "if (ret != -ENODATA)" cannot be true because "ret" is set to 1. Fixes: 5785dd7a8ef0 ("drm/msm: Fix duplicate gpu node in icc summary") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20211001125759.GJ2283@kili Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 20cfa89cd7e1274268b23306a73fa496b6fe83cf Author: Rob Clark Date: Thu Sep 30 10:43:20 2021 -0700 drm/msm/a6xx: Track current ctx by seqno commit 14eb0cb4e9a7323c8735cf6c681ed8423ce6ae06 upstream. In theory a context can be destroyed and a new one allocated at the same address, making the pointer comparision to detect when we don't need to update the current pagetables invalid. Instead assign a sequence number to each context on creation, and use this for the check. Fixes: 84c31ee16f90 ("drm/msm/a6xx: Add support for per-instance pagetables") Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 00ba7a3951f4ea7c91b29e2bfbb3a4ecf72bf542 Author: Arnd Bergmann Date: Mon Sep 27 13:36:23 2021 +0200 drm/msm/submit: fix overflow check on 64-bit architectures commit 95c58291ee709424557996891926a05a32c5b13a upstream. The overflow check does causes a warning from clang-14 when 'sz' is a type that is smaller than size_t: drivers/gpu/drm/msm/msm_gem_submit.c:217:10: error: result of comparison of constant 18446744073709551615 with expression of type 'unsigned int' is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (sz == SIZE_MAX) { Change the type accordingly. Fixes: 20224d715a88 ("drm/msm/submit: Move copy_from_user ahead of locking bos") Signed-off-by: Arnd Bergmann Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20210927113632.3849987-1-arnd@kernel.org Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 2d28dafbc88e26250b1332c8acf650ff280eccbd Author: Dmitry Baryshkov Date: Sat Sep 25 22:28:24 2021 +0300 drm/msm/mdp5: fix cursor-related warnings commit c491a0c7bbf3a64732cb8414021429d15ec08eec upstream. Since f35a2a99100f ("drm/encoder: make encoder control functions optional") drm_mode_config_validate would print warnings if both cursor plane and cursor functions are provided. Restore separate set of drm_crtc_funcs to be used if separate cursor plane is provided. [ 6.556046] ------------[ cut here ]------------ [ 6.556071] [CRTC:93:crtc-0] must not have both a cursor plane and a cursor_set func [ 6.556091] WARNING: CPU: 1 PID: 76 at drivers/gpu/drm/drm_mode_config.c:648 drm_mode_config_validate+0x238/0x4d0 [ 6.567453] Modules linked in: [ 6.577604] CPU: 1 PID: 76 Comm: kworker/u8:2 Not tainted 5.15.0-rc1-dirty #43 [ 6.580557] Hardware name: Qualcomm Technologies, Inc. DB820c (DT) [ 6.587763] Workqueue: events_unbound deferred_probe_work_func [ 6.593926] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 6.599740] pc : drm_mode_config_validate+0x238/0x4d0 [ 6.606596] lr : drm_mode_config_validate+0x238/0x4d0 [ 6.611804] sp : ffff8000121b3980 [ 6.616838] x29: ffff8000121b3990 x28: 0000000000000000 x27: 0000000000000001 [ 6.620140] x26: ffff8000114cde50 x25: ffff8000114cdd40 x24: ffff0000987282d8 [ 6.627258] x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000001 [ 6.634376] x20: ffff000098728000 x19: ffff000080a39000 x18: ffffffffffffffff [ 6.641494] x17: 3136564e3631564e x16: 0000000000000324 x15: ffff800011c78709 [ 6.648613] x14: 0000000000000000 x13: ffff800011a22850 x12: 00000000000009ab [ 6.655730] x11: 0000000000000339 x10: ffff800011a22850 x9 : ffff800011a22850 [ 6.662848] x8 : 00000000ffffefff x7 : ffff800011a7a850 x6 : ffff800011a7a850 [ 6.669966] x5 : 000000000000bff4 x4 : 40000000fffff339 x3 : 0000000000000000 [ 6.677084] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008093b800 [ 6.684205] Call trace: [ 6.691319] drm_mode_config_validate+0x238/0x4d0 [ 6.693577] drm_dev_register+0x17c/0x210 [ 6.698435] msm_drm_bind+0x4b4/0x694 [ 6.702429] try_to_bring_up_master+0x164/0x1d0 [ 6.706075] __component_add+0xa0/0x170 [ 6.710415] component_add+0x14/0x20 [ 6.714234] msm_hdmi_dev_probe+0x1c/0x2c [ 6.718053] platform_probe+0x68/0xe0 [ 6.721959] really_probe.part.0+0x9c/0x30c [ 6.725606] __driver_probe_device+0x98/0x144 [ 6.729600] driver_probe_device+0xc8/0x15c [ 6.734114] __device_attach_driver+0xb4/0x120 [ 6.738106] bus_for_each_drv+0x78/0xd0 [ 6.742619] __device_attach+0xdc/0x184 [ 6.746351] device_initial_probe+0x14/0x20 [ 6.750172] bus_probe_device+0x9c/0xa4 [ 6.754337] deferred_probe_work_func+0x88/0xc0 [ 6.758158] process_one_work+0x1d0/0x370 [ 6.762671] worker_thread+0x2c8/0x470 [ 6.766839] kthread+0x15c/0x170 [ 6.770483] ret_from_fork+0x10/0x20 [ 6.773870] ---[ end trace 5884eb76cd26d274 ]--- [ 6.777500] ------------[ cut here ]------------ [ 6.782043] [CRTC:93:crtc-0] must not have both a cursor plane and a cursor_move func [ 6.782063] WARNING: CPU: 1 PID: 76 at drivers/gpu/drm/drm_mode_config.c:654 drm_mode_config_validate+0x290/0x4d0 [ 6.794362] Modules linked in: [ 6.804600] CPU: 1 PID: 76 Comm: kworker/u8:2 Tainted: G W 5.15.0-rc1-dirty #43 [ 6.807555] Hardware name: Qualcomm Technologies, Inc. DB820c (DT) [ 6.816148] Workqueue: events_unbound deferred_probe_work_func [ 6.822311] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 6.828126] pc : drm_mode_config_validate+0x290/0x4d0 [ 6.834981] lr : drm_mode_config_validate+0x290/0x4d0 [ 6.840189] sp : ffff8000121b3980 [ 6.845223] x29: ffff8000121b3990 x28: 0000000000000000 x27: 0000000000000001 [ 6.848525] x26: ffff8000114cde50 x25: ffff8000114cdd40 x24: ffff0000987282d8 [ 6.855643] x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000001 [ 6.862763] x20: ffff000098728000 x19: ffff000080a39000 x18: ffffffffffffffff [ 6.869879] x17: 3136564e3631564e x16: 0000000000000324 x15: ffff800011c790c2 [ 6.876998] x14: 0000000000000000 x13: ffff800011a22850 x12: 0000000000000a2f [ 6.884116] x11: 0000000000000365 x10: ffff800011a22850 x9 : ffff800011a22850 [ 6.891234] x8 : 00000000ffffefff x7 : ffff800011a7a850 x6 : ffff800011a7a850 [ 6.898351] x5 : 000000000000bff4 x4 : 40000000fffff365 x3 : 0000000000000000 [ 6.905470] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008093b800 [ 6.912590] Call trace: [ 6.919702] drm_mode_config_validate+0x290/0x4d0 [ 6.921960] drm_dev_register+0x17c/0x210 [ 6.926821] msm_drm_bind+0x4b4/0x694 [ 6.930813] try_to_bring_up_master+0x164/0x1d0 [ 6.934459] __component_add+0xa0/0x170 [ 6.938799] component_add+0x14/0x20 [ 6.942619] msm_hdmi_dev_probe+0x1c/0x2c [ 6.946438] platform_probe+0x68/0xe0 [ 6.950345] really_probe.part.0+0x9c/0x30c [ 6.953991] __driver_probe_device+0x98/0x144 [ 6.957984] driver_probe_device+0xc8/0x15c [ 6.962498] __device_attach_driver+0xb4/0x120 [ 6.966492] bus_for_each_drv+0x78/0xd0 [ 6.971004] __device_attach+0xdc/0x184 [ 6.974737] device_initial_probe+0x14/0x20 [ 6.978556] bus_probe_device+0x9c/0xa4 [ 6.982722] deferred_probe_work_func+0x88/0xc0 [ 6.986543] process_one_work+0x1d0/0x370 [ 6.991057] worker_thread+0x2c8/0x470 [ 6.995223] kthread+0x15c/0x170 [ 6.998869] ret_from_fork+0x10/0x20 [ 7.002255] ---[ end trace 5884eb76cd26d275 ]--- Fixes: aa649e875daf ("drm/msm/mdp5: mdp5_crtc: Restore cursor state only if LM cursors are enabled") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210925192824.3416259-1-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 46c8ddede0273d1d132beefa9de8b820326982be Author: Colin Ian King Date: Wed Sep 29 13:18:57 2021 +0100 drm/msm: Fix null pointer dereference on pointer edp commit 2133c4fc8e1348dcb752f267a143fe2254613b34 upstream. The initialization of pointer dev dereferences pointer edp before edp is null checked, so there is a potential null pointer deference issue. Fix this by only dereferencing edp after edp has been null checked. Addresses-Coverity: ("Dereference before null check") Fixes: ab5b0107ccf3 ("drm/msm: Initial add eDP support in msm drm driver (v5)") Signed-off-by: Colin Ian King Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210929121857.213922-1-colin.king@canonical.com Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 09f3946bb452918dbfb1982add56f9ffaae393dc Author: Douglas Anderson Date: Tue Oct 5 19:29:08 2021 -0700 drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read commit 97794170b696856483f74b47bfb6049780d2d3a0 upstream. In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test") the function connector_bad_edid() started assuming that the memory for the EDID passed to it was big enough to hold `edid[0x7e] + 1` blocks of data (1 extra for the base block). It completely ignored the fact that the function was passed `num_blocks` which indicated how much memory had been allocated for the EDID. Let's fix this by adding a bounds check. This is important for handling the case where there's an error in the first block of the EDID. In that case we will call connector_bad_edid() without having re-allocated memory based on `edid[0x7e]`. Fixes: e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test") Reported-by: Ville Syrjälä Signed-off-by: Douglas Anderson Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20211005192905.v2.1.Ib059f9c23c2611cb5a9d760e7d0a700c1295928d@changeid Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 8b0462c25effc97367890bfee38862164ee2df71 Author: Vegard Nossum Date: Tue Oct 12 13:52:42 2021 +0200 drm/panel: olimex-lcd-olinuxino: select CRC32 commit a14bc107edd0c108bda2245e50daa22f91c95d20 upstream. Fix the following build/link error by adding a dependency on the CRC32 routines: ld: drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.o: in function `lcd_olinuxino_probe': panel-olimex-lcd-olinuxino.c:(.text+0x303): undefined reference to `crc32_le' Fixes: 17fd7a9d324fd ("drm/panel: Add support for Olimex LCD-OLinuXino panel") Cc: Arnd Bergmann Signed-off-by: Vegard Nossum Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20211012115242.10325-1-vegard.nossum@oracle.com Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit dc4f4acadabf09096a80e1ae1286cf236894ebfe Author: Kamal Dasu Date: Fri Oct 8 16:36:02 2021 -0400 spi: bcm-qspi: clear MSPI spifie interrupt during probe commit 75b3cb97eb1f05042745c0655a7145b0262d4c5c upstream. Intermittent Kernel crash has been observed on probe in bcm_qspi_mspi_l2_isr() handler when the MSPI spifie interrupt bit has not been cleared before registering for interrupts. Fix the driver to move SoC specific custom interrupt handling code before we register IRQ in probe. Also clear MSPI interrupt status resgiter prior to registering IRQ handlers. Fixes: cc20a38612db ("spi: iproc-qspi: Add Broadcom iProc SoCs support") Signed-off-by: Kamal Dasu Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/20211008203603.40915-3-kdasu.kdev@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2a51f25a7ed94fdfb61388968cbe1d1fe3fda9ff Author: Mark Brown Date: Thu Sep 23 18:00:23 2021 +0100 spi: spidev: Add SPI ID table commit 6840615f85f6046039ebc4989870ddb12892b7fc upstream. Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding an id_table listing the SPI IDs for everything. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210923170023.1683-1-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b461c85534740c2a6de35ca61a1991ab6203db13 Author: Vadim Pasternak Date: Mon Sep 27 17:22:14 2021 +0300 platform/mellanox: mlxreg-io: Fix read access of n-bytes size attributes commit db9cc7d6f95e7d89b0ce57e785cfd9d67a7505d8 upstream. Fix shift argument for function rol32(). It should be provided in bits, while was provided in bytes. Fixes: 86148190a7db ("platform/mellanox: mlxreg-io: Add support for complex attributes") Signed-off-by: Vadim Pasternak Link: https://lore.kernel.org/r/20210927142214.2613929-3-vadimp@nvidia.com Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 1da4f33681b5306c0a40d896eb47da9d349474e8 Author: Vadim Pasternak Date: Mon Sep 27 17:22:13 2021 +0300 platform/mellanox: mlxreg-io: Fix argument base in kstrtou32() call commit 9b024201693e397441668cca0d2df7055fe572eb upstream. Change kstrtou32() argument 'base' to be zero instead of 'len'. It works by chance for setting one bit value, but it is not supposed to work in case value passed to mlxreg_io_attr_store() is greater than 1. It works for example, for: echo 1 > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable But it will fail for: echo n > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable, where n > 1. The flow for input buffer conversion is as below: _kstrtoull(const char *s, unsigned int base, unsigned long long *res) calls: rv = _parse_integer(s, base, &_res); For the second case, where n > 1: - _parse_integer() converts 's' to 'val'. For n=2, 'len' is set to 2 (string buffer is 0x32 0x0a), for n=3 'len' is set to 3 (string buffer 0x33 0x0a), etcetera. - 'base' is equal or greater then '2' (length of input buffer). As a result, _parse_integer() exits with result zero (rv): rv = 0; while (1) { ... if (val >= base)-> (2 >= 2) break; ... rv++; ... } And _kstrtoull() in their turn will fail: if (rv == 0) return -EINVAL; Fixes: 5ec4a8ace06c ("platform/mellanox: Introduce support for Mellanox register access driver") Signed-off-by: Vadim Pasternak Link: https://lore.kernel.org/r/20210927142214.2613929-2-vadimp@nvidia.com Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit df8e58716afb3bee2b59de66b1ba1033f2e26303 Author: Ido Schimmel Date: Tue Oct 12 20:49:55 2021 +0300 mlxsw: thermal: Fix out-of-bounds memory accesses commit 332fdf951df8b870e3da86b122ae304e2aabe88c upstream. Currently, mlxsw allows cooling states to be set above the maximum cooling state supported by the driver: # cat /sys/class/thermal/thermal_zone2/cdev0/type mlxsw_fan # cat /sys/class/thermal/thermal_zone2/cdev0/max_state 10 # echo 18 > /sys/class/thermal/thermal_zone2/cdev0/cur_state # echo $? 0 This results in out-of-bounds memory accesses when thermal state transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the transition table is accessed with a too large index (state) [1]. According to the thermal maintainer, it is the responsibility of the driver to reject such operations [2]. Therefore, return an error when the state to be set exceeds the maximum cooling state supported by the driver. To avoid dead code, as suggested by the thermal maintainer [3], partially revert commit a421ce088ac8 ("mlxsw: core: Extend cooling device with cooling levels") that tried to interpret these invalid cooling states (above the maximum) in a special way. The cooling levels array is not removed in order to prevent the fans going below 20% PWM, which would cause them to get stuck at 0% PWM. [1] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290 Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5 CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122 Hardware name: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 03/08/2016 Workqueue: events_freezable_power_ thermal_zone_device_check Call Trace: dump_stack_lvl+0x8b/0xb3 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b thermal_cooling_device_stats_update+0x271/0x290 __thermal_cdev_update+0x15e/0x4e0 thermal_cdev_update+0x9f/0xe0 step_wise_throttle+0x770/0xee0 thermal_zone_device_update+0x3f6/0xdf0 process_one_work+0xa42/0x1770 worker_thread+0x62f/0x13e0 kthread+0x3ee/0x4e0 ret_from_fork+0x1f/0x30 Allocated by task 1: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 thermal_cooling_device_setup_sysfs+0x153/0x2c0 __thermal_cooling_device_register.part.0+0x25b/0x9c0 thermal_cooling_device_register+0xb3/0x100 mlxsw_thermal_init+0x5c5/0x7e0 __mlxsw_core_bus_device_register+0xcb3/0x19c0 mlxsw_core_bus_device_register+0x56/0xb0 mlxsw_pci_probe+0x54f/0x710 local_pci_probe+0xc6/0x170 pci_device_probe+0x2b2/0x4d0 really_probe+0x293/0xd10 __driver_probe_device+0x2af/0x440 driver_probe_device+0x51/0x1e0 __driver_attach+0x21b/0x530 bus_for_each_dev+0x14c/0x1d0 bus_add_driver+0x3ac/0x650 driver_register+0x241/0x3d0 mlxsw_sp_module_init+0xa2/0x174 do_one_initcall+0xee/0x5f0 kernel_init_freeable+0x45a/0x4de kernel_init+0x1f/0x210 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff8881052f7800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 1016 bytes inside of 1024-byte region [ffff8881052f7800, ffff8881052f7c00) The buggy address belongs to the page: page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0 head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x200000000010200(slab|head|node=0|zone=2) raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67-1895-1fdc45c0244e@linaro.org/ [3] https://lore.kernel.org/linux-pm/af9857f2-578e-de3a-e62b-6baff7e69fd4@linaro.org/ CC: Daniel Lezcano Fixes: a50c1e35650b ("mlxsw: core: Implement thermal zone") Fixes: a421ce088ac8 ("mlxsw: core: Extend cooling device with cooling levels") Signed-off-by: Ido Schimmel Tested-by: Vadim Pasternak Link: https://lore.kernel.org/r/20211012174955.472928-1-idosch@idosch.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2d14f8a9f1b7dc04dfdf36d381d6d8f7ae1ad366 Author: Wang Hai Date: Wed Oct 13 14:16:31 2021 +0800 ata: ahci_platform: fix null-ptr-deref in ahci_platform_enable_regulators() commit 776c75010803849c1cc4f11031a2b3960ab05202 upstream. I got a null-ptr-deref report: KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] ... RIP: 0010:regulator_enable+0x84/0x260 ... Call Trace: ahci_platform_enable_regulators+0xae/0x320 ahci_platform_enable_resources+0x1a/0x120 ahci_probe+0x4f/0x1b9 platform_probe+0x10b/0x280 ... entry_SYSCALL_64_after_hwframe+0x44/0xae If devm_regulator_get() in ahci_platform_get_resources() fails, hpriv->phy_regulator will point to NULL, when enabling or disabling it, null-ptr-deref will occur. ahci_probe() ahci_platform_get_resources() devm_regulator_get(, "phy") // failed, let phy_regulator = NULL ahci_platform_enable_resources() ahci_platform_enable_regulators() regulator_enable(hpriv->phy_regulator) // null-ptr-deref commit 962399bb7fbf ("ata: libahci_platform: Fix regulator_get_optional() misuse") replaces devm_regulator_get_optional() with devm_regulator_get(), but PHY regulator omits to delete "hpriv->phy_regulator = NULL;" like AHCI. Delete it like AHCI regulator to fix this bug. Fixes: commit 962399bb7fbf ("ata: libahci_platform: Fix regulator_get_optional() misuse") Reported-by: Hulk Robot Signed-off-by: Wang Hai Reviewed-by: Hans de Goede Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 55b033b82dded90576d9e7906613adc027b6fefe Author: Dan Carpenter Date: Wed Oct 6 10:34:19 2021 +0300 pata_legacy: fix a couple uninitialized variable bugs commit 013923477cb311293df9079332cf8b806ed0e6f2 upstream. The last byte of "pad" is used without being initialized. Fixes: 55dba3120fbc ("libata: update ->data_xfer hook for ATAPI") Signed-off-by: Dan Carpenter Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 6432d7f1d1c3aa74cfe8f5e3afdf81b786c32e86 Author: Ziyang Xuan Date: Wed Oct 13 15:50:32 2021 +0800 NFC: digital: fix possible memory leak in digital_in_send_sdd_req() commit 291c932fc3692e4d211a445ba8aa35663831bac7 upstream. 'skb' is allocated in digital_in_send_sdd_req(), but not free when digital_in_send_cmd() failed, which will cause memory leak. Fix it by freeing 'skb' if digital_in_send_cmd() return failed. Fixes: 2c66daecc409 ("NFC Digital: Add NFC-A technology support") Signed-off-by: Ziyang Xuan Reviewed-by: Krzysztof Kozlowski Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 564249219e5b5673a8416b5181875d828c3f1e8c Author: Ziyang Xuan Date: Wed Oct 13 15:50:12 2021 +0800 NFC: digital: fix possible memory leak in digital_tg_listen_mdaa() commit 58e7dcc9ca29c14e44267a4d0ea61e3229124907 upstream. 'params' is allocated in digital_tg_listen_mdaa(), but not free when digital_send_cmd() failed, which will cause memory leak. Fix it by freeing 'params' if digital_send_cmd() return failed. Fixes: 1c7a4c24fbfd ("NFC Digital: Add target NFC-DEP support") Signed-off-by: Ziyang Xuan Reviewed-by: Krzysztof Kozlowski Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e005ba2235b6f4a78b9454eccca47583fdc59ae5 Author: Ziyang Xuan Date: Wed Oct 13 11:49:32 2021 +0800 nfc: fix error handling of nfc_proto_register() commit 0911ab31896f0e908540746414a77dd63912748d upstream. When nfc proto id is using, nfc_proto_register() return -EBUSY error code, but forgot to unregister proto. Fix it by adding proto_unregister() in the error handling case. Fixes: c7fe3b52c128 ("NFC: add NFC socket family") Signed-off-by: Ziyang Xuan Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20211013034932.2833737-1-william.xuanziyang@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0b84e32840b7b6aa329585096c831e2b58b008d9 Author: Cindy Lu Date: Wed Sep 29 17:09:33 2021 +0800 vhost-vdpa: Fix the wrong input in config_cb commit bcef9356fc2e1302daf373c83c826aa27954d128 upstream. Fix the wrong input in for config_cb. In function vhost_vdpa_config_cb, the input cb.private was used as struct vhost_vdpa, so the input was wrong here, fix this issue Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa") Signed-off-by: Cindy Lu Link: https://lore.kernel.org/r/20210929090933.20465-1-lulu@redhat.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 2d902349653cbe1c6e43e5e30370497f166fb42c Author: Arnd Bergmann Date: Wed Oct 13 16:35:49 2021 +0200 ethernet: s2io: fix setting mac address during resume commit 40507e7aada8422c38aafa0c8a1a09e4623c712a upstream. After recent cleanups, gcc started warning about a suspicious memcpy() call during the s2io_io_resume() function: In function '__dev_addr_set', inlined from 'eth_hw_addr_set' at include/linux/etherdevice.h:318:2, inlined from 's2io_set_mac_addr' at drivers/net/ethernet/neterion/s2io.c:5205:2, inlined from 's2io_io_resume' at drivers/net/ethernet/neterion/s2io.c:8569:7: arch/x86/include/asm/string_32.h:182:25: error: '__builtin_memcpy' accessing 6 bytes at offsets 0 and 2 overlaps 4 bytes at offset 2 [-Werror=restrict] 182 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/netdevice.h:4648:9: note: in expansion of macro 'memcpy' 4648 | memcpy(dev->dev_addr, addr, len); | ^~~~~~ What apparently happened is that an old cleanup changed the calling conventions for s2io_set_mac_addr() from taking an ethernet address as a character array to taking a struct sockaddr, but one of the callers was not changed at the same time. Change it to instead call the low-level do_s2io_prog_unicast() function that still takes the old argument type. Fixes: 2fd376884558 ("S2io: Added support set_mac_address driver entry point") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20211013143613.2049096-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 322c0e53496309e634d9db7349678eaad1d25b55 Author: Nanyong Sun Date: Tue Oct 12 20:59:01 2021 +0800 net: encx24j600: check error in devm_regmap_init_encx24j600 commit f03dca0c9e2297c84a018e306f8a9cd534ee4287 upstream. devm_regmap_init may return error which caused by like out of memory, this will results in null pointer dereference later when reading or writing register: general protection fault in encx24j600_spi_probe KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540 Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00 RSP: 0018:ffffc900010476b8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000 RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094 RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001 R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08 FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459 spi_probe drivers/spi/spi.c:397 really_probe drivers/base/dd.c:517 __driver_probe_device drivers/base/dd.c:751 driver_probe_device drivers/base/dd.c:782 __device_attach_driver drivers/base/dd.c:899 bus_for_each_drv drivers/base/bus.c:427 __device_attach drivers/base/dd.c:971 bus_probe_device drivers/base/bus.c:487 device_add drivers/base/core.c:3364 __spi_add_device drivers/spi/spi.c:599 spi_add_device drivers/spi/spi.c:641 spi_new_device drivers/spi/spi.c:717 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e] dev_attr_store drivers/base/core.c:2074 sysfs_kf_write fs/sysfs/file.c:139 kernfs_fop_write_iter fs/kernfs/file.c:300 new_sync_write fs/read_write.c:508 (discriminator 4) vfs_write fs/read_write.c:594 ksys_write fs/read_write.c:648 do_syscall_64 arch/x86/entry/common.c:50 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113 Add error check in devm_regmap_init_encx24j600 to avoid this situation. Fixes: 04fbfce7a222 ("net: Microchip encx24j600 driver") Reported-by: Hulk Robot Signed-off-by: Nanyong Sun Link: https://lore.kernel.org/r/20211012125901.3623144-1-sunnanyong@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 38eaccdcc81173c2f78e9936dce6cee29549988c Author: Alvin Šipraga Date: Tue Oct 12 13:27:31 2021 +0200 net: dsa: fix spurious error message when unoffloaded port leaves bridge commit 43a4b4dbd48c9006ef64df3a12acf33bdfe11c61 upstream. Flip the sign of a return value check, thereby suppressing the following spurious error: port 2 failed to notify DSA_NOTIFIER_BRIDGE_LEAVE: -EOPNOTSUPP ... which is emitted when removing an unoffloaded DSA switch port from a bridge. Fixes: d371b7c92d19 ("net: dsa: Unset vlan_filtering when ports leave the bridge") Signed-off-by: Alvin Šipraga Reviewed-by: Vladimir Oltean Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20211012112730.3429157-1-alvin@pqrs.dk Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 383239a33cf29ebee9ce0d4e0e5c900b77a16148 Author: Arun Ramadoss Date: Mon Oct 11 21:18:08 2021 +0530 net: dsa: microchip: Added the condition for scheduling ksz_mib_read_work commit ef1100ef20f29aec4e62abeccdb5bdbebba1e378 upstream. When the ksz module is installed and removed using rmmod, kernel crashes with null pointer dereferrence error. During rmmod, ksz_switch_remove function tries to cancel the mib_read_workqueue using cancel_delayed_work_sync routine and unregister switch from dsa. During dsa_unregister_switch it calls ksz_mac_link_down, which in turn reschedules the workqueue since mib_interval is non-zero. Due to which queue executed after mib_interval and it tries to access dp->slave. But the slave is unregistered in the ksz_switch_remove function. Hence kernel crashes. To avoid this crash, before canceling the workqueue, resetted the mib_interval to 0. v1 -> v2: -Removed the if condition in ksz_mib_read_work Fixes: 469b390e1ba3 ("net: dsa: microchip: use delayed_work instead of timer + work") Signed-off-by: Arun Ramadoss Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b1752d2f4fc22928727e14b2541f16c93f12e6b8 Author: Maarten Zanders Date: Mon Oct 11 16:27:20 2021 +0200 net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's commit 4a3e0aeddf091f00974b02627c157843ce382a24 upstream. mv88e6xxx_port_ppu_updates() interpretes data in the PORT_STS register incorrectly for internal ports (ie no PPU). In these cases, the PHY_DETECT bit indicates link status. This results in forcing the MAC state whenever the PHY link goes down which is not intended. As a side effect, LED's configured to show link status stay lit even though the physical link is down. Add a check in mac_link_down and mac_link_up to see if it concerns an external port and only then, look at PPU status. Fixes: 5d5b231da7ac (net: dsa: mv88e6xxx: use PHY_DETECT in mac_link_up/mac_link_down) Reported-by: Maarten Zanders Reviewed-by: Maxime Chevallier Signed-off-by: Maarten Zanders Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f71c73a1275c962a4411f47a0dc4027238e61575 Author: Florian Fainelli Date: Fri Oct 8 14:42:52 2021 -0700 net: phy: Do not shutdown PHYs in READY state commit f49823939e41121fdffada4d583e3e38d28336f9 upstream. In case a PHY device was probed thus in the PHY_READY state, but not configured and with no network device attached yet, we should not be trying to shut it down because it has been brought back into reset by phy_device_reset() towards the end of phy_probe() and anyway we have not configured the PHY yet. Fixes: e2f016cf7751 ("net: phy: add a shutdown procedure") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 568feb737f5e37afcb0c9180955541efaf993415 Author: Herve Codina Date: Fri Oct 8 12:34:37 2021 +0200 net: stmmac: fix get_hw_feature() on old hardware commit 075da584bae2da6a37428d59a477b6bdad430ac3 upstream. Some old IPs do not provide the hardware feature register. On these IPs, this register is read 0x00000000. In old driver version, this feature was handled but a regression came with the commit f10a6a3541b4 ("stmmac: rework get_hw_feature function"). Indeed, this commit removes the return value in dma->get_hw_feature(). This return value was used to indicate the validity of retrieved information and used later on in stmmac_hw_init() to override priv->plat data if this hardware feature were valid. This patch restores the return code in ->get_hw_feature() in order to indicate the hardware feature validity and override priv->plat data only if this hardware feature is valid. Fixes: f10a6a3541b4 ("stmmac: rework get_hw_feature function") Signed-off-by: Herve Codina Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 947442b6209001c2484e8ea74f16119d510d1575 Author: Saeed Mahameed Date: Mon Oct 4 21:20:25 2021 -0700 net/mlx5e: Switchdev representors are not vlan challenged commit b2107cdc43d8601f2cadfba990ae844cc1f44e68 upstream. Before this patch, mlx5 representors advertised the NETIF_F_VLAN_CHALLENGED bit, this could lead to missing features when using reps with vxlan/bridge and maybe other virtual interfaces, when such interfaces inherit this bit and block vlan usage in their topology. Example: $ip link add dev bridge type bridge # add representor interface to the bridge $ip link set dev pf0hpf master $ip link add link bridge name vlan10 type vlan id 10 protocol 802.1q Error: 8021q: VLANs not supported on device. Reps are perfectly capable of handling vlan traffic, although they don't implement vlan_{add,kill}_vid ndos, hence, remove NETIF_F_VLAN_CHALLENGED advertisement. Fixes: cb67b832921c ("net/mlx5e: Introduce SRIOV VF representors") Reported-by: Roopa Prabhu Signed-off-by: Saeed Mahameed Reviewed-by: Roi Dayan Signed-off-by: Greg Kroah-Hartman commit 2f306483d5479a8d23e998cf521d936d91463696 Author: Aya Levin Date: Sun Sep 26 17:55:41 2021 +0300 net/mlx5e: Mutually exclude RX-FCS and RX-port-timestamp commit 0bc73ad46a76ed6ece4dcacb28858e7b38561e1c upstream. Due to current HW arch limitations, RX-FCS (scattering FCS frame field to software) and RX-port-timestamp (improved timestamp accuracy on the receive side) can't work together. RX-port-timestamp is not controlled by the user and it is enabled by default when supported by the HW/FW. This patch sets RX-port-timestamp opposite to RX-FCS configuration. Fixes: 102722fc6832 ("net/mlx5e: Add support for RXFCS feature flag") Signed-off-by: Aya Levin Reviewed-by: Tariq Toukan Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit ed8aafea4fec9c654e63445236e0b505e27ed3a7 Author: Valentine Fatiev Date: Sun Aug 15 17:43:19 2021 +0300 net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path commit 94b960b9deffc02fc0747afc01f72cc62ab099e3 upstream. Prior to this patch in case mlx5_core_destroy_cq() failed it returns without completing all destroy operations and that leads to memory leak. Instead, complete the destroy flow before return error. Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq() to be symmetrical with mlx5_core_create_cq(). kmemleak complains on: unreferenced object 0xc000000038625100 (size 64): comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s) hex dump (first 32 bytes): 60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4..... 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}..... backtrace: [<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core] [<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core] [<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core] [<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core] [<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core] [<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core] [<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core] [<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230 [mlx5_core] [<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300 [mlx5_core] [<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core] [<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core] [<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0 [<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0 [<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0 [<00000000646c5c2c>] genl_rcv_msg+0x78/0x120 [<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0 Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Valentine Fatiev Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 0d9ddf515cde793841f738490037560fd6559c63 Author: Karsten Graul Date: Thu Oct 7 16:14:40 2021 +0200 net/smc: improved fix wait on already cleared link commit 95f7f3e7dc6bd2e735cb5de11734ea2222b1e05a upstream. Commit 8f3d65c16679 ("net/smc: fix wait on already cleared link") introduced link refcounting to avoid waits on already cleared links. This patch extents and improves the refcounting to cover all remaining possible cases for this kind of error situation. Fixes: 15e1b99aadfb ("net/smc: no WR buffer wait for terminating link group") Signed-off-by: Karsten Graul Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 844b62f61709c7173b0d61345ba1f78a9e650d37 Author: Vegard Nossum Date: Tue Oct 12 17:25:09 2021 +0200 net: korina: select CRC32 commit 427f974d9727ca681085ddcd0530c97ab5811ae0 upstream. Fix the following build/link error by adding a dependency on the CRC32 routines: ld: drivers/net/ethernet/korina.o: in function `korina_multicast_list': korina.c:(.text+0x1af): undefined reference to `crc32_le' Fixes: ef11291bcd5f9 ("Add support the Korina (IDT RC32434) Ethernet MAC") Cc: Arnd Bergmann Signed-off-by: Vegard Nossum Acked-by: Florian fainelli Link: https://lore.kernel.org/r/20211012152509.21771-1-vegard.nossum@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit af9a33bfff34b9695ef2e6d8a2217876a0823dc2 Author: Vegard Nossum Date: Tue Oct 12 11:34:46 2021 +0200 net: arc: select CRC32 commit e599ee234ad4fdfe241d937bbabd96e0d8f9d868 upstream. Fix the following build/link error by adding a dependency on the CRC32 routines: ld: drivers/net/ethernet/arc/emac_main.o: in function `arc_emac_set_rx_mode': emac_main.c:(.text+0xb11): undefined reference to `crc32_le' The crc32_le() call comes through the ether_crc_le() call in arc_emac_set_rx_mode(). [v2: moved the select to ARC_EMAC_CORE; the Makefile is a bit confusing, but the error comes from emac_main.o, which is part of the arc_emac module, which in turn is enabled by CONFIG_ARC_EMAC_CORE. Note that arc_emac is different from emac_arc...] Fixes: 775dd682e2b0ec ("arc_emac: implement promiscuous mode and multicast filtering") Cc: Arnd Bergmann Signed-off-by: Vegard Nossum Link: https://lore.kernel.org/r/20211012093446.1575-1-vegard.nossum@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 81099749174ea690b0b7e94fadbaa407d69faf5e Author: Andy Shevchenko Date: Fri Sep 24 01:46:40 2021 +0300 gpio: pca953x: Improve bias setting commit 55a9968c7e139209a9e93d4ca4321731bea5fc95 upstream. The commit 15add06841a3 ("gpio: pca953x: add ->set_config implementation") introduced support for bias setting. However this, due to being half-baked, brought potential issues: - the turning bias via disabling makes the pin floating for a while; - once enabled, bias can't be disabled. Fix all these by adding support for bias disabling and move the disabling part under the corresponding conditional. While at it, add support for default setting, since it's cheap to add. Fixes: 15add06841a3 ("gpio: pca953x: add ->set_config implementation") Cc: Thomas Petazzoni Signed-off-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 9025c92a6cc701c249b9d8d95082350079c6d27c Author: Mark Brown Date: Wed Sep 22 17:17:36 2021 +0100 gpio: 74x164: Add SPI device ID table commit be4491838359e78e42e88db4ac479e21c5eda1e0 upstream. Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding a SPI device ID table. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Reviewed-by: Linus Walleij Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 4f0bc44b9191b176d7b558f1f5ca1865339a27ef Author: Eiichi Tsukata Date: Wed Oct 13 17:27:29 2021 -0300 sctp: account stream padding length for reconf chunk commit a2d859e3fc97e79d907761550dbc03ff1b36479c upstream. sctp_make_strreset_req() makes repeated calls to sctp_addto_chunk() which will automatically account for padding on each call. inreq and outreq are already 4 bytes aligned, but the payload is not and doing SCTP_PAD4(a + b) (which _sctp_make_chunk() did implicitly here) is different from SCTP_PAD4(a) + SCTP_PAD4(b) and not enough. It led to possible attempt to use more buffer than it was allocated and triggered a BUG_ON. Cc: Vlad Yasevich Cc: Neil Horman Cc: Greg KH Fixes: cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk") Reported-by: Eiichi Tsukata Signed-off-by: Eiichi Tsukata Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: Marcelo Ricardo Leitner Reviewed-by: Xin Long Link: https://lore.kernel.org/r/b97c1f8b0c7ff79ac4ed206fc2c49d3612e0850c.1634156849.git.mleitner@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5ccd69157a9a043f1fbcf7d6a09bcb7829b845aa Author: Keith Busch Date: Wed Oct 6 23:50:31 2021 -0700 nvme-pci: Fix abort command id commit 85f74acf097a63a07f5a7c215db6883e5c35e3ff upstream. The request tag is no longer the only component of the command id. Fixes: e7006de6c2380 ("nvme: code command_id with a genctr for use-after-free validation") Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 9036542c2befb00545f5b73e4e34f6697798fe7e Author: Biju Das Date: Wed Sep 22 12:24:05 2021 +0100 clk: renesas: rzg2l: Fix clk status function commit fa2a30f8e0aa9304919750b116a9e9e322465299 upstream. As per RZ/G2L HW(Rev.0.50) manual, clock monitor register value 0 means clock is not supplied and 1 means clock is supplied. This patch fixes the issue by removing the inverted logic. Fixing the above, triggered following 2 issues 1) GIC interrupts don't work if we disable IA55_CLK and DMAC_ACLK. Fixed this issue by adding these clocks as critical clocks. 2) DMA is not working, since the DMA driver is not turning on DMAC_PCLK. So will provide a fix in the DMA driver to turn on DMA_PCLK. Fixes: ef3c613ccd68 ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC") Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20210922112405.26413-2-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit abab283877558998e5672a98868552e5bd861045 Author: Nicolas Saenz Julienne Date: Tue Aug 31 14:58:42 2021 +0200 ARM: dts: bcm2711-rpi-4-b: Fix pcie0's unit address formatting commit 13dbc954b3c9a9de0ad5b7279e8d3b708d31068b upstream. dtbs_check currently complains that: arch/arm/boot/dts/bcm2711-rpi-4-b.dts:220.10-231.4: Warning (pci_device_reg): /scb/pcie@7d500000/pci@1,0: PCI unit address format error, expected "0,0" Unsurprisingly pci@0,0 is the right address, as illustrated by its reg property: &pcie0 { pci@0,0 { /* * As defined in the IEEE Std 1275-1994 document, * reg is a five-cell address encoded as (phys.hi * phys.mid phys.lo size.hi size.lo). phys.hi * should contain the device's BDF as 0b00000000 * bbbbbbbb dddddfff 00000000. The other cells * should be zero. */ reg = <0 0 0 0 0>; }; }; The device is clearly 0. So fix it. Also add a missing 'device_type = "pci"'. Fixes: 258f92d2f840 ("ARM: dts: bcm2711: Add reset controller to xHCI node") Suggested-by: Rob Herring Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210831125843.1233488-1-nsaenzju@redhat.com Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Greg Kroah-Hartman commit 264e77ee3987c82b56b0005a9455be8ff899e4b7 Author: Stefan Wahren Date: Sat Aug 7 13:06:33 2021 +0200 ARM: dts: bcm2711-rpi-4-b: fix sd_io_1v8_reg regulator states commit b55ec7528879a822a4d350248daa04bbb27f25fd upstream. DT schema check complains at sd_io_1v8_reg about the following: [1800000, 1, 3300000, 0] is too long Additional items are not allowed (3300000, 0 were unexpected) So fix the states definition. Fixes: 7dbe8c62ceeb ("ARM: dts: Add minimal Raspberry Pi 4 support") Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/1628334401-6577-3-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Greg Kroah-Hartman commit 06560ba731e2775441c6dc9f0bf39f9f3606fbb7 Author: Sudeep Holla Date: Fri Sep 24 10:28:58 2021 +0100 firmware: arm_ffa: Add missing remove callback to ffa_bus_type commit 244f5d597e1ea519c2085fbd9819458688775e42 upstream. Currently the arm_ffa firmware driver can be built as module and hence all the users of FFA driver. If any driver on the ffa bus is removed or unregistered, the remove callback on all the device bound to the driver being removed should be callback. For that to happen, we must register a remove callback on the ffa_bus which is currently missing. This results in the probe getting called again without the previous remove callback on a device which may result in kernel crash. Fix the issue by registering the remove callback on the FFA bus. Link: https://lore.kernel.org/r/20210924092859.3057562-1-sudeep.holla@arm.com Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration") Reported-by: Jens Wiklander Tested-by: Jens Wiklander Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman commit b2da1ae1941d6ae648db7af2f189557f9cf3b97a Author: Sudeep Holla Date: Fri Sep 24 10:28:59 2021 +0100 firmware: arm_ffa: Fix __ffa_devices_unregister commit eb7b52e6db7c21400b9b2d539f9343fb6e94bd94 upstream. When arm_ffa firmware driver module is unloaded or removed we call __ffa_devices_unregister on all the devices on the ffa bus. It must unregister all the devices instead it is currently just releasing the devices without unregistering. That is pure wrong as when we try to load the module back again, it will result in the kernel crash something like below. -->8 CPU: 2 PID: 232 Comm: modprobe Not tainted 5.15.0-rc2+ #169 Hardware name: FVP Base RevC (DT) Call trace: dump_backtrace+0x0/0x1cc show_stack+0x18/0x64 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 sysfs_create_dir_ns+0xe4/0x140 kobject_add_internal+0x170/0x358 kobject_add+0x94/0x100 device_add+0x178/0x5f0 device_register+0x20/0x30 ffa_device_register+0x80/0xcc [ffa_module] ffa_setup_partitions+0x7c/0x108 [ffa_module] init_module+0x290/0x2dc [ffa_module] do_one_initcall+0xbc/0x230 do_init_module+0x58/0x304 load_module+0x15e0/0x1f68 __arm64_sys_finit_module+0xb8/0xf4 invoke_syscall+0x44/0x140 el0_svc_common+0xb4/0xf0 do_el0_svc+0x24/0x80 el0_svc+0x20/0x50 el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x1a0/0x1a4 kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to register things with the same name in the same directory. ---- Fix the issue by calling device_unregister in __ffa_devices_unregister which will also take care of calling device_release(which is mapped to ffa_release_device) Link: https://lore.kernel.org/r/20210924092859.3057562-2-sudeep.holla@arm.com Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration") Tested-by: Jens Wiklander Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman commit a0dfb710735dddc473d9ecbd59ca1f18e816bc97 Author: Stefan Wahren Date: Sat Aug 7 13:06:32 2021 +0200 ARM: dts: bcm2711: fix MDIO #address- and #size-cells commit 2faff6737a8a684b077264f0aed131526c99eec4 upstream. The values of #address-cells and #size-cells are swapped. Fix this and avoid the following DT schema warnings for mdio@e14: #address-cells:0:0: 1 was expected #size-cells:0:0: 0 was expected Fixes: be8af7a9e3cc ("ARM: dts: bcm2711-rpi-4: Enable GENET support") Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/1628334401-6577-2-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Greg Kroah-Hartman commit 83fe15846c489dac360b93dfe1feaa429b06bfb0 Author: Mateusz Kwiatkowski Date: Thu Jul 22 21:02:08 2021 +0200 ARM: dts: bcm283x: Fix VEC address for BCM2711 commit 9287e91e9019d4bc1018adb55ab791ae672e0b14 upstream. The VEC has a different address (0x7ec13000) on the BCM2711 (used in e.g. Raspberry Pi 4) compared to BCM283x (e.g. Pi 3 and earlier). This was erroneously not taken account for. Definition of the VEC in the devicetrees had to be moved from bcm283x.dtsi to bcm2711.dtsi and bcm2835-common.dtsi to allow for this differentiation. Fixes: 7894bdc6228f ("ARM: boot: dts: bcm2711: Add BCM2711 VEC compatible") Signed-off-by: Mateusz Kwiatkowski Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/1626980528-3835-1-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Greg Kroah-Hartman commit 2a7374dd882db9aa0b56613ef9d2c913c4a3aa60 Author: Nicolas Saenz Julienne Date: Tue Aug 31 14:58:43 2021 +0200 ARM: dts: bcm2711-rpi-4-b: Fix usb's unit address commit 3f32472854614d6f53b09b4812372dba9fc5c7de upstream. The unit address is supposed to represent ','. Which are both 0 for RPi4b's XHCI controller. On top of that although OpenFirmware states bus number goes in the high part of the last reg parameter, FDT doesn't seem to care for it[1], so remove it. [1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210830103909.323356-1-nsaenzju@redhat.com/#24414633 Fixes: 258f92d2f840 ("ARM: dts: bcm2711: Add reset controller to xHCI node") Suggested-by: Rob Herring Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210831125843.1233488-2-nsaenzju@redhat.com Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Greg Kroah-Hartman commit a009758b28f3e6d02664f1140712b7ba098dec15 Author: Sumit Garg Date: Tue Oct 12 13:01:16 2021 +0530 tee: optee: Fix missing devices unregister during optee_remove commit 7f565d0ead264329749c0da488de9c8dfa2f18ce upstream. When OP-TEE driver is built as a module, OP-TEE client devices registered on TEE bus during probe should be unregistered during optee_remove. So implement optee_unregister_devices() accordingly. Fixes: c3fa24af9244 ("tee: optee: add TEE bus device enumeration support") Reported-by: Sudeep Holla Signed-off-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Greg Kroah-Hartman commit 362d067a231d4124045234aa7f35d5acb484ecb4 Author: Jackie Liu Date: Wed Sep 22 10:51:22 2021 +0800 tracing: Fix missing osnoise tracer on max_latency commit 424b650f35c77defbb3cbd6e5221d3697af42250 upstream. The compiler warns when the data are actually unused: kernel/trace/trace.c:1712:13: error: ‘trace_create_maxlat_file’ defined but not used [-Werror=unused-function] 1712 | static void trace_create_maxlat_file(struct trace_array *tr, | ^~~~~~~~~~~~~~~~~~~~~~~~ [Why] CONFIG_HWLAT_TRACER=n, CONFIG_TRACER_MAX_TRACE=n, CONFIG_OSNOISE_TRACER=y gcc report warns. [How] Now trace_create_maxlat_file will only take effect when CONFIG_HWLAT_TRACER=y or CONFIG_TRACER_MAX_TRACE=y. In fact, after adding osnoise trace, it also needs to take effect. Link: https://lore.kernel.org/all/c1d9e328-ad7c-920b-6c24-9e1598a6421c@infradead.org/ Link: https://lkml.kernel.org/r/20210922025122.3268022-1-liu.yun@linux.dev Fixes: bce29ac9ce0b ("trace: Add osnoise tracer") Cc: Daniel Bristot de Oliveira Suggested-by: Steven Rostedt Reviewed-by: Daniel Bristot de Oliveira Tested-by: Randy Dunlap # build-tested Signed-off-by: Jackie Liu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit ce5c6dd074732ffb4be9ec76b3f9fec1c3c643aa Author: Dan Carpenter Date: Mon Aug 16 21:39:54 2021 +0300 iio: dac: ti-dac5571: fix an error code in probe() commit f7a28df7db84eb3410e9eca37832efa5aed93338 upstream. If we have an unexpected number of channels then return -EINVAL instead of returning success. Fixes: df38a4a72a3b ("iio: dac: add TI DAC5571 family support") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20210816183954.GB2068@kili Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8d3fd8fdf2cbd6d9a2dbe29920cbf7c8eaf0bce7 Author: Mark Brown Date: Mon Sep 27 14:44:03 2021 +0100 fpga: ice40-spi: Add SPI device ID table commit 2a2a79577ddae7d5314b2f57ca86b44d794403d5 upstream. Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding a SPI ID table. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Signed-off-by: Moritz Fischer Signed-off-by: Greg Kroah-Hartman commit 645e2c994b6a14f2860dc6cf7092c5f40ab2a6b5 Author: Mark Brown Date: Thu Sep 23 18:24:53 2021 +0100 eeprom: at25: Add SPI ID table commit 9e2cd444909b3c93f5cc83463d12291e3e0f990b upstream. Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding an id_table listing the SPI IDs for everything. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210923172453.4921-1-broonie@kernel.org Signed-off-by: Greg Kroah-Hartman commit 362fe6c8d5abced6ef33dbb82cc4183c6e863e5f Author: Arnd Bergmann Date: Thu Oct 14 17:37:18 2021 +0200 eeprom: 93xx46: fix MODULE_DEVICE_TABLE commit f42752729e2068a92c7d8b576d0dbbc9c1464149 upstream. The newly added SPI device ID table does not work because the entry is incorrectly copied from the OF device table. During build testing, this shows as a compile failure when building it as a loadable module: drivers/misc/eeprom/eeprom_93xx46.c:424:1: error: redefinition of '__mod_of__eeprom_93xx46_of_table_device_table' MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table); Change the entry to refer to the correct symbol. Fixes: 137879f7ff23 ("eeprom: 93xx46: Add SPI device ID table") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20211014153730.3821376-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit 42c587653cb78aa8427dbb7c14d5a3f1dce4d8be Author: Mark Brown Date: Wed Sep 22 19:40:48 2021 +0100 eeprom: 93xx46: Add SPI device ID table commit 137879f7ff23c635d2c6b2e43f4b39e2d305c3e2 upstream. Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding a SPI device ID table. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210922184048.34770-1-broonie@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1a5ba478c41c4842e899a95458cb7c7a1228b5b9 Author: Oleksij Rempel Date: Fri Oct 15 21:12:06 2021 -0700 Input: resistive-adc-touch - fix division by zero error on z1 == 0 commit fe0a7e3d012738b0034b3c97ddb0e8bc0a3ff0e6 upstream. For proper pressure calculation we need at least x and z1 to be non zero. Even worse, in case z1 we may run in to division by zero error. Fixes: 60b7db914ddd ("Input: resistive-adc-touch - rework mapping of channels") Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20211007095727.29579-1-o.rempel@pengutronix.de Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 6ad4dc9602fa5f05f668b03b42ccf12d4ae3e7b9 Author: Dan Carpenter Date: Tue Sep 14 13:53:33 2021 +0300 iio: ssp_sensors: fix error code in ssp_print_mcu_debug() commit 4170d3dd1467e9d78cb9af374b19357dc324b328 upstream. The ssp_print_mcu_debug() function should return negative error codes on error. Returning "length" is meaningless. This change does not affect runtime because the callers only care about zero/non-zero. Reported-by: Jonathan Cameron Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20210914105333.GA11657@kili Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit af8aae7a1257046ce66ef5e29ce80a7373987ed5 Author: Dan Carpenter Date: Thu Sep 9 12:13:36 2021 +0300 iio: ssp_sensors: add more range checking in ssp_parse_dataframe() commit 8167c9a375ccceed19048ad9d68cb2d02ed276e0 upstream. The "idx" is validated at the start of the loop but it gets incremented during the iteration so it needs to be checked again. Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20210909091336.GA26312@kili Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3903e5404214b0b70a099c13b8d3145d7d382ca3 Author: Miquel Raynal Date: Wed Aug 18 13:11:25 2021 +0200 iio: adc: max1027: Fix the number of max1X31 channels commit f0cb5fed37ab37f6a6c5463c5fd39b58a45670c8 upstream. The macro MAX1X29_CHANNELS() already calls MAX1X27_CHANNELS(). Calling MAX1X27_CHANNELS() before MAX1X29_CHANNELS() in the definition of MAX1X31_CHANNELS() declares the first 8 channels twice. So drop this extra call from the MAX1X31 channels list definition. Fixes: 7af5257d8427 ("iio: adc: max1027: Prepare the introduction of different resolutions") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20210818111139.330636-3-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 43e399d862efeb0d08a909f832190bb55c807497 Author: Sean Nyekjaer Date: Tue Aug 17 14:43:36 2021 +0200 iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushed commit 9033c7a357481fb5bcc1737bafa4aec572dca5c6 upstream. fxls8962af_fifo_flush() will return the samples flushed. So return IRQ_NONE only if an error is returned. Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling") Signed-off-by: Sean Nyekjaer Link: https://lore.kernel.org/r/20210817124336.1672169-1-sean@geanix.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 56e3bcdf6b9b12ca4f02b4fb158256edaad6583f Author: Jiri Valek - 2N Date: Mon Sep 20 14:53:48 2021 +0200 iio: light: opt3001: Fixed timeout error when 0 lux commit 26d90b5590579def54382a2fc34cfbe8518a9851 upstream. Reading from sensor returned timeout error under zero light conditions. Signed-off-by: Jiri Valek - 2N Fixes: ac663db3678a ("iio: light: opt3001: enable operation w/o IRQ") Link: https://lore.kernel.org/r/20210920125351.6569-1-valek@2n.cz Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 07415de29ded52aefc105e8be92be0e7bf8064a0 Author: Hui Liu Date: Sun Sep 26 15:30:28 2021 +0800 iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED commit c2980c64c7fd4585d684574c92d1624d44961edd upstream. The previous driver does't apply the necessary scaling to take the voltage range into account. We change readback value from raw data to input voltage to fix case IIO_CHAN_INFO_PROCESSED. Fixes: ace4cdfe67be ("iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.") Signed-off-by: Hui Liu Link: https://lore.kernel.org/r/20210926073028.11045-2-hui.liu@mediatek.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 04e03b907022ebd876f422f17efcc2c6cc934dc6 Author: Nuno Sá Date: Mon Sep 20 11:00:47 2021 +0200 iio: adis16475: fix deadlock on frequency set commit 9da1b86865ab4376408c58cd9fec332c8bdb5c73 upstream. With commit 39c024b51b560 ("iio: adis16475: improve sync scale mode handling"), two deadlocks were introduced: 1) The call to 'adis_write_reg_16()' was not changed to it's unlocked version. 2) The lock was not being released on the success path of the function. This change fixes both these issues. Fixes: 39c024b51b560 ("iio: adis16475: improve sync scale mode handling") Signed-off-by: Nuno Sá Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210920090047.74903-1-nuno.sa@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 06a6230a568354cc9db755dc7e8565c8a04e144a Author: Miquel Raynal Date: Wed Aug 18 13:11:24 2021 +0200 iio: adc: max1027: Fix wrong shift with 12-bit devices commit 732ae19ee8f58ecaf30cbc1bbbda5cbee6a45043 upstream. 10-bit devices must shift the value twice. This is not needed anymore on 12-bit devices. Fixes: ae47d009b508 ("iio: adc: max1027: Introduce 12-bit devices support") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20210818111139.330636-2-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 45b54f7f6ae77e4ebc47afaa2c3f5342b9da1763 Author: Christophe JAILLET Date: Sat Aug 21 12:37:24 2021 +0200 iio: adc128s052: Fix the error handling path of 'adc128_probe()' commit bbcf40816b547b3c37af49168950491d20d81ce1 upstream. A successful 'regulator_enable()' call should be balanced by a corresponding 'regulator_disable()' call in the error handling path of the probe, as already done in the remove function. Update the error handling path accordingly. Fixes: 913b86468674 ("iio: adc: Add TI ADC128S052") Signed-off-by: Christophe JAILLET Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/85189f1cfcf6f5f7b42d8730966f2a074b07b5f5.1629542160.git.christophe.jaillet@wanadoo.fr Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2c675f25eb354e5118c3eab2d1f7ea6cbb5a00ae Author: Nuno Sá Date: Fri Sep 3 16:14:23 2021 +0200 iio: adis16480: fix devices that do not support sleep mode commit ea1945c2f72d7bd253e2ebaa97cdd8d9ffcde076 upstream. Not all devices supported by this driver support being put to sleep mode. For those devices, when calling 'adis16480_stop_device()' on the unbind path, we where actually writing in the SYNC_SCALE register. Fixes: 80cbc848c4fa0 ("iio: imu: adis16480: Add support for ADIS16490") Fixes: 82e7a1b250170 ("iio: imu: adis16480: Add support for ADIS1649x family of devices") Signed-off-by: Nuno Sá Link: https://lore.kernel.org/r/20210903141423.517028-6-nuno.sa@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 696eef458c311cf3c142eb354c9dc8804485e08e Author: Alexandru Tachici Date: Mon Sep 6 09:56:30 2021 +0300 iio: adc: ad7793: Fix IRQ flag commit 1a913270e57a8e7f1e3789802f1f64e6d0654626 upstream. In Sigma-Delta devices the SDO line is also used as an interrupt. Leaving IRQ on level instead of falling might trigger a sample read when the IRQ is enabled, as the SDO line is already low. Not sure if SDO line will always immediately go high in ad_sd_buffer_postenable before the IRQ is enabled. Also the datasheet seem to explicitly say the falling edge of the SDO should be used as an interrupt: >From the AD7793 datasheet: " The DOUT/RDY falling edge can be used as an interrupt to a processor" Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags") Signed-off-by: Alexandru Tachici Cc: Link: https://lore.kernel.org/r/20210906065630.16325-4-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c9e8c11b1a8454a3cf13be07063c6dcb73ca9f28 Author: Alexandru Tachici Date: Mon Sep 6 09:56:29 2021 +0300 iio: adc: ad7780: Fix IRQ flag commit e081102f3077aa716974ccebec97003c890d5641 upstream. Correct IRQ flag here is falling. In Sigma-Delta devices the SDO line is also used as an interrupt. Leaving IRQ on level instead of falling might trigger a sample read when the IRQ is enabled, as the SDO line is already low. Not sure if SDO line will always immediately go high in ad_sd_buffer_postenable before the IRQ is enabled. Also the datasheet seem to explicitly say the falling edge of the SDO should be used as an interrupt: >From the AD7780 datasheet: " The DOUT/Figure 22 RDY falling edge can be used as an interrupt to a processor" Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags") Signed-off-by: Alexandru Tachici Cc: Link: https://lore.kernel.org/r/20210906065630.16325-3-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d8f72ea6ccfdc2aa75843f68594b10592f9d535d Author: Alexandru Tachici Date: Mon Sep 6 09:56:28 2021 +0300 iio: adc: ad7192: Add IRQ flag commit 89a86da5cb8e0ee153111fb68a719d31582c206b upstream. IRQ type in ad_sigma_delta_info struct was missing. In Sigma-Delta devices the SDO line is also used as an interrupt. Leaving IRQ on level instead of falling might trigger a sample read when the IRQ is enabled, as the SDO line is already low. Not sure if SDO line will always immediately go high in ad_sd_buffer_postenable before the IRQ is enabled. Also the datasheet seem to explicitly say the falling edge of the SDO should be used as an interrupt: >From the AD7192 datasheet: "The DOUT/RDY falling edge can be used as an interrupt to a processor," Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags") Signed-off-by: Alexandru Tachici Cc: Link: https://lore.kernel.org/r/20210906065630.16325-2-alexandru.tachici@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 10dea2bc52e43dc6ccb4b97bf2bb575b7d18f797 Author: Saravana Kannan Date: Wed Sep 29 12:05:49 2021 -0700 driver core: Reject pointless SYNC_STATE_ONLY device links commit f729a592adb6760013c3e48622a5bf256b992452 upstream. SYNC_STATE_ONLY device links intentionally allow cycles because cyclic sync_state() dependencies are valid and necessary. However a SYNC_STATE_ONLY device link where the consumer and the supplier are the same device is pointless because the device link would be deleted as soon as the device probes (because it's also the consumer) and won't affect when the sync_state() callback is called. It's a waste of CPU cycles and memory to create this device link. So reject any attempts to create such a device link. Fixes: 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY flag") Cc: stable Reported-by: Ulf Hansson Reviewed-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20210929190549.860541-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman commit e733c7a6f7542a9258ae340828d7d8c4ec2748f4 Author: Saravana Kannan Date: Tue Sep 28 17:07:33 2021 -0700 drivers: bus: simple-pm-bus: Add support for probing simple bus only devices commit 98e96cf80045a383fcc47c58dd4e87b3ae587b3e upstream. fw_devlink could end up creating device links for bus only devices. However, bus only devices don't get probed and can block probe() or sync_state() [1] call backs of other devices. To avoid this, probe these devices using the simple-pm-bus driver. However, there are instances of devices that are not simple buses (they get probed by their specific drivers) that also list the "simple-bus" (or other bus only compatible strings) in their compatible property to automatically populate their child devices. We still want these devices to get probed by their specific drivers. So, we make sure this driver only probes devices that are only buses. [1] - https://lore.kernel.org/lkml/CAPDyKFo9Bxremkb1dDrr4OcXSpE0keVze94Cm=zrkOVxHHxBmQ@mail.gmail.com/ Fixes: c442a0d18744 ("driver core: Set fw_devlink to "permissive" behavior by default") Cc: stable Cc: Rob Herring Tested-by: Saravana Kannan Tested-by: Ulf Hansson Tested-by: Geert Uytterhoeven Tested-by: Damien Le Moal Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20210929000735.585237-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman commit 11d6dbd807aaa8ad84133d655a89cad86f3394c1 Author: Billy Tsai Date: Tue Aug 31 15:14:44 2021 +0800 iio: adc: aspeed: set driver data when adc probe. commit eb795cd97365a3d3d9da3926d234a7bc32a3bb15 upstream. Fix the issue when adc remove will get the null driver data. Fixed: commit 573803234e72 ("iio: Aspeed ADC") Signed-off-by: Billy Tsai Link: https://lore.kernel.org/r/20210831071458.2334-2-billy_tsai@aspeedtech.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 74c078866ff490b892e5e3f31b5738dd26b85359 Author: Cédric Le Goater Date: Mon Oct 11 09:02:03 2021 +0200 powerpc/xive: Discard disabled interrupts in get_irqchip_state() commit 6f779e1d359b8d5801f677c1d49dcfa10bf95674 upstream. When an interrupt is passed through, the KVM XIVE device calls the set_vcpu_affinity() handler which raises the P bit to mask the interrupt and to catch any in-flight interrupts while routing the interrupt to the guest. On the guest side, drivers (like some Intels) can request at probe time some MSIs and call synchronize_irq() to check that there are no in flight interrupts. This will call the XIVE get_irqchip_state() handler which will always return true as the interrupt P bit has been set on the host side and lock the CPU in an infinite loop. Fix that by discarding disabled interrupts in get_irqchip_state(). Fixes: da15c03b047d ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race") Cc: stable@vger.kernel.org #v5.4+ Signed-off-by: Cédric Le Goater Tested-by: seeteena Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211011070203.99726-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman commit 202975c570d20185715603d054a09f6cca71c76e Author: Borislav Petkov Date: Wed Oct 6 19:34:55 2021 +0200 x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT automatically commit 711885906b5c2df90746a51f4cd674f1ab9fbb1d upstream. This Kconfig option was added initially so that memory encryption is enabled by default on machines which support it. However, devices which have DMA masks that are less than the bit position of the encryption bit, aka C-bit, require the use of an IOMMU or the use of SWIOTLB. If the IOMMU is disabled or in passthrough mode, the kernel would switch to SWIOTLB bounce-buffering for those transfers. In order to avoid that, 2cc13bb4f59f ("iommu: Disable passthrough mode when SME is active") disables the default IOMMU passthrough mode so that devices for which the default 256K DMA is insufficient, can use the IOMMU instead. However 2, there are cases where the IOMMU is disabled in the BIOS, etc. (think the usual hardware folk "oops, I dropped the ball there" cases) or a driver doesn't properly use the DMA APIs or a device has a firmware or hardware bug, e.g.: ea68573d408f ("drm/amdgpu: Fail to load on RAVEN if SME is active") However 3, in the above GPU use case, there are APIs like Vulkan and some OpenGL/OpenCL extensions which are under the assumption that user-allocated memory can be passed in to the kernel driver and both the GPU and CPU can do coherent and concurrent access to the same memory. That cannot work with SWIOTLB bounce buffers, of course. So, in order for those devices to function, drop the "default y" for the SME by default active option so that users who want to have SME enabled, will need to either enable it in their config or use "mem_encrypt=on" on the kernel command line. [ tlendacky: Generalize commit message. ] Fixes: 7744ccdbc16f ("x86/mm: Add Secure Memory Encryption (SME) support") Reported-by: Paul Menzel Signed-off-by: Borislav Petkov Acked-by: Alex Deucher Acked-by: Tom Lendacky Cc: Link: https://lkml.kernel.org/r/8bbacd0e-4580-3194-19d2-a0ecad7df09c@molgen.mpg.de Signed-off-by: Greg Kroah-Hartman commit 128f382892157b9c81bc0d3fcb275c0b8e575d84 Author: Borislav Petkov Date: Fri Oct 15 12:46:25 2021 +0200 x86/fpu: Mask out the invalid MXCSR bits properly commit b2381acd3fd9bacd2c63f53b2c610c89959b31cc upstream. This is a fix for the fix (yeah, /facepalm). The correct mask to use is not the negation of the MXCSR_MASK but the actual mask which contains the supported bits in the MXCSR register. Reported and debugged by Ville Syrjälä Fixes: d298b03506d3 ("x86/fpu: Restore the masking out of reserved MXCSR bits") Signed-off-by: Borislav Petkov Tested-by: Ville Syrjälä Tested-by: Ser Olmy Cc: Link: https://lore.kernel.org/r/YWgYIYXLriayyezv@intel.com Signed-off-by: Greg Kroah-Hartman commit bce9adf0b5ea38fa5b793dd293d10455f8dbd47f Author: Michael S. Tsirkin Date: Mon Oct 4 11:31:00 2021 -0400 Revert "virtio-blk: Add validation for block size in config space" commit ff63198850f33eab54b2da6905380fd4d4fc0739 upstream. It turns out that access to config space before completing the feature negotiation is broken for big endian guests at least with QEMU hosts up to 6.1 inclusive. This affects any device that accesses config space in the validate callback: at the moment that is virtio-net with VIRTIO_NET_F_MTU but since 82e89ea077b9 ("virtio-blk: Add validation for block size in config space") that also started affecting virtio-blk with VIRTIO_BLK_F_BLK_SIZE. Further, unlike VIRTIO_NET_F_MTU which is off by default on QEMU, VIRTIO_BLK_F_BLK_SIZE is on by default, which resulted in lots of people not being able to boot VMs on BE. The spec is very clear that what we are doing is legal so QEMU needs to be fixed, but given it's been broken for so many years and no one noticed, we need to give QEMU a bit more time before applying this. Further, this patch is incomplete (does not check blk size is a power of two) and it duplicates the logic from nbd. Revert for now, and we'll reapply a cleaner logic in the next release. Cc: stable@vger.kernel.org Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config space") Cc: Xie Yongji Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit f2935e790419b849daf49b75db0b15a8d7687938 Author: Max Gurtovoy Date: Sun Sep 5 11:57:17 2021 +0300 virtio-blk: remove unneeded "likely" statements commit 6105d1fe6f4c24ce8c13e2e6568b16b76e04983d upstream. Usually we use "likely/unlikely" to optimize the fast path. Remove redundant "likely/unlikely" statements in the control path to simplify the code and make it easier to read. Reviewed-by: Stefan Hajnoczi Signed-off-by: Max Gurtovoy Link: https://lore.kernel.org/r/20210905085717.7427-1-mgurtovoy@nvidia.com Signed-off-by: Michael S. Tsirkin Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig Reviewed-by: Stefan Hajnoczi Signed-off-by: Greg Kroah-Hartman commit 0e822e5413da1af28cca350cb1cb42b6133bdcae Author: Stephen Boyd Date: Wed Oct 13 13:45:11 2021 +0100 nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells commit 5d388fa01fa6eb310ac023a363a6cb216d9d8fe9 upstream. If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0); will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long. UBSAN reports this problem: UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Fix it by making sure there are any bits to mask out. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Cc: Douglas Anderson Cc: stable@vger.kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20211013124511.18726-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit eb1e9f2ec683b99c9d3d7b3d603221a1bfeace3c Author: Hans Potsch Date: Wed Oct 6 14:13:32 2021 +0200 EDAC/armada-xp: Fix output of uncorrectable error counter commit d9b7748ffc45250b4d7bcf22404383229bc495f5 upstream. The number of correctable errors is displayed as uncorrectable errors because the "SBE" error count is passed to both calls of edac_mc_handle_error(). Pass the correct uncorrectable error count to the second edac_mc_handle_error() call when logging uncorrectable errors. [ bp: Massage commit message. ] Fixes: 7f6998a41257 ("ARM: 8888/1: EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC") Signed-off-by: Hans Potsch Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/20211006121332.58788-1-hans.potsch@nokia.com Signed-off-by: Greg Kroah-Hartman commit 2c2e626d9ba4f6b07bcdd97554203e9f25f3e8de Author: Halil Pasic Date: Mon Oct 11 07:39:21 2021 +0200 virtio: write back F_VERSION_1 before validate commit 2f9a174f918e29608564c7a4e8329893ab604fb4 upstream. The virtio specification virtio-v1.1-cs01 states: "Transitional devices MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not been acknowledged by the driver." This is exactly what QEMU as of 6.1 has done relying solely on VIRTIO_F_VERSION_1 for detecting that. However, the specification also says: "... the driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device ..." before setting FEATURES_OK. In that case, any transitional device relying solely on VIRTIO_F_VERSION_1 for detecting legacy drivers will return data in legacy format. In particular, this implies that it is in big endian format for big endian guests. This naturally confuses the driver which expects little endian in the modern mode. It is probably a good idea to amend the spec to clarify that VIRTIO_F_VERSION_1 can only be relied on after the feature negotiation is complete. Before validate callback existed, config space was only read after FEATURES_OK. However, we already have two regressions, so let's address this here as well. The regressions affect the VIRTIO_NET_F_MTU feature of virtio-net and the VIRTIO_BLK_F_BLK_SIZE feature of virtio-blk for BE guests when virtio 1.0 is used on both sides. The latter renders virtio-blk unusable with DASD backing, because things simply don't work with the default. See Fixes tags for relevant commits. For QEMU, we can work around the issue by writing out the feature bits with VIRTIO_F_VERSION_1 bit set. We (ab)use the finalize_features config op for this. This isn't enough to address all vhost devices since these do not get the features until FEATURES_OK, however it looks like the affected devices actually never handled the endianness for legacy mode correctly, so at least that's not a regression. No devices except virtio net and virtio blk seem to be affected. Long term the right thing to do is to fix the hypervisors. Cc: #v4.11 Signed-off-by: Halil Pasic Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config space") Fixes: fe36cbe0671e ("virtio_net: clear MTU when out of range") Reported-by: markver@us.ibm.com Reviewed-by: Cornelia Huck Link: https://lore.kernel.org/r/20211011053921.1198936-1-pasic@linux.ibm.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit d22592f1fd8d4bf54fa1cc0ef9122c983d82f30a Author: Srinivas Kandagatla Date: Wed Sep 22 16:43:26 2021 +0100 misc: fastrpc: Add missing lock before accessing find_vma() commit f9a470db2736b01538ad193c316eb3f26be37d58 upstream. fastrpc driver is using find_vma() without any protection, as a result we see below warning due to recent patch 5b78ed24e8ec ("mm/pagemap: add mmap_assert_locked() annotations to find_vma*()") which added mmap_assert_locked() in find_vma() function. This bug went un-noticed in previous versions. Fix this issue by adding required protection while calling find_vma(). CPU: 0 PID: 209746 Comm: benchmark_model Not tainted 5.15.0-rc2-00445-ge14fe2bf817a-dirty #969 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : find_vma+0x64/0xd0 lr : find_vma+0x60/0xd0 sp : ffff8000158ebc40 ... Call trace: find_vma+0x64/0xd0 fastrpc_internal_invoke+0x570/0xda8 fastrpc_device_ioctl+0x3e0/0x928 __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.3+0x70/0xf8 do_el0_svc+0x24/0x88 el0_svc+0x3c/0x138 el0t_64_sync_handler+0x90/0xb8 el0t_64_sync+0x180/0x184 Fixes: 80f3afd72bd4 ("misc: fastrpc: consider address offset before sending to DSP") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210922154326.8927-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman commit 6df4c42e0b6083ec2e21f0187fac65d6288d48c2 Author: Tomaz Solc Date: Wed Oct 6 14:57:50 2021 +0200 USB: serial: option: add prod. id for Quectel EG91 commit c184accc4a42c7872dc8e8d0fc97a740dc61fe24 upstream. Adding support for Quectel EG91 LTE module. The interface layout is same as for EG95. usb-devices output: T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0191 Rev=03.18 S: Manufacturer=Android S: Product=Android C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan Interfaces: 0: Diag 1: GNSS 2: AT-command interface/modem 3: Modem 4: QMI Signed-off-by: Tomaz Solc Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit b39adce3afe1db247216999e65a04b5f462c9cfe Author: Daniele Palmas Date: Mon Oct 4 12:56:55 2021 +0200 USB: serial: option: add Telit LE910Cx composition 0x1204 commit f5a8a07edafed8bede17a95ef8940fe3a57a77d5 upstream. Add the following Telit LE910Cx composition: 0x1204: tty, adb, mbim, tty, tty, tty, tty Signed-off-by: Daniele Palmas Link: https://lore.kernel.org/r/20211004105655.8515-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8372fb17ebf234d5244fcffa80a86177519fedad Author: Yu-Tung Chang Date: Thu Sep 30 10:11:12 2021 +0800 USB: serial: option: add Quectel EC200S-CN module support commit 2263eb7370060bdb0013bc14e1a7c9bf33617a55 upstream. Add usb product id of the Quectel EC200S-CN module. usb-devices output for 0x6002: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=6002 Rev=03.18 S: Manufacturer=Android S: Product=Android S: SerialNumber=0000 C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Signed-off-by: Yu-Tung Chang Link: https://lore.kernel.org/r/20210930021112.330396-1-mtwget@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 1e2c4a11a59be035a9dabdb0af927b7fd03ef55f Author: Aleksander Morgado Date: Thu Oct 7 14:25:01 2021 +0200 USB: serial: qcserial: add EM9191 QDL support commit 11c52d250b34a0862edc29db03fbec23b30db6da upstream. When the module boots into QDL download mode it exposes the 1199:90d2 ids, which can be mapped to the qcserial driver, and used to run firmware upgrades (e.g. with the qmi-firmware-update program). T: Bus=01 Lev=03 Prnt=08 Port=03 Cnt=01 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1199 ProdID=90d2 Rev=00.00 S: Manufacturer=Sierra Wireless, Incorporated S: Product=Sierra Wireless EM9191 S: SerialNumber=8W0382004102A109 C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=2mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=qcserial Signed-off-by: Aleksander Morgado Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 96703298fc519f3bbd88066f3f3c8096c539df8c Author: Michael Cullen Date: Fri Oct 15 13:17:50 2021 -0700 Input: xpad - add support for another USB ID of Nacon GC-100 commit 3378a07daa6cdd11e042797454c706d1c69f9ca6 upstream. The Nacon GX100XF is already mapped, but it seems there is a Nacon GC-100 (identified as NC5136Wht PCGC-100WHITE though I believe other colours exist) with a different USB ID when in XInput mode. Signed-off-by: Michael Cullen Link: https://lore.kernel.org/r/20211015192051.5196-1-michael@michaelcullen.name Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ff9249aab39820be11b6975a10d94253b7d426fc Author: Miquel Raynal Date: Wed Oct 6 00:16:31 2021 +0200 usb: musb: dsps: Fix the probe error path commit c2115b2b16421d93d4993f3fe4c520e91d6fe801 upstream. Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb") has inverted the calls to dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without updating correctly the error path. dsps_create_musb_pdev() allocates and registers a new platform device which must be unregistered and freed with platform_device_unregister(), and this is missing upon dsps_setup_optional_vbus_irq() error. While on the master branch it seems not to trigger any issue, I observed a kernel crash because of a NULL pointer dereference with a v5.10.70 stable kernel where the patch mentioned above was backported. With this kernel version, -EPROBE_DEFER is returned the first time dsps_setup_optional_vbus_irq() is called which triggers the probe to error out without unregistering the platform device. Unfortunately, on the Beagle Bone Black Wireless, the platform device still living in the system is being used by the USB Ethernet gadget driver, which during the boot phase triggers the crash. My limited knowledge of the musb world prevents me to revert this commit which was sent to silence a robot warning which, as far as I understand, does not make sense. The goal of this patch was to prevent an IRQ to fire before the platform device being registered. I think this cannot ever happen due to the fact that enabling the interrupts is done by the ->enable() callback of the platform musb device, and this platform device must be already registered in order for the core or any other user to use this callback. Hence, I decided to fix the error path, which might prevent future errors on mainline kernels while also fixing older ones. Fixes: 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20211005221631.1529448-1-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 85c6f477b3574ba0efa05603247b39e00be0c1b5 Author: Zhang Jianhua Date: Thu Sep 23 10:53:40 2021 +0800 efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock() commit 38fa3206bf441911258e5001ac8b6738693f8d82 upstream. While reboot the system by sysrq, the following bug will be occur. BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:90 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 10052, name: rc.shutdown CPU: 3 PID: 10052 Comm: rc.shutdown Tainted: G W O 5.10.0 #1 Call trace: dump_backtrace+0x0/0x1c8 show_stack+0x18/0x28 dump_stack+0xd0/0x110 ___might_sleep+0x14c/0x160 __might_sleep+0x74/0x88 down_interruptible+0x40/0x118 virt_efi_reset_system+0x3c/0xd0 efi_reboot+0xd4/0x11c machine_restart+0x60/0x9c emergency_restart+0x1c/0x2c sysrq_handle_reboot+0x1c/0x2c __handle_sysrq+0xd0/0x194 write_sysrq_trigger+0xbc/0xe4 proc_reg_write+0xd4/0xf0 vfs_write+0xa8/0x148 ksys_write+0x6c/0xd8 __arm64_sys_write+0x18/0x28 el0_svc_common.constprop.3+0xe4/0x16c do_el0_svc+0x1c/0x2c el0_svc+0x20/0x30 el0_sync_handler+0x80/0x17c el0_sync+0x158/0x180 The reason for this problem is that irq has been disabled in machine_restart() and then it calls down_interruptible() in virt_efi_reset_system(), which would occur sleep in irq context, it is dangerous! Commit 99409b935c9a("locking/semaphore: Add might_sleep() to down_*() family") add might_sleep() in down_interruptible(), so the bug info is here. down_trylock() can solve this problem, cause there is no might_sleep. -------- Cc: Signed-off-by: Zhang Jianhua Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 3b7951e3219385e336f09b282f03d705b9daef68 Author: Ard Biesheuvel Date: Wed Sep 1 08:33:19 2021 +0200 efi/cper: use stack buffer for error record decoding commit b3a72ca80351917cc23f9e24c35f3c3979d3c121 upstream. Joe reports that using a statically allocated buffer for converting CPER error records into human readable text is probably a bad idea. Even though we are not aware of any actual issues, a stack buffer is clearly a better choice here anyway, so let's move the buffer into the stack frames of the two functions that refer to it. Cc: Reported-by: Joe Perches Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 746b00a48688ef8e2fcdb4e3ce5f08dd21c48e5a Author: Arnd Bergmann Date: Mon Sep 27 14:13:57 2021 +0200 cb710: avoid NULL pointer subtraction commit 42641042c10c757fe10cc09088cf3f436cec5007 upstream. clang-14 complains about an unusual way of converting a pointer to an integer: drivers/misc/cb710/sgbuf2.c:50:15: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction] return ((ptr - NULL) & 3) != 0; Replace this with a normal cast to uintptr_t. Fixes: 5f5bac8272be ("mmc: Driver for CB710/720 memory card reader (MMC part)") Cc: stable Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210927121408.939246-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2b6c75bf92027ebf79f1cb579b5ff3ac5d4f218d Author: Nikolay Martynov Date: Fri Oct 8 12:25:47 2021 +0300 xhci: Enable trust tx length quirk for Fresco FL11 USB controller commit ea0f69d8211963c4b2cc1998b86779a500adb502 upstream. Tested on SD5200T TB3 dock which has Fresco Logic FL1100 USB 3.0 Host Controller. Before this patch streaming video from USB cam made mouse and keyboard connected to the same USB bus unusable. Also video was jerky. With this patch streaming video doesn't have any effect on other periferals and video is smooth. Cc: stable@vger.kernel.org Signed-off-by: Nikolay Martynov Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20211008092547.3996295-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit e54abefe703ab7c4e5983e889babd1447738ca42 Author: Pavankumar Kondeti Date: Fri Oct 8 12:25:46 2021 +0300 xhci: Fix command ring pointer corruption while aborting a command commit ff0e50d3564f33b7f4b35cadeabd951d66cfc570 upstream. The command ring pointer is located at [6:63] bits of the command ring control register (CRCR). All the control bits like command stop, abort are located at [0:3] bits. While aborting a command, we read the CRCR and set the abort bit and write to the CRCR. The read will always give command ring pointer as all zeros. So we essentially write only the control bits. Since we split the 64 bit write into two 32 bit writes, there is a possibility of xHC command ring stopped before the upper dword (all zeros) is written. If that happens, xHC updates the upper dword of its internal command ring pointer with all zeros. Next time, when the command ring is restarted, we see xHC memory access failures. Fix this issue by only writing to the lower dword of CRCR where all control bits are located. Cc: stable@vger.kernel.org Signed-off-by: Pavankumar Kondeti Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20211008092547.3996295-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit fa3093d37cceb5d126ef8a4c12a9fbf373052915 Author: Jonathan Bell Date: Fri Oct 8 12:25:44 2021 +0300 xhci: add quirk for host controllers that don't update endpoint DCS commit 5255660b208aebfdb71d574f3952cf48392f4306 upstream. Seen on a VLI VL805 PCIe to USB controller. For non-stream endpoints at least, if the xHC halts on a particular TRB due to an error then the DCS field in the Out Endpoint Context maintained by the hardware is not updated with the current cycle state. Using the quirk XHCI_EP_CTX_BROKEN_DCS and instead fetch the DCS bit from the TRB that the xHC stopped on. [ bjorn: rebased to v5.14-rc2 ] Link: https://github.com/raspberrypi/linux/issues/3060 Cc: stable@vger.kernel.org Signed-off-by: Jonathan Bell Signed-off-by: Bjørn Mork Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20211008092547.3996295-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit eacfdec26656dc81a04ca1460cddb98aa4da731a Author: Jonathan Bell Date: Fri Oct 8 12:25:43 2021 +0300 xhci: guard accesses to ep_state in xhci_endpoint_reset() commit a01ba2a3378be85538e0183ae5367c1bc1d5aaf3 upstream. See https://github.com/raspberrypi/linux/issues/3981 Two read-modify-write cycles on ep->ep_state are not guarded by xhci->lock. Fix these. Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset") Cc: stable@vger.kernel.org Signed-off-by: Jonathan Bell Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20211008092547.3996295-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit db96c1d87c953fa79e026b1e3cb40fff5b413edd Author: Johan Hovold Date: Fri Oct 8 12:25:45 2021 +0300 USB: xhci: dbc: fix tty registration race commit 880de403777376e50bdf60def359fa50a722006f upstream. Make sure to allocate resources before registering the tty device to avoid having a racing open() and write() fail to enable rx or dereference a NULL pointer when accessing the uninitialised fifo. Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Cc: stable@vger.kernel.org # 4.16 Cc: Lu Baolu Signed-off-by: Johan Hovold Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20211008092547.3996295-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 7c0af62f11c39429fc2f8d05b239915f9eedd823 Author: Alexander Usyskin Date: Wed Oct 13 10:45:52 2021 +0300 mei: hbm: drop hbm responses on early shutdown commit 6d7163f2c49fda5658e43105a96b555c89a4548d upstream. Drop HBM responses also in the early shutdown phase where the usual traffic is allowed. Extend the rule that drop HBM responses received during the shutdown phase by also in MEI_DEV_POWERING_DOWN state. This resolves the stall if the driver is stopping in the middle of the link init or link reset. Fixes: da3eb47c90d4 ("mei: hbm: drop hbm responses on shutdown") Fixes: 36edb1407c3c ("mei: allow clients on bus to communicate in remove callback") Cc: # v5.12+ Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20211013074552.2278419-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit fe87a580929e955009b1851216c21054381a2a03 Author: Andy Shevchenko Date: Fri Oct 1 20:36:44 2021 +0300 mei: me: add Ice Lake-N device id. commit 75c10c5e7a715550afdd51ef8cfd1d975f48f9e1 upstream. Add Ice Lake-N device ID. The device can be found on MacBookPro16,2 [1]. [1]: https://linux-hardware.org/?probe=f1c5cf0c43 Signed-off-by: Andy Shevchenko Cc: stable Link: https://lore.kernel.org/r/20211001173644.16068-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit ce8f1faa8140f59f5e06408f7c83943fbe5259fd Author: James Morse Date: Fri Sep 17 16:59:58 2021 +0000 x86/resctrl: Free the ctrlval arrays when domain_setup_mon_state() fails commit 64e87d4bd3201bf8a4685083ee4daf5c0d001452 upstream. domain_add_cpu() is called whenever a CPU is brought online. The earlier call to domain_setup_ctrlval() allocates the control value arrays. If domain_setup_mon_state() fails, the control value arrays are not freed. Add the missing kfree() calls. Fixes: 1bd2a63b4f0de ("x86/intel_rdt/mba_sc: Add initialization support") Fixes: edf6fa1c4a951 ("x86/intel_rdt/cqm: Add RMID (Resource monitoring ID) management") Signed-off-by: James Morse Signed-off-by: Borislav Petkov Acked-by: Reinette Chatre Cc: Link: https://lkml.kernel.org/r/20210917165958.28313-1-james.morse@arm.com Signed-off-by: Greg Kroah-Hartman commit 0294b7ccb00baed9f7c051824839f0725e08d6bd Author: Arnd Bergmann Date: Mon Sep 27 14:15:10 2021 +0200 module: fix clang CFI with MODULE_UNLOAD=n commit 0d67e332e6df72f43eaa21228daa3a79e23093f3 upstream. When CONFIG_MODULE_UNLOAD is disabled, the module->exit member is not defined, causing a build failure: kernel/module.c:4493:8: error: no member named 'exit' in 'struct module' mod->exit = *exit; add an #ifdef block around this. Fixes: cf68fffb66d6 ("add support for Clang CFI") Acked-by: Kees Cook Reviewed-by: Sami Tolvanen Reviewed-by: Miroslav Benes Signed-off-by: Arnd Bergmann Signed-off-by: Jessica Yu Signed-off-by: Greg Kroah-Hartman commit 0e309e1152fc34ef75991d9d69b165dbf75bf26c Author: Josef Bacik Date: Tue Oct 5 16:35:27 2021 -0400 btrfs: fix abort logic in btrfs_replace_file_extents commit 4afb912f439c4bc4e6a4f3e7547f2e69e354108f upstream. Error injection testing uncovered a case where we'd end up with a corrupt file system with a missing extent in the middle of a file. This occurs because the if statement to decide if we should abort is wrong. The only way we would abort in this case is if we got a ret != -EOPNOTSUPP and we called from the file clone code. However the prealloc code uses this path too. Instead we need to abort if there is an error, and the only error we _don't_ abort on is -EOPNOTSUPP and only if we came from the clone file code. CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Nikolay Borisov Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f86531a3115fad53a3a45ef90b6b997294120103 Author: Josef Bacik Date: Fri Oct 1 13:57:18 2021 -0400 btrfs: update refs for any root except tree log roots commit d175209be04d7d263fa1a54cde7608c706c9d0d7 upstream. I hit a stuck relocation on btrfs/061 during my overnight testing. This turned out to be because we had left over extent entries in our extent root for a data reloc inode that no longer existed. This happened because in btrfs_drop_extents() we only update refs if we have SHAREABLE set or we are the tree_root. This regression was introduced by aeb935a45581 ("btrfs: don't set SHAREABLE flag for data reloc tree") where we stopped setting SHAREABLE for the data reloc tree. The problem here is we actually do want to update extent references for data extents in the data reloc tree, in fact we only don't want to update extent references if the file extents are in the log tree. Update this check to only skip updating references in the case of the log tree. This is relatively rare, because you have to be running scrub at the same time, which is what btrfs/061 does. The data reloc inode has its extents pre-allocated, and then we copy the extent into the pre-allocated chunks. We theoretically should never be calling btrfs_drop_extents() on a data reloc inode. The exception of course is with scrub, if our pre-allocated extent falls inside of the block group we are scrubbing, then the block group will be marked read only and we will be forced to cow that extent. This means we will call btrfs_drop_extents() on that range when we COW that file extent. This isn't really problematic if we do this, the data reloc inode requires that our extent lengths match exactly with the extent we are copying, thankfully we validate the extent is correct with get_new_location(), so if we happen to COW only part of the extent we won't link it in when we do the relocation, so we are safe from any other shenanigans that arise because of this interaction with scrub. Fixes: aeb935a45581 ("btrfs: don't set SHAREABLE flag for data reloc tree") CC: stable@vger.kernel.org # 5.8+ Reviewed-by: Qu Wenruo Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 5dbc0d798074ac19ee04ad42d4b9f09d54d85b68 Author: Filipe Manana Date: Fri Oct 1 13:48:18 2021 +0100 btrfs: check for error when looking up inode during dir entry replay commit cfd312695b71df04c3a2597859ff12c470d1e2e4 upstream. At replay_one_name(), we are treating any error from btrfs_lookup_inode() as if the inode does not exists. Fix this by checking for an error and returning it to the caller. CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 439cce2df9251b58564f4c359adea99c130afaf9 Author: Filipe Manana Date: Fri Oct 1 13:52:32 2021 +0100 btrfs: deal with errors when adding inode reference during log replay commit 52db77791fe24538c8aa2a183248399715f6b380 upstream. At __inode_add_ref(), we treating any error returned from btrfs_lookup_dir_item() or from btrfs_lookup_dir_index_item() as meaning that there is no existing directory entry in the fs/subvolume tree. This is not correct since we can get errors such as, for example, -EIO when reading extent buffers while searching the fs/subvolume's btree. So fix that and return the error to the caller when it is not -ENOENT. CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 790dbfcd43a03af561060c1392f83704109a39f9 Author: Filipe Manana Date: Fri Oct 1 13:52:31 2021 +0100 btrfs: deal with errors when replaying dir entry during log replay commit e15ac6413745e3def00e663de00aea5a717311c1 upstream. At replay_one_one(), we are treating any error returned from btrfs_lookup_dir_item() or from btrfs_lookup_dir_index_item() as meaning that there is no existing directory entry in the fs/subvolume tree. This is not correct since we can get errors such as, for example, -EIO when reading extent buffers while searching the fs/subvolume's btree. So fix that and return the error to the caller when it is not -ENOENT. CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 0adda9f173f1e1f67b89c7257a5d21d4abfbbfb2 Author: Qu Wenruo Date: Tue Sep 14 14:57:59 2021 +0800 btrfs: unlock newly allocated extent buffer after error commit 19ea40dddf1833db868533958ca066f368862211 upstream. [BUG] There is a bug report that injected ENOMEM error could leave a tree block locked while we return to user-space: BTRFS info (device loop0): enabling ssd optimizations FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 0 PID: 7579 Comm: syz-executor Not tainted 5.15.0-rc1 #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 fail_dump lib/fault-inject.c:52 [inline] should_fail+0x13c/0x160 lib/fault-inject.c:146 should_failslab+0x5/0x10 mm/slab_common.c:1328 slab_pre_alloc_hook.constprop.99+0x4e/0xc0 mm/slab.h:494 slab_alloc_node mm/slub.c:3120 [inline] slab_alloc mm/slub.c:3214 [inline] kmem_cache_alloc+0x44/0x280 mm/slub.c:3219 btrfs_alloc_delayed_extent_op fs/btrfs/delayed-ref.h:299 [inline] btrfs_alloc_tree_block+0x38c/0x670 fs/btrfs/extent-tree.c:4833 __btrfs_cow_block+0x16f/0x7d0 fs/btrfs/ctree.c:415 btrfs_cow_block+0x12a/0x300 fs/btrfs/ctree.c:570 btrfs_search_slot+0x6b0/0xee0 fs/btrfs/ctree.c:1768 btrfs_insert_empty_items+0x80/0xf0 fs/btrfs/ctree.c:3905 btrfs_new_inode+0x311/0xa60 fs/btrfs/inode.c:6530 btrfs_create+0x12b/0x270 fs/btrfs/inode.c:6783 lookup_open+0x660/0x780 fs/namei.c:3282 open_last_lookups fs/namei.c:3352 [inline] path_openat+0x465/0xe20 fs/namei.c:3557 do_filp_open+0xe3/0x170 fs/namei.c:3588 do_sys_openat2+0x357/0x4a0 fs/open.c:1200 do_sys_open+0x87/0xd0 fs/open.c:1216 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x46ae99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f46711b9c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 000000000078c0a0 RCX: 000000000046ae99 RDX: 0000000000000000 RSI: 00000000000000a1 RDI: 0000000020005800 RBP: 00007f46711b9c80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000017 R13: 0000000000000000 R14: 000000000078c0a0 R15: 00007ffc129da6e0 ================================================ WARNING: lock held when returning to user space! 5.15.0-rc1 #16 Not tainted ------------------------------------------------ syz-executor/7579 is leaving the kernel with locks still held! 1 lock held by syz-executor/7579: #0: ffff888104b73da8 (btrfs-tree-01/1){+.+.}-{3:3}, at: __btrfs_tree_lock+0x2e/0x1a0 fs/btrfs/locking.c:112 [CAUSE] In btrfs_alloc_tree_block(), after btrfs_init_new_buffer(), the new extent buffer @buf is locked, but if later operations like adding delayed tree ref fail, we just free @buf without unlocking it, resulting above warning. [FIX] Unlock @buf in out_free_buf: label. Reported-by: Hao Sun Link: https://lore.kernel.org/linux-btrfs/CACkBjsZ9O6Zr0KK1yGn=1rQi6Crh1yeCRdTSBxx9R99L4xdn-Q@mail.gmail.com/ CC: stable@vger.kernel.org # 5.4+ Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 697ee8c3d3fadfeb3ac270a3a3d2ce42b2c07557 Author: Marek Vasut Date: Fri Sep 17 02:59:13 2021 +0200 drm/msm: Avoid potential overflow in timeout_to_jiffies() commit 171316a68d9a8e0d9e28b7cf4c15afc4c6244a4e upstream. The return type of ktime_divns() is s64. The timeout_to_jiffies() currently assigns the result of this ktime_divns() to unsigned long, which on 32 bit systems may overflow. Furthermore, the result of this function is sometimes also passed to functions which expect signed long, dma_fence_wait_timeout() is one such example. Fix this by adjusting the type of remaining_jiffies to s64, so we do not suffer overflow there, and return a value limited to range of 0..INT_MAX, which is safe for all usecases of this timeout. The above overflow can be triggered if userspace passes in too large timeout value, larger than INT_MAX / HZ seconds. The kernel detects it and complains about "schedule_timeout: wrong timeout value %lx" and generates a warning backtrace. Note that this fixes commit 6cedb8b377bb ("drm/msm: avoid using 'timespec'"), because the previously used timespec_to_jiffies() function returned unsigned long instead of s64: static inline unsigned long timespec_to_jiffies(const struct timespec *value) Fixes: 6cedb8b377bb ("drm/msm: avoid using 'timespec'") Signed-off-by: Marek Vasut Cc: Arnd Bergmann Cc: Jordan Crouse Cc: Rob Clark Cc: stable@vger.kernel.org # 5.6+ Acked-by: Arnd Bergmann Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210917005913.157379-1-marex@denx.de Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 2479f72f5328aaca1ca63f8e76a0ba97982fe997 Author: Fabio Estevam Date: Tue Sep 14 14:48:31 2021 -0300 drm/msm: Do not run snapshot on non-DPU devices commit 6a7e0b0e9fb839caa7c7f25bcf91a95b1c2cbef1 upstream. Since commit 98659487b845 ("drm/msm: add support to take dpu snapshot") the following NULL pointer dereference is seen on i.MX53: [ 3.275493] msm msm: bound 30000000.gpu (ops a3xx_ops) [ 3.287174] [drm] Initialized msm 1.8.0 20130625 for msm on minor 0 [ 3.293915] 8<--- cut here --- [ 3.297012] Unable to handle kernel NULL pointer dereference at virtual address 00000028 [ 3.305244] pgd = (ptrval) [ 3.307989] [00000028] *pgd=00000000 [ 3.311624] Internal error: Oops: 805 [#1] SMP ARM [ 3.316430] Modules linked in: [ 3.319503] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+g682d702b426b #1 [ 3.326652] Hardware name: Freescale i.MX53 (Device Tree Support) [ 3.332754] PC is at __mutex_init+0x14/0x54 [ 3.336969] LR is at msm_disp_snapshot_init+0x24/0xa0 i.MX53 does not use the DPU controller. Fix the problem by only calling msm_disp_snapshot_init() on platforms that use the DPU controller. Cc: stable@vger.kernel.org Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot") Signed-off-by: Fabio Estevam Link: https://lore.kernel.org/r/20210914174831.2044420-1-festevam@gmail.com Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 95a9523afb3da9456fad8b58f7093d7df79b20f9 Author: Marek Vasut Date: Thu Oct 7 23:41:17 2021 +0200 drm/nouveau/fifo: Reinstate the correct engine bit programming commit d1d94b0129dccd226784633c60b7df90e8a051b5 upstream. Commit 64f7c698bea9 ("drm/nouveau/fifo: add engine_id hook") replaced fifo/chang84.c g84_fifo_chan_engine() call with an indirect call of fifo/g84.c g84_fifo_engine_id(). The G84_FIFO_ENGN_* values returned from the later g84_fifo_engine_id() are incremented by 1 compared to the previous g84_fifo_chan_engine() return values. This is fine either way for most of the code, except this one line where an engine bit programmed into the hardware is derived from the return value. Decrement the return value accordingly, otherwise the wrong engine bit is programmed into the hardware and that leads to the following failure: nouveau 0000:01:00.0: gr: 00000030 [ILLEGAL_MTHD ILLEGAL_CLASS] ch 1 [003fbce000 DRM] subc 3 class 0000 mthd 085c data 00000420 On the following hardware: lspci -s 01:00.0 01:00.0 VGA compatible controller: NVIDIA Corporation GT216GLM [Quadro FX 880M] (rev a2) lspci -ns 01:00.0 01:00.0 0300: 10de:0a3c (rev a2) Fixes: 64f7c698bea9 ("drm/nouveau/fifo: add engine_id hook") Signed-off-by: Marek Vasut Cc: # 5.12+ Cc: Ben Skeggs Cc: Karol Herbst Cc: Lyude Paul Reviewed-by: Karol Herbst Reviewed-by: Ben Skeggs Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20211007214117.231472-1-marex@denx.de Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 0af9c042cd6ed66cced6c9cf61801d19729b63e0 Author: Mike Kravetz Date: Tue Oct 5 13:25:29 2021 -0700 arm64/hugetlb: fix CMA gigantic page order for non-4K PAGE_SIZE commit 2e5809a4ddb15969503e43b06662a9a725f613ea upstream. For non-4K PAGE_SIZE configs, the largest gigantic huge page size is CONT_PMD_SHIFT order. On arm64 with 64K PAGE_SIZE, the gigantic page is 16G. Therefore, one should be able to specify 'hugetlb_cma=16G' on the kernel command line so that one gigantic page can be allocated from CMA. However, when adding such an option the following message is produced: hugetlb_cma: cma area should be at least 8796093022208 MiB This is because the calculation for non-4K gigantic page order is incorrect in the arm64 specific routine arm64_hugetlb_cma_reserve(). Fixes: abb7962adc80 ("arm64/hugetlb: Reserve CMA areas for gigantic pages on 16K and 64K configs") Cc: # 5.9.x Signed-off-by: Mike Kravetz Reviewed-by: Anshuman Khandual Link: https://lore.kernel.org/r/20211005202529.213812-1-mike.kravetz@oracle.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit f66b6d61f2e33ee8f9e2d4835f90ebedccd56ebe Author: Thomas Zimmermann Date: Tue Oct 5 09:03:55 2021 +0200 drm/fbdev: Clamp fbdev surface size if too large commit b693e42921e0220c0d564c55c6cdc680b0f85390 upstream. Clamp the fbdev surface size of the available maximumi height to avoid failing to init console emulation. An example error is shown below. bad framebuffer height 2304, should be >= 768 && <= 768 [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0 simple-framebuffer simple-framebuffer.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-22) This is especially a problem with drivers that have very small screen sizes and cannot over-allocate at all. v2: * reduce warning level (Ville) Signed-off-by: Thomas Zimmermann Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Reviewed-by: Ville Syrjälä Reviewed-by: Alex Deucher Reported-by: Amanoel Dawod Reported-by: Zoltán Kővágó Reported-by: Michael Stapelberg Cc: Daniel Vetter Cc: Maxime Ripard Cc: dri-devel@lists.freedesktop.org Cc: # v5.14+ Link: https://patchwork.freedesktop.org/patch/msgid/20211005070355.7680-1-tzimmermann@suse.de Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 2c7820141702e00fd1c204ad4fab42544008a9a1 Author: Guo Ren Date: Fri Sep 24 15:33:38 2021 +0800 csky: Fixup regs.sr broken in ptrace commit af89ebaa64de726ca0a39bbb0bf0c81a1f43ad50 upstream. gpr_get() return the entire pt_regs (include sr) to userspace, if we don't restore the C bit in gpr_set, it may break the ALU result in that context. So the C flag bit is part of gpr context, that's why riscv totally remove the C bit in the ISA. That makes sr reg clear from userspace to supervisor privilege. Signed-off-by: Guo Ren Cc: Al Viro Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f8e8e5448c77cd186ba606ca3fe79973b6febb39 Author: Al Viro Date: Fri Sep 24 00:35:42 2021 +0000 csky: don't let sigreturn play with priveleged bits of status register commit fbd63c08cdcca5fb1315aca3172b3c9c272cfb4f upstream. csky restore_sigcontext() blindly overwrites regs->sr with the value it finds in sigcontext. Attacker can store whatever they want in there, which includes things like S-bit. Userland shouldn't be able to set that, or anything other than C flag (bit 0). Do the same thing other architectures with protected bits in flags register do - preserve everything that shouldn't be settable in user mode, picking the rest from the value saved is sigcontext. Signed-off-by: Al Viro Signed-off-by: Guo Ren Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 46f067744387955b46842afa744ab53e41192f9f Author: Dinh Nguyen Date: Thu Sep 16 17:51:26 2021 -0500 clk: socfpga: agilex: fix duplicate s2f_user0_clk commit 09540fa337196be20e9f0241652364f09275d374 upstream. Remove the duplicate s2f_user0_clk and the unused s2f_usr0_mux define. Fixes: f817c132db67 ("clk: socfpga: agilex: fix up s2f_user0_clk representation") Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20210916225126.1427700-1-dinguyen@kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit d429630cde94a0b924fad36691139483df4aad85 Author: Roberto Sassu Date: Tue Oct 5 14:08:36 2021 +0200 s390: fix strrchr() implementation commit 8e0ab8e26b72a80e991c66a8abc16e6c856abe3d upstream. Fix two problems found in the strrchr() implementation for s390 architectures: evaluate empty strings (return the string address instead of NULL, if '\0' is passed as second argument); evaluate the first character of non-empty strings (the current implementation stops at the second). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Heiko Carstens (incorrect behavior with empty strings) Signed-off-by: Roberto Sassu Link: https://lore.kernel.org/r/20211005120836.60630-1-roberto.sassu@huawei.com Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 8ca9745efe3528feb06ca4e117188038eea2d351 Author: Ming Lei Date: Thu Sep 23 17:11:31 2021 +0800 dm rq: don't queue request to blk-mq during DM suspend commit b4459b11e84092658fa195a2587aff3b9637f0e7 upstream. DM uses blk-mq's quiesce/unquiesce to stop/start device mapper queue. But blk-mq's unquiesce may come from outside events, such as elevator switch, updating nr_requests or others, and request may come during suspend, so simply ask for blk-mq to requeue it. Fixes one kernel panic issue when running updating nr_requests and dm-mpath suspend/resume stress test. Cc: stable@vger.kernel.org Signed-off-by: Ming Lei Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit d856f5d13d656b0b78ef974ed14c124a48dd3eff Author: Sachi King Date: Sat Oct 2 14:18:40 2021 +1000 ACPI: PM: Include alternate AMDI0005 id in special behaviour commit 1ea1dbf1f54c3345072c963b3acf8830e2468c1b upstream. The Surface Laptop 4 AMD has used the AMD0005 to identify this controller instead of using the appropriate ACPI ID AMDI0005. The AMD0005 needs the same special casing as AMDI0005. Link: https://github.com/linux-surface/acpidumps/tree/master/surface_laptop_4_amd Link: https://gist.github.com/nakato/2a1a7df1a45fe680d7a08c583e1bf863 Signed-off-by: Sachi King Reviewed-by: Mario Limonciello Cc: 5.14+ # 5.14+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 6e506f07c5b561d673dd0b0d8f7f420cc48024fb Author: Jiazi Li Date: Wed Sep 29 19:59:28 2021 +0800 dm: fix mempool NULL pointer race when completing IO commit d208b89401e073de986dc891037c5a668f5d5d95 upstream. dm_io_dec_pending() calls end_io_acct() first and will then dec md in-flight pending count. But if a task is swapping DM table at same time this can result in a crash due to mempool->elements being NULL: task1 task2 do_resume ->do_suspend ->dm_wait_for_completion bio_endio ->clone_endio ->dm_io_dec_pending ->end_io_acct ->wakeup task1 ->dm_swap_table ->__bind ->__bind_mempools ->bioset_exit ->mempool_exit ->free_io [ 67.330330] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ...... [ 67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 67.330510] pc : mempool_free+0x70/0xa0 [ 67.330515] lr : mempool_free+0x4c/0xa0 [ 67.330520] sp : ffffff8008013b20 [ 67.330524] x29: ffffff8008013b20 x28: 0000000000000004 [ 67.330530] x27: ffffffa8c2ff40a0 x26: 00000000ffff1cc8 [ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800 [ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800 [ 67.330547] x21: 00000000ffff1cc8 x20: ffffffd9a1304d80 [ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c [ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd [ 67.330563] x15: 000000000093b41e x14: 0000000000000010 [ 67.330569] x13: 0000000000007f7a x12: 0000000034155555 [ 67.330574] x11: 0000000000000001 x10: 0000000000000001 [ 67.330579] x9 : 0000000000000000 x8 : 0000000000000000 [ 67.330585] x7 : 0000000000000000 x6 : ffffff80148b5c1a [ 67.330590] x5 : ffffff8008013ae0 x4 : 0000000000000001 [ 67.330596] x3 : ffffff80080139c8 x2 : ffffff801083bab8 [ 67.330601] x1 : 0000000000000000 x0 : ffffffdada34c970 [ 67.330609] Call trace: [ 67.330616] mempool_free+0x70/0xa0 [ 67.330627] bio_put+0xf8/0x110 [ 67.330638] dec_pending+0x13c/0x230 [ 67.330644] clone_endio+0x90/0x180 [ 67.330649] bio_endio+0x198/0x1b8 [ 67.330655] dec_pending+0x190/0x230 [ 67.330660] clone_endio+0x90/0x180 [ 67.330665] bio_endio+0x198/0x1b8 [ 67.330673] blk_update_request+0x214/0x428 [ 67.330683] scsi_end_request+0x2c/0x300 [ 67.330688] scsi_io_completion+0xa0/0x710 [ 67.330695] scsi_finish_command+0xd8/0x110 [ 67.330700] scsi_softirq_done+0x114/0x148 [ 67.330708] blk_done_softirq+0x74/0xd0 [ 67.330716] __do_softirq+0x18c/0x374 [ 67.330724] irq_exit+0xb4/0xb8 [ 67.330732] __handle_domain_irq+0x84/0xc0 [ 67.330737] gic_handle_irq+0x148/0x1b0 [ 67.330744] el1_irq+0xe8/0x190 [ 67.330753] lpm_cpuidle_enter+0x4f8/0x538 [ 67.330759] cpuidle_enter_state+0x1fc/0x398 [ 67.330764] cpuidle_enter+0x18/0x20 [ 67.330772] do_idle+0x1b4/0x290 [ 67.330778] cpu_startup_entry+0x20/0x28 [ 67.330786] secondary_start_kernel+0x160/0x170 Fix this by: 1) Establishing pointers to 'struct dm_io' members in dm_io_dec_pending() so that they may be passed into end_io_acct() _after_ free_io() is called. 2) Moving end_io_acct() after free_io(). Cc: stable@vger.kernel.org Signed-off-by: Jiazi Li Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 594a97f7617b98a0c9412e8877b1ba63fdac240d Author: Steven Rostedt Date: Thu Oct 14 14:35:07 2021 -0400 nds32/ftrace: Fix Error: invalid operands (*UND* and *UND* sections) for `^' commit be358af1191b1b2fedebd8f3421cafdc8edacc7d upstream. I received a build failure for a new patch I'm working on the nds32 architecture, and when I went to test it, I couldn't get to my build error, because it failed to build with a bunch of: Error: invalid operands (*UND* and *UND* sections) for `^' issues with various files. Those files were temporary asm files that looked like: kernel/.tmp_mc_fork.s I decided to look deeper, and found that the "mc" portion of that name stood for "mcount", and was created by the recordmcount.pl script. One that I wrote over a decade ago. Once I knew the source of the problem, I was able to investigate it further. The way the recordmcount.pl script works (BTW, there's a C version that simply modifies the ELF object) is by doing an "objdump" on the object file. Looks for all the calls to "mcount", and creates an offset of those locations from some global variable it can use (usually a global function name, found with <.*>:). Creates a asm file that is a table of references to these locations, using the found variable/function. Compiles it and links it back into the original object file. This asm file is called ".tmp_mc_.s". The problem here is that the objdump produced by the nds32 object file, contains things that look like: 0000159a <.L3^B1>: 159a: c6 00 beqz38 $r6, 159a <.L3^B1> 159a: R_NDS32_9_PCREL_RELA .text+0x159e 159c: 84 d2 movi55 $r6, #-14 159e: 80 06 mov55 $r0, $r6 15a0: ec 3c addi10.sp #0x3c Where ".L3^B1 is somehow selected as the "global" variable to index off of. Then the assembly file that holds the mcount locations looks like this: .section __mcount_loc,"a",@progbits .align 2 .long .L3^B1 + -5522 .long .L3^B1 + -5384 .long .L3^B1 + -5270 .long .L3^B1 + -5098 .long .L3^B1 + -4970 .long .L3^B1 + -4758 .long .L3^B1 + -4122 [...] And when it is compiled back to an object to link to the original object, the compile fails on the "^" symbol. Simple solution for now, is to have the perl script ignore using function symbols that have an "^" in the name. Link: https://lkml.kernel.org/r/20211014143507.4ad2c0f7@gandalf.local.home Cc: stable@vger.kernel.org Acked-by: Greentime Hu Fixes: fbf58a52ac088 ("nds32/ftrace: Add RECORD_MCOUNT support") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 24262c6439c6401455242a75ff22326b54f797fd Author: Md Sadre Alam Date: Tue Sep 7 12:35:57 2021 +0530 mtd: rawnand: qcom: Update code word value for raw read commit f60f5741002b9fde748cff65fd09bd6222c5db0c upstream. From QPIC V2 onwards there is a separate register to read last code word "QPIC_NAND_READ_LOCATION_LAST_CW_n". qcom_nandc_read_cw_raw() is used to read only one code word at a time. If we will configure number of code words to 1 in in QPIC_NAND_DEV0_CFG0 register then QPIC controller thinks its reading the last code word, since from QPIC V2 onwards we are having separate register to read the last code word, we have to configure "QPIC_NAND_READ_LOCATION_LAST_CW_n" register to fetch data from controller buffer to system memory. Fixes: 503ee5aad430 ("mtd: rawnand: qcom: update last code word register") Cc: stable@kernel.org Signed-off-by: Md Sadre Alam Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/1630998357-1359-1-git-send-email-mdalam@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit f7744bdec09f33e0924a87457e701c83313f6286 Author: Ville Baillie Date: Tue Sep 21 07:21:32 2021 +0000 spi: atmel: Fix PDC transfer setup bug commit 75e33c55ae8fb4a177fe07c284665e1d61b02560 upstream. atmel_spi_dma_map_xfer to never be called in PDC mode. This causes the driver to silently fail. This patch changes the conditional to match the behaviour of the previous commit before the refactor. Fixes: 5fa5e6dec762 ("spi: atmel: Switch to transfer_one transfer method") Signed-off-by: Ville Baillie Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210921072132.21831-1-villeb@bytesnap.co.uk Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 26a88eedfc88b30568ebd5ed6c40065d7dfe630c Author: Sachi King Date: Sat Oct 2 14:18:39 2021 +1000 platform/x86: amd-pmc: Add alternative acpi id for PMC controller commit c0d84d2c7c23e9cf23a5abdda40eeaa79eabfe69 upstream. The Surface Laptop 4 AMD has used the AMD0005 to identify this controller instead of using the appropriate ACPI ID AMDI0005. Include AMD0005 in the acpi id list. Link: https://github.com/linux-surface/acpidumps/tree/master/surface_laptop_4_amd Link: https://gist.github.com/nakato/2a1a7df1a45fe680d7a08c583e1bf863 Cc: # 5.14+ Signed-off-by: Sachi King Reviewed-by: Mario Limonciello Link: https://lore.kernel.org/r/20211002041840.2058647-1-nakato@nakato.io Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 1a707ec090e9f9ddf58dbe761d79b68c8a3bc0a2 Author: Zephaniah E. Loss-Cutler-Hull Date: Mon Oct 4 21:48:55 2021 -0700 platform/x86: gigabyte-wmi: add support for B550 AORUS ELITE AX V2 commit 0f607d6b227470456a69a37d7c7badea51d52844 upstream. This works just fine on my system. Signed-off-by: Zephaniah E. Loss-Cutler-Hull Cc: Link: https://lore.kernel.org/r/20211005044855.1429724-1-zephaniah@gmail.com Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 52d44bd028c14986e300ff0a0468b6eef3053a6d Author: Hui Wang Date: Tue Oct 12 19:47:48 2021 +0800 ALSA: hda/realtek: Fix the mic type detection issue for ASUS G551JW commit a3fd1a986e499a06ac5ef95c3a39aa4611e7444c upstream. We need to define the codec pin 0x1b to be the mic, but somehow the mic doesn't support hot plugging detection, and Windows also has this issue, so we set it to phantom headset-mic. Also the determine_headset_type() often returns the omtp type by a mistake when we plug a ctia headset, this makes the mic can't record sound at all. Because most of the headset are ctia type nowadays and some machines have the fixed ctia type audio jack, it is possible this machine has the fixed ctia jack too. Here we set this mic jack to fixed ctia type, this could avoid the mic type detection mistake and make the ctia headset work stable. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214537 Reported-and-tested-by: msd Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20211012114748.5238-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8c5628cbb26e8365d2ce608cea31a0a0f5daa049 Author: Cameron Berkenpas Date: Sun Oct 10 15:54:11 2021 -0700 ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2 commit 023a062f238129e8a542b5163c4350ceb076283e upstream. The previous patch's HDA verb initialization for the Lenovo 13s sequence was slightly off. This updated verb sequence has been tested and confirmed working. Fixes: ad7cc2d41b7a ("ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops.") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555 Cc: Signed-off-by: Cameron Berkenpas Link: https://lore.kernel.org/r/20211010225410.23423-1-cam@neo-zeon.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9a13d0f9c3d956f3edb3ab7fe105677c1a1f595a Author: Werner Sembach Date: Wed Oct 6 15:04:15 2021 +0200 ALSA: hda/realtek: Add quirk for TongFang PHxTxX1 commit dd6dd6e3c791db7fdbc5433ec7e450717aa3a0ce upstream. This applies a SND_PCI_QUIRK(...) to the TongFang PHxTxX1 barebone. This fixes the issue of the internal Microphone not working after booting another OS. When booting a certain another OS this barebone keeps some coeff settings even after a cold shutdown. These coeffs prevent the microphone detection from working in Linux, making the Laptop think that there is always an external microphone plugged-in and therefore preventing the use of the internal one. The relevant indexes and values where gathered by naively diff-ing and reading a working and a non-working coeff dump. Signed-off-by: Werner Sembach Cc: Link: https://lore.kernel.org/r/20211006130415.538243-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f8d3c17e1c3720a1497b5c5db514a832834610d1 Author: Kailang Yang Date: Tue Oct 5 14:35:14 2021 +0800 ALSA: hda/realtek - ALC236 headset MIC recording issue commit 5aec98913095ed3b4424ed6c5fdeb6964e9734da upstream. In power save mode, the recording voice from headset mic will 2s more delay. Add this patch will solve this issue. [ minor coding style fix by tiwai ] Signed-off-by: Kailang Yang Tested-by: Kai-Heng Feng Cc: Link: https://lore.kernel.org/r/ccb0cdd5bbd7486eabbd8d987d384cb0@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1f923b81f49e904b2d85eaba9d6a96e549da8fd3 Author: Werner Sembach Date: Fri Oct 1 15:31:11 2021 +0200 ALSA: hda/realtek: Add quirk for Clevo X170KM-G commit cc03069a397005da24f6783835c274d5aedf6043 upstream. This applies a SND_PCI_QUIRK(...) to the Clevo X170KM-G barebone. This fixes the issue of the devices internal Speaker not working. Signed-off-by: Werner Sembach Cc: Link: https://lore.kernel.org/r/20211001133111.428249-3-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 07015c2e0f35cbc3e5c6032f5eba415bb28ff4c1 Author: Werner Sembach Date: Fri Oct 1 15:31:10 2021 +0200 ALSA: hda/realtek: Complete partial device name to avoid ambiguity commit 1f8d398e1cd8813f8ec16d55c086e8270a9c18ab upstream. The string "Clevo X170" is not enough to unambiguously identify the correct device. Fixing it so another Clevo barebone name starting with "X170" can be added without causing confusion. Signed-off-by: Werner Sembach Cc: Link: https://lore.kernel.org/r/20211001133111.428249-2-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a2fc31b3699ad3fdbe11e9b881bfbb0404e540ff Author: Chris Chiu Date: Fri Oct 1 14:28:56 2021 +0800 ALSA: hda - Enable headphone mic on Dell Latitude laptops with ALC3254 commit 2b987fe84429361c7f189568c476d1bd00d2ff7e upstream. The headphone mic is not working on Dell Latitude laptops with ALC3254. The codec vendor id is 0x10ec0295 and share the same pincfg as defined in ALC295_STANDARD_PINS. So the ALC269_FIXUP_DELL1_MIC_NO_PRESENCE will be applied per alc269_pin_fixup_tbl[] but actually the headphone mic is using NID 0x1b instead of 0x1a. The ALC269_FIXUP_DELL4_MIC_NO_PRESENCE need to be applied instead. Use ALC269_FIXUP_DELL4_MIC_NO_PRESENCE for particular models before a generic fixup comes out. Signed-off-by: Chris Chiu Cc: Link: https://lore.kernel.org/r/20211001062856.1037901-1-chris.chiu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 72653bfc9b9d0b0755089bd9bec492a7a1393592 Author: John Liu Date: Thu Sep 30 13:53:16 2021 +0200 ALSA: hda/realtek: Enable 4-speaker output for Dell Precision 5560 laptop commit eb676622846b34a751e2ff9b5910a5322a4e0000 upstream. The Dell Precision 5560 laptop appears to use the 4-speakers-on-ALC289 audio just like its sibling product XPS 9510, so it requires the same quirk to enable woofer output. Tested on my Dell Precision 5560. Signed-off-by: John Liu Cc: Link: https://lore.kernel.org/r/20210930115316.659-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 14137ae740cb8819db011eb7558f1df00a2b3592 Author: Takashi Iwai Date: Thu Sep 30 13:41:14 2021 +0200 ALSA: seq: Fix a potential UAF by wrong private_free call order commit 1f8763c59c4ec6254d629fe77c0a52220bd907aa upstream. John Keeping reported and posted a patch for a potential UAF in rawmidi sequencer destruction: the snd_rawmidi_dev_seq_free() may be called after the associated rawmidi object got already freed. After a deeper look, it turned out that the bug is rather the incorrect private_free call order for a snd_seq_device. The snd_seq_device private_free gets called at the release callback of the sequencer device object, while this was rather expected to be executed at the snd_device call chains that runs at the beginning of the whole card-free procedure. It's been broken since the rewrite of sequencer-device binding (although it hasn't surfaced because the sequencer device release happens usually right along with the card device release). This patch corrects the private_free call to be done in the right place, at snd_seq_device_dev_free(). Fixes: 7c37ae5c625a ("ALSA: seq: Rewrite sequencer device binding with standard bus") Reported-and-tested-by: John Keeping Cc: Link: https://lore.kernel.org/r/20210930114114.8645-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dfd5633ae7755809be1fee84cc250684f133df93 Author: Takashi Iwai Date: Wed Sep 29 09:35:40 2021 +0200 ALSA: usb-audio: Fix a missing error check in scarlett gen2 mixer commit 8ec59ac3ad29891c0afef627640df36f2daa0349 upstream. The check of the returned error code is missing in scarlett2_update_monitor_other(). Let's fix it. Fixes: d5bda7e03982 ("ALSA: usb-audio: scarlett2: Add support for the talkback feature") Reported-by: kernel test robot Cc: Link: https://lore.kernel.org/r/202109131831.9IodEzRx-lkp@intel.com Link: https://lore.kernel.org/r/20210929073540.9611-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1a98c3c687956a9a239286e7b98389f8e8f8961b Author: Takashi Iwai Date: Sun Oct 10 09:55:46 2021 +0200 ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctl commit 228af5a4fa3a8293bd8b7ac5cf59548ee29627bf upstream. Michael Forney reported an incorrect padding type that was defined in the commit 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") for PCM control mmap data. His analysis is correct, and this caused the misplacements of PCM control data on 32bit arch and 32bit compat mode. The bug is that the __pad2 definition in __snd_pcm_mmap_control64 struct was wrongly with __pad_before_uframe, which should have been __pad_after_uframe instead. This struct is used in SYNC_PTR ioctl and control mmap. Basically this bug leads to two problems: - The offset of avail_min field becomes wrong, it's placed right after appl_ptr without padding on little-endian - When appl_ptr and avail_min are read as 64bit values in kernel side, the values become either zero or corrupted (mixed up) One good news is that, because both user-space and kernel misunderstand the wrong offset, at least, 32bit application running on 32bit kernel works as is. Also, 64bit applications are unaffected because the padding size is zero. The remaining problem is the 32bit compat mode; as mentioned in the above, avail_min is placed right after appl_ptr on little-endian archs, 64bit kernel reads bogus values for appl_ptr updates, which may lead to streaming bugs like jumping, XRUN or whatever unexpected. (However, we haven't heard any serious bug reports due to this over years, so practically seen, it's fairly safe to assume that the impact by this bug is limited.) Ideally speaking, we should correct the wrong mmap status control definition. But this would cause again incompatibility with the existing binaries, and fixing it (e.g. by renumbering ioctls) would be really messy. So, as of this patch, we only correct the behavior of 32bit compat mode and keep the rest as is. Namely, the SYNC_PTR ioctl is now handled differently in compat mode to read/write the 32bit values at the right offsets. The control mmap of 32bit apps on 64bit kernels has been already disabled (which is likely rather an overlook, but this worked fine at this time :), so covering SYNC_PTR ioctl should suffice as a fallback. Fixes: 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") Reported-by: Michael Forney Reviewed-by: Arnd Bergmann Cc: Cc: Rich Felker Link: https://lore.kernel.org/r/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org Link: https://lore.kernel.org/r/20211010075546.23220-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ca3dccb96511fe5b0d545073ffdb74390927c3f2 Author: Jonas Hahnfeld Date: Tue Oct 12 22:09:07 2021 +0200 ALSA: usb-audio: Add quirk for VF0770 commit 48827e1d6af58f219e89c7ec08dccbca28c7694e upstream. The device advertises 8 formats, but only a rate of 48kHz is honored by the hardware and 24 bits give chopped audio, so only report the one working combination. This fixes out-of-the-box audio experience with PipeWire which otherwise attempts to choose S24_3LE (while PulseAudio defaulted to S16_LE). Signed-off-by: Jonas Hahnfeld Cc: Link: https://lore.kernel.org/r/20211012200906.3492-1-hahnjo@hahnjo.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman