commit e0ee50101346ca9cef52da75e3fb4380c27c042a Author: Greg Kroah-Hartman Date: Thu Apr 20 12:37:00 2023 +0200 Linux 6.2.12 Link: https://lore.kernel.org/r/20230418120313.725598495@linuxfoundation.org Tested-by: Chris Paterson (CIP) Tested-by: Ronald Warsow Tested-by: Markus Reichelt Tested-by: Shuah Khan Tested-by: Justin M. Forbes Tested-by: Ron Economos Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20230419093655.693770727@linuxfoundation.org Link: https://lore.kernel.org/r/20230419132054.228391649@linuxfoundation.org Tested-by: Ron Economos Tested-by: Markus Reichelt Tested-by: Conor Dooley Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit 8260f9a083c1c99e155b2787e2742e2cb692b61d Author: Duy Truong Date: Thu Apr 13 17:55:48 2023 -0700 nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD [ Upstream commit 74391b3e69855e7dd65a9cef36baf5fc1345affd ] Added a quirk to fix the TeamGroup T-Force Cardea Zero Z330 SSDs reporting duplicate NGUIDs. Signed-off-by: Duy Truong Cc: stable@vger.kernel.org Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 1d0d418bb2b4bd7e179069fcb2a36d32f0d44007 Author: Juraj Pecigos Date: Sun Mar 26 11:29:49 2023 +0200 nvme-pci: mark Lexar NM760 as IGNORE_DEV_SUBNQN [ Upstream commit 1231363aec86704a6b0467a12e3ca7bdf890e01d ] A system with more than one of these SSDs will only have one usable. The kernel fails to detect more than one nvme device due to duplicate cntlids. before: [ 9.395229] nvme 0000:01:00.0: platform quirk: setting simple suspend [ 9.395262] nvme nvme0: pci function 0000:01:00.0 [ 9.395282] nvme 0000:03:00.0: platform quirk: setting simple suspend [ 9.395305] nvme nvme1: pci function 0000:03:00.0 [ 9.409873] nvme nvme0: Duplicate cntlid 1 with nvme1, subsys nqn.2022-07.com.siliconmotion:nvm-subsystem-sn- , rejecting [ 9.409982] nvme nvme0: Removing after probe failure status: -22 [ 9.427487] nvme nvme1: allocated 64 MiB host memory buffer. [ 9.445088] nvme nvme1: 16/0/0 default/read/poll queues [ 9.449898] nvme nvme1: Ignoring bogus Namespace Identifiers after: [ 1.161890] nvme 0000:01:00.0: platform quirk: setting simple suspend [ 1.162660] nvme nvme0: pci function 0000:01:00.0 [ 1.162684] nvme 0000:03:00.0: platform quirk: setting simple suspend [ 1.162707] nvme nvme1: pci function 0000:03:00.0 [ 1.191354] nvme nvme0: allocated 64 MiB host memory buffer. [ 1.193378] nvme nvme1: allocated 64 MiB host memory buffer. [ 1.211044] nvme nvme1: 16/0/0 default/read/poll queues [ 1.211080] nvme nvme0: 16/0/0 default/read/poll queues [ 1.216145] nvme nvme0: Ignoring bogus Namespace Identifiers [ 1.216261] nvme nvme1: Ignoring bogus Namespace Identifiers Adding the NVME_QUIRK_IGNORE_DEV_SUBNQN quirk to resolves the issue. Signed-off-by: Juraj Pecigos Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Stable-dep-of: 74391b3e6985 ("nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD") Signed-off-by: Sasha Levin commit 0536e50b35c6b015bf6e66ace2e9fc69596dd702 Author: David Disseldorp Date: Fri Apr 7 00:34:11 2023 +0200 cifs: fix negotiate context parsing [ Upstream commit 5105a7ffce19160e7062aee67fb6b3b8a1b56d78 ] smb311_decode_neg_context() doesn't properly check against SMB packet boundaries prior to accessing individual negotiate context entries. This is due to the length check omitting the eight byte smb2_neg_context header, as well as incorrect decrementing of len_of_ctxts. Fixes: 5100d8a3fe03 ("SMB311: Improve checking of negotiate security contexts") Reported-by: Volker Lendecke Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: David Disseldorp Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 8848804f2d5cffcf0c8685fa5b455ae47e231ec9 Author: Gregor Herburger Date: Thu Apr 13 11:37:37 2023 +0200 i2c: ocores: generate stop condition after timeout in polling mode [ Upstream commit f8160d3b35fc94491bb0cb974dbda310ef96c0e2 ] In polling mode, no stop condition is generated after a timeout. This causes SCL to remain low and thereby block the bus. If this happens during a transfer it can cause slaves to misinterpret the subsequent transfer and return wrong values. To solve this, pass the ETIMEDOUT error up from ocores_process_polling() instead of setting STATE_ERROR directly. The caller is adjusted to call ocores_process_timeout() on error both in polling and in IRQ mode, which will set STATE_ERROR and generate a stop condition. Fixes: 69c8c0c0efa8 ("i2c: ocores: add polling interface") Signed-off-by: Gregor Herburger Signed-off-by: Matthias Schiffer Acked-by: Peter Korsgaard Reviewed-by: Andrew Lunn Reviewed-by: Federico Vaga Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 40359713eb36d224fed3ca0191cb42b12f17e539 Author: Matija Glavinic Pecotic Date: Thu Apr 6 08:26:52 2023 +0200 x86/rtc: Remove __init for runtime functions [ Upstream commit 775d3c514c5b2763a50ab7839026d7561795924d ] set_rtc_noop(), get_rtc_noop() are after booting, therefore their __init annotation is wrong. A crash was observed on an x86 platform where CMOS RTC is unused and disabled via device tree. set_rtc_noop() was invoked from ntp: sync_hw_clock(), although CONFIG_RTC_SYSTOHC=n, however sync_cmos_clock() doesn't honour that. Workqueue: events_power_efficient sync_hw_clock RIP: 0010:set_rtc_noop Call Trace: update_persistent_clock64 sync_hw_clock Fix this by dropping the __init annotation from set/get_rtc_noop(). Fixes: c311ed6183f4 ("x86/init: Allow DT configured systems to disable RTC at boot time") Signed-off-by: Matija Glavinic Pecotic Signed-off-by: Thomas Gleixner Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/59f7ceb1-446b-1d3d-0bc8-1f0ee94b1e18@nokia.com Signed-off-by: Sasha Levin commit 273727f22f62d77e930f5fd069db48c7198b8f6c Author: Vincent Guittot Date: Tue Apr 11 11:06:11 2023 +0200 sched/fair: Fix imbalance overflow [ Upstream commit 91dcf1e8068e9a8823e419a7a34ff4341275fb70 ] When local group is fully busy but its average load is above system load, computing the imbalance will overflow and local group is not the best target for pulling this load. Fixes: 0b0695f2b34a ("sched/fair: Rework load_balance()") Reported-by: Tingjia Cao Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Tested-by: Tingjia Cao Link: https://lore.kernel.org/lkml/CABcWv9_DAhVBOq2=W=2ypKE9dKM5s2DvoV8-U0+GDwwuKZ89jQ@mail.gmail.com/T/ Signed-off-by: Sasha Levin commit 8e75afc2d1d47b59c2f6e6fd8733ba7fcf6efebc Author: Aneesh Kumar K.V Date: Tue Apr 4 09:44:33 2023 +0530 powerpc/papr_scm: Update the NUMA distance table for the target node [ Upstream commit b277fc793daf258877b4c0744b52f69d6e6ba22e ] Platform device helper routines won't update the NUMA distance table while creating a platform device, even if the device is present on a NUMA node that doesn't have memory or CPU. This is especially true for pmem devices. If the target node of the pmem device is not online, we find the nearest online node to the device and associate the pmem device with that online node. To find the nearest online node, we should have the numa distance table updated correctly. Update the distance information during the device probe. For a papr scm device on NUMA node 3 distance_lookup_table value for distance_ref_points_depth = 2 before and after fix is below: Before fix: node 3 distance depth 0 - 0 node 3 distance depth 1 - 0 node 4 distance depth 0 - 4 node 4 distance depth 1 - 2 node 5 distance depth 0 - 5 node 5 distance depth 1 - 1 After fix node 3 distance depth 0 - 3 node 3 distance depth 1 - 1 node 4 distance depth 0 - 4 node 4 distance depth 1 - 2 node 5 distance depth 0 - 5 node 5 distance depth 1 - 1 Without the fix, the nearest numa node to the pmem device (NUMA node 3) will be picked as 4. After the fix, we get the correct numa node which is 5. Fixes: da1115fdbd6e ("powerpc/nvdimm: Pick nearby online node if the device node is not online") Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://msgid.link/20230404041433.1781804-1-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin commit 239decac2778645153bc2723cf6d194a083ae106 Author: Tharun Kumar P Date: Mon Mar 20 19:52:37 2023 +0530 i2c: mchp-pci1xxxx: Update Timing registers [ Upstream commit aa874cdfec07d4dd9c6f0c356d65c609ba31a26f ] Update I2C timing registers based on latest hardware design. This fix does not break functionality of chips with older design and existing users will not be affected. Fixes: 361693697249 ("i2c: microchip: pci1xxxx: Add driver for I2C host controller in multifunction endpoint of pci1xxxx switch") Signed-off-by: Tharun Kumar P Reviewed-by: Andy Shevchenko Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit b2354efa80ef1aadefc4cabc63272a122402f7b9 Author: ZhaoLong Wang Date: Sat Mar 4 09:41:41 2023 +0800 ubi: Fix deadlock caused by recursively holding work_sem [ Upstream commit f773f0a331d6c41733b17bebbc1b6cae12e016f5 ] During the processing of the bgt, if the sync_erase() return -EBUSY or some other error code in __erase_worker(),schedule_erase() called again lead to the down_read(ubi->work_sem) hold twice and may get block by down_write(ubi->work_sem) in ubi_update_fastmap(), which cause deadlock. ubi bgt other task do_work down_read(&ubi->work_sem) ubi_update_fastmap erase_worker # Blocked by down_read __erase_worker down_write(&ubi->work_sem) schedule_erase schedule_ubi_work down_read(&ubi->work_sem) Fix this by changing input parameter @nested of the schedule_erase() to 'true' to avoid recursively acquiring the down_read(&ubi->work_sem). Also, fix the incorrect comment about @nested parameter of the schedule_erase() because when down_write(ubi->work_sem) is held, the @nested is also need be true. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217093 Fixes: 2e8f08deabbc ("ubi: Fix races around ubi_refill_pools()") Signed-off-by: ZhaoLong Wang Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 69f65bb91d7470af6273e54436efd0bec1ff88a5 Author: Zhihao Cheng Date: Mon Mar 6 09:33:08 2023 +0800 ubi: Fix failure attaching when vid_hdr offset equals to (sub)page size commit 1e020e1b96afdecd20680b5b5be2a6ffc3d27628 upstream. Following process will make ubi attaching failed since commit 1b42b1a36fc946 ("ubi: ensure that VID header offset ... size"): ID="0xec,0xa1,0x00,0x15" # 128M 128KB 2KB modprobe nandsim id_bytes=$ID flash_eraseall /dev/mtd0 modprobe ubi mtd="0,2048" # set vid_hdr offset as 2048 (one page) (dmesg): ubi0 error: ubi_attach_mtd_dev [ubi]: VID header offset 2048 too large. UBI error: cannot attach mtd0 UBI error: cannot initialize UBI, error -22 Rework original solution, the key point is making sure 'vid_hdr_shift + UBI_VID_HDR_SIZE < ubi->vid_hdr_alsize', so we should check vid_hdr_shift rather not vid_hdr_offset. Then, ubi still support (sub)page aligined VID header offset. Fixes: 1b42b1a36fc946 ("ubi: ensure that VID header offset ... size") Signed-off-by: Zhihao Cheng Tested-by: Nicolas Schichan Tested-by: Miquel Raynal # v5.10, v4.19 Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit a096a78d70a012b47d0ab50cfd26905a39506bf8 Author: Matthieu Baerts Date: Tue Apr 11 22:42:12 2023 +0200 selftests: mptcp: userspace pm: uniform verify events commit 711ae788cbbb82818531b55e32b09518ee09a11a upstream. Simply adding a "sleep" before checking something is usually not a good idea because the time that has been picked can not be enough or too much. The best is to wait for events with a timeout. In this selftest, 'sleep 0.5' is used more than 40 times. It is always used before calling a 'verify_*' function except for this verify_listener_events which has been added later. At the end, using all these 'sleep 0.5' seems to work: the slow CIs don't complain so far. Also because it doesn't take too much time, we can just add two more 'sleep 0.5' to uniform what is done before calling a 'verify_*' function. For the same reasons, we can also delay a bigger refactoring to replace all these 'sleep 0.5' by functions waiting for events instead of waiting for a fix time and hope for the best. Fixes: 6c73008aa301 ("selftests: mptcp: listener test for userspace PM") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Signed-off-by: Matthieu Baerts Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 95135835519b0ab931c39908b2c99e9fb3c9068b Author: Paolo Abeni Date: Tue Apr 11 22:42:11 2023 +0200 mptcp: fix NULL pointer dereference on fastopen early fallback commit c0ff6f6da66a7791a32c0234388b1bdc00244917 upstream. In case of early fallback to TCP, subflow_syn_recv_sock() deletes the subflow context before returning the newly allocated sock to the caller. The fastopen path does not cope with the above unconditionally dereferencing the subflow context. Fixes: 36b122baf6a8 ("mptcp: add subflow_v(4,6)_send_synack()") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 19ea79e87af32c2b3c6fc49bd84efeb35ca57678 Author: Paolo Abeni Date: Tue Apr 11 22:42:10 2023 +0200 mptcp: stricter state check in mptcp_worker commit d6a0443733434408f2cbd4c53fea6910599bab9e upstream. As reported by Christoph, the mptcp protocol can run the worker when the relevant msk socket is in an unexpected state: connect() // incoming reset + fastclose // the mptcp worker is scheduled mptcp_disconnect() // msk is now CLOSED listen() mptcp_worker() Leading to the following splat: divide error: 0000 [#1] PREEMPT SMP CPU: 1 PID: 21 Comm: kworker/1:0 Not tainted 6.3.0-rc1-gde5e8fd0123c #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__tcp_select_window+0x22c/0x4b0 net/ipv4/tcp_output.c:3018 RSP: 0018:ffffc900000b3c98 EFLAGS: 00010293 RAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8214ce97 RDI: 0000000000000004 RBP: 000000000000ffd7 R08: 0000000000000004 R09: 0000000000010000 R10: 000000000000ffd7 R11: ffff888005afa148 R12: 000000000000ffd7 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000405270 CR3: 000000003011e006 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tcp_select_window net/ipv4/tcp_output.c:262 [inline] __tcp_transmit_skb+0x356/0x1280 net/ipv4/tcp_output.c:1345 tcp_transmit_skb net/ipv4/tcp_output.c:1417 [inline] tcp_send_active_reset+0x13e/0x320 net/ipv4/tcp_output.c:3459 mptcp_check_fastclose net/mptcp/protocol.c:2530 [inline] mptcp_worker+0x6c7/0x800 net/mptcp/protocol.c:2705 process_one_work+0x3bd/0x950 kernel/workqueue.c:2390 worker_thread+0x5b/0x610 kernel/workqueue.c:2537 kthread+0x138/0x170 kernel/kthread.c:376 ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308 This change addresses the issue explicitly checking for bad states before running the mptcp worker. Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close") Cc: stable@vger.kernel.org Reported-by: Christoph Paasch Link: https://github.com/multipath-tcp/mptcp_net-next/issues/374 Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Tested-by: Christoph Paasch Signed-off-by: Matthieu Baerts Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1afbb34456062561672f7a6e999ca63e16a9ff6a Author: Paolo Abeni Date: Tue Apr 11 22:42:09 2023 +0200 mptcp: use mptcp_schedule_work instead of open-coding it commit a5cb752b125766524c921faab1a45cc96065b0a7 upstream. Beyond reducing code duplication this also avoids scheduling the mptcp_worker on a closed socket on some edge scenarios. The addressed issue is actually older than the blamed commit below, but this fix needs it as a pre-requisite. Fixes: ba8f48f7a4d7 ("mptcp: introduce mptcp_schedule_work") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a9ebb8ed5569fe85a30a795e967cf4595a503040 Author: Horatio Zhang Date: Thu Apr 6 13:32:14 2023 +0800 drm/amd/pm: correct SMU13.0.7 max shader clock reporting commit 85e0689eb6b10cd3b2fb455d1b3f4d4d0b13ff78 upstream. Correct the max shader clock reporting on SMU 13.0.7. Signed-off-by: Horatio Zhang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman commit 6007b9890ec88afe72a7a6e4ec24c923b745d305 Author: Horatio Zhang Date: Thu Apr 6 11:17:38 2023 +0800 drm/amd/pm: correct SMU13.0.7 pstate profiling clock settings commit f06b8887e3ef4f50098d3a949aef392c529c831a upstream. Correct the pstate standard/peak profiling mode clock settings for SMU13.0.7. Signed-off-by: Horatio Zhang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman commit 89c98802f0b754f3ee130480509f088be1daf81c Author: Waiman Long Date: Tue Apr 11 09:35:59 2023 -0400 cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork() methods commit eee87853794187f6adbe19533ed79c8b44b36a91 upstream. In the case of CLONE_INTO_CGROUP, not all cpusets are ready to accept new tasks. It is too late to check that in cpuset_fork(). So we need to add the cpuset_can_fork() and cpuset_cancel_fork() methods to pre-check it before we can allow attachment to a different cpuset. We also need to set the attach_in_progress flag to alert other code that a new task is going to be added to the cpuset. Fixes: ef2c41cf38a7 ("clone3: allow spawning processes into cgroups") Suggested-by: Michal Koutný Signed-off-by: Waiman Long Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 1eeb31c3ac1a79eae566c763bd21237bc5d39198 Author: Waiman Long Date: Tue Apr 11 09:35:58 2023 -0400 cgroup/cpuset: Make cpuset_fork() handle CLONE_INTO_CGROUP properly commit 42a11bf5c5436e91b040aeb04063be1710bb9f9c upstream. By default, the clone(2) syscall spawn a child process into the same cgroup as its parent. With the use of the CLONE_INTO_CGROUP flag introduced by commit ef2c41cf38a7 ("clone3: allow spawning processes into cgroups"), the child will be spawned into a different cgroup which is somewhat similar to writing the child's tid into "cgroup.threads". The current cpuset_fork() method does not properly handle the CLONE_INTO_CGROUP case where the cpuset of the child may be different from that of its parent. Update the cpuset_fork() method to treat the CLONE_INTO_CGROUP case similar to cpuset_attach(). Since the newly cloned task has not been running yet, its actual memory usage isn't known. So it is not necessary to make change to mm in cpuset_fork(). Fixes: ef2c41cf38a7 ("clone3: allow spawning processes into cgroups") Reported-by: Giuseppe Scrivano Signed-off-by: Waiman Long Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 6aa942500458a39afb02d10d20d2ed59349ab2a4 Author: Waiman Long Date: Tue Apr 11 09:35:57 2023 -0400 cgroup/cpuset: Wake up cpuset_attach_wq tasks in cpuset_cancel_attach() commit ba9182a89626d5f83c2ee4594f55cb9c1e60f0e2 upstream. After a successful cpuset_can_attach() call which increments the attach_in_progress flag, either cpuset_cancel_attach() or cpuset_attach() will be called later. In cpuset_attach(), tasks in cpuset_attach_wq, if present, will be woken up at the end. That is not the case in cpuset_cancel_attach(). So missed wakeup is possible if the attach operation is somehow cancelled. Fix that by doing the wakeup in cpuset_cancel_attach() as well. Fixes: e44193d39e8d ("cpuset: let hotplug propagation work wait for task attaching") Signed-off-by: Waiman Long Reviewed-by: Michal Koutný Cc: stable@vger.kernel.org # v3.11+ Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 37d82023df0464e46a73d92ce5dc6fdf09b9313d Author: Waiman Long Date: Fri Mar 17 11:15:05 2023 -0400 cgroup/cpuset: Fix partition root's cpuset.cpus update bug commit 292fd843de26c551856e66faf134512c52dd78b4 upstream. It was found that commit 7a2127e66a00 ("cpuset: Call set_cpus_allowed_ptr() with appropriate mask for task") introduced a bug that corrupted "cpuset.cpus" of a partition root when it was updated. It is because the tmp->new_cpus field of the passed tmp parameter of update_parent_subparts_cpumask() should not be used at all as it contains important cpumask data that should not be overwritten. Fix it by using tmp->addmask instead. Also update update_cpumask() to make sure that trialcs->cpu_allowed will not be corrupted until it is no longer needed. Fixes: 7a2127e66a00 ("cpuset: Call set_cpus_allowed_ptr() with appropriate mask for task") Signed-off-by: Waiman Long Cc: stable@vger.kernel.org # v6.2+ Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit daea92f089485d04e6a2fe35e2f89e4369232039 Author: Josh Don Date: Wed Mar 15 14:40:29 2023 -0700 cgroup: fix display of forceidle time at root commit fcdb1eda5302599045bb366e679cccb4216f3873 upstream. We need to reset forceidle_sum to 0 when reading from root, since the bstat we accumulate into is stack allocated. To make this more robust, just replace the existing cputime reset with a memset of the overall bstat. Signed-off-by: Josh Don Fixes: 1fcf54deb767 ("sched/core: add forced idle accounting for cgroups") Cc: stable@vger.kernel.org # v6.0+ Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 0fdbf3f618fe9c411dad36d0ba2132beb20a2a5e Author: Basavaraj Natikar Date: Wed Mar 29 22:58:59 2023 +0530 x86/PCI: Add quirk for AMD XHCI controller that loses MSI-X state in D3hot commit f195fc1e9715ba826c3b62d58038f760f66a4fe9 upstream. The AMD [1022:15b8] USB controller loses some internal functional MSI-X context when transitioning from D0 to D3hot. BIOS normally traps D0->D3hot and D3hot->D0 transitions so it can save and restore that internal context, but some firmware in the field can't do this because it fails to clear the AMD_15B8_RCC_DEV2_EPF0_STRAP2 NO_SOFT_RESET bit. Clear AMD_15B8_RCC_DEV2_EPF0_STRAP2 NO_SOFT_RESET bit before USB controller initialization during boot. Link: https://lore.kernel.org/linux-usb/Y%2Fz9GdHjPyF2rNG3@glanzmann.de/T/#u Link: https://lore.kernel.org/r/20230329172859.699743-1-Basavaraj.Natikar@amd.com Reported-by: Thomas Glanzmann Tested-by: Thomas Glanzmann Signed-off-by: Basavaraj Natikar Signed-off-by: Bjorn Helgaas Reviewed-by: Mario Limonciello Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 536ec28220832e84cb2c7c7b92dc14fa2381e01e Author: Reinette Chatre Date: Wed Mar 29 13:13:11 2023 -0700 PCI/MSI: Provide missing stub for pci_msix_can_alloc_dyn() commit 195d8e5da3acb17c5357526494f818a21e97cd10 upstream. pci_msix_can_alloc_dyn() is not declared when CONFIG_PCI_MSI is disabled. There is no existing user of pci_msix_can_alloc_dyn() but work is in progress to change this. This work encounters the following error when CONFIG_PCI_MSI is disabled: drivers/vfio/pci/vfio_pci_intrs.c:427:21: error: implicit declaration of function 'pci_msix_can_alloc_dyn' [-Werror=implicit-function-declaration] Provide definition for pci_msix_can_alloc_dyn() in preparation for users that need to compile when CONFIG_PCI_MSI is disabled. [bhelgaas: Also reported by Arnd Bergmann in drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c; added his Fixes: line] Fixes: fb0a6a268dcd ("net/mlx5: Provide external API for allocating vectors") Fixes: 34026364df8e ("PCI/MSI: Provide post-enable dynamic allocation interfaces for MSI-X") Link: https://lore.kernel.org/oe-kbuild-all/202303291000.PWFqGCxH-lkp@intel.com/ Link: https://lore.kernel.org/r/310ecc4815dae4174031062f525245f0755c70e2.1680119924.git.reinette.chatre@intel.com Reported-by: kernel test robot Signed-off-by: Reinette Chatre Signed-off-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan Cc: stable@vger.kernel.org # v6.2+ Signed-off-by: Greg Kroah-Hartman commit 07a75c0050e59c50f038cc5f4e2a3258c8f8c9d0 Author: Rob Herring Date: Wed Mar 29 07:38:35 2023 -0500 PCI: Fix use-after-free in pci_bus_release_domain_nr() commit 30ba2d09edb5ea857a1473ae3d820911347ada62 upstream. Commit c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()") introduced a use-after-free bug in the bus removal cleanup. The issue was found with kfence: [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70 [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-#115): [ 19.309677] pci_bus_release_domain_nr+0x10/0x70 [ 19.309691] dw_pcie_host_deinit+0x28/0x78 [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.309752] platform_probe+0x90/0xd8 ... [ 19.311457] kfence-#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s: [ 19.311562] __kmem_cache_alloc_node+0x260/0x278 [ 19.311571] kmalloc_trace+0x24/0x30 [ 19.311580] pci_alloc_bus+0x24/0xa0 [ 19.311590] pci_register_host_bridge+0x48/0x4b8 [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8 [ 19.311613] pci_host_probe+0x18/0xc0 [ 19.311623] dw_pcie_host_init+0x2c0/0x568 [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194] [ 19.311647] platform_probe+0x90/0xd8 ... [ 19.311782] freed by task 96 on cpu 10 at 19.285833s: [ 19.311799] release_pcibus_dev+0x30/0x40 [ 19.311808] device_release+0x30/0x90 [ 19.311814] kobject_put+0xa8/0x120 [ 19.311832] device_unregister+0x20/0x30 [ 19.311839] pci_remove_bus+0x78/0x88 [ 19.311850] pci_remove_root_bus+0x5c/0x98 [ 19.311860] dw_pcie_host_deinit+0x28/0x78 [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.311900] platform_probe+0x90/0xd8 ... [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4 [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022 [ 19.325852] Workqueue: events_unbound deferred_probe_work_func The stack trace is a bit misleading as dw_pcie_host_deinit() doesn't directly call pci_bus_release_domain_nr(). The issue turns out to be in pci_remove_root_bus() which first calls pci_remove_bus() which frees the struct pci_bus when its struct device is released. Then pci_bus_release_domain_nr() is called and accesses the freed struct pci_bus. Reordering these fixes the issue. Fixes: c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()") Link: https://lore.kernel.org/r/20230329123835.2724518-1-robh@kernel.org Link: https://lore.kernel.org/r/b529cb69-0602-9eed-fc02-2f068707a006@nvidia.com Reported-by: Jon Hunter Tested-by: Jon Hunter Signed-off-by: Rob Herring Signed-off-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan Cc: stable@vger.kernel.org # v6.2+ Cc: Pali Rohár Signed-off-by: Greg Kroah-Hartman commit 73e4995ea2719b1819c85c6c463246d7b34a4fa3 Author: Evan Quan Date: Fri Apr 7 17:12:15 2023 +0800 drm/amd/pm: correct the pcie link state check for SMU13 commit b9a24d8bd51e2db425602fa82d7f4c06aa3db852 upstream. Update the driver implementations to fit those data exposed by PMFW. Signed-off-by: Evan Quan Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman commit 0ed054d277b56e0b2d63557598eb1a7642488214 Author: Srinivas Pandruvada Date: Mon Apr 10 10:35:01 2023 -0700 thermal: intel: Avoid updating unsupported THERM_STATUS_CLEAR mask bits commit 117e4e5bd9d47b89777dbf6b37a709dcfe59520f upstream. Some older processors don't allow BIT(13) and BIT(15) in the current mask set by "THERM_STATUS_CLEAR_CORE_MASK". This results in: unchecked MSR access error: WRMSR to 0x19c (tried to write 0x000000000000aaa8) at rIP: 0xffffffff816f66a6 (throttle_active_work+0xa6/0x1d0) To avoid unchecked MSR issues, check CPUID for each relevant feature and use that information to set the supported feature bits only in the "clear" mask for cores. Do the same for the analogous package mask set by "THERM_STATUS_CLEAR_PKG_MASK". Introduce functions thermal_intr_init_core_clear_mask() and thermal_intr_init_pkg_clear_mask() to set core and package mask bits, respectively. These functions are called during initialization. Fixes: 6fe1e64b6026 ("thermal: intel: Prevent accidental clearing of HFI status") Reported-by: Rui Salvaterra Link: https://lore.kernel.org/lkml/cdf43fb423368ee3994124a9e8c9b4f8d00712c6.camel@linux.intel.com/T/ Tested-by: Rui Salvaterra Signed-off-by: Srinivas Pandruvada Cc: 6.2+ # 6.2+ [ rjw: Renamed 2 funtions and 2 static variables, edited subject and changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit eabc4872f172ecb8dd8536bc366a51868154a450 Author: Jiri Kosina Date: Tue Apr 4 21:23:42 2023 +0200 scsi: ses: Handle enclosure with just a primary component gracefully commit c8e22b7a1694bb8d025ea636816472739d859145 upstream. This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components") and introduces proper handling of case where there are no detected secondary components, but primary component (enumerated in num_enclosures) does exist. That fix was originally proposed by Ding Hui . Completely ignoring devices that have one primary enclosure and no secondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such even on valid configurations with 1 primary and 0 secondary enclosures as below: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1 The changelog for the original fix follows ===== We can get a crash when disconnecting the iSCSI session, the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98 In ses_intf_add, components count could be 0, and kcalloc 0 size scomp, but not saved in edev->component[i].scratch In this situation, edev->component[0].scratch is an invalid pointer, when kfree it in ses_intf_remove_enclosure, a crash like above would happen The call trace also could be other random cases when kfree cannot catch the invalid pointer We should not use edev->component[] array when the components count is 0 We also need check index when use edev->component[] array in ses_enclosure_data_process ===== Reported-by: Michal Kolar Originally-by: Ding Hui Cc: stable@vger.kernel.org Fixes: 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components") Signed-off-by: Jiri Kosina Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2304042122270.29760@cbobk.fhfr.pm Tested-by: Michal Kolar Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 281b194b488154e51ee569509bc47a62dcc6a63b Author: Radu Pirea (OSS) Date: Thu Apr 6 12:59:53 2023 +0300 net: phy: nxp-c45-tja11xx: fix unsigned long multiplication overflow commit bdaaecc127d471c422ee9e994978617c8aa79e1e upstream. Any multiplication between GENMASK(31, 0) and a number bigger than 1 will be truncated because of the overflow, if the size of unsigned long is 32 bits. Replaced GENMASK with GENMASK_ULL to make sure that multiplication will be between 64 bits values. Cc: # 5.15+ Fixes: 514def5dd339 ("phy: nxp-c45-tja11xx: add timestamping support") Signed-off-by: Radu Pirea (OSS) Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20230406095953.75622-1-radu-nicolae.pirea@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a614f988f48edd4939e0c9c65a10959159d93772 Author: Radu Pirea (OSS) Date: Thu Apr 6 12:59:04 2023 +0300 net: phy: nxp-c45-tja11xx: add remove callback commit a4506722dc39ca840593f14e3faa4c9ba9408211 upstream. Unregister PTP clock when the driver is removed. Purge the RX and TX skb queues. Fixes: 514def5dd339 ("phy: nxp-c45-tja11xx: add timestamping support") CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Radu Pirea (OSS) Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20230406095904.75456-1-radu-nicolae.pirea@oss.nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 837a5780580796a0d3868de99e0485b12d3c478a Author: Ivan Bornyakov Date: Thu Apr 6 16:08:32 2023 +0300 net: sfp: initialize sfp->i2c_block_size at sfp allocation commit 813c2dd78618f108fdcf9cd726ea90f081ee2881 upstream. sfp->i2c_block_size is initialized at SFP module insertion in sfp_sm_mod_probe(). Because of that, if SFP module was never inserted since boot, sfp_read() call will lead to zero-length I2C read attempt, and not all I2C controllers are happy with zero-length reads. One way to issue sfp_read() on empty SFP cage is to execute ethtool -m. If SFP module was never plugged since boot, there will be a zero-length I2C read attempt. # ethtool -m xge0 i2c i2c-3: adapter quirk: no zero length (addr 0x0050, size 0, read) Cannot get Module EEPROM data: Operation not supported If SFP module was plugged then removed at least once, sfp->i2c_block_size will be initialized and ethtool -m will fail with different exit code and without I2C error # ethtool -m xge0 Cannot get Module EEPROM data: Remote I/O error Fix this by initializing sfp->i2_block_size at struct sfp allocation stage so no wild sfp_read() could issue zero-length I2C read. Signed-off-by: Ivan Bornyakov Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Cc: stable@vger.kernel.org Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 45b9055a3a3ff6e8c08faad82ea36a8644a81587 Author: Tanu Malhotra Date: Mon Mar 27 11:58:38 2023 -0700 HID: intel-ish-hid: Fix kernel panic during warm reset commit 38518593ec55e897abda4b4be77b2ec8ec4447d1 upstream. During warm reset device->fw_client is set to NULL. If a bus driver is registered after this NULL setting and before new firmware clients are enumerated by ISHTP, kernel panic will result in the function ishtp_cl_bus_match(). This is because of reference to device->fw_client->props.protocol_name. ISH firmware after getting successfully loaded, sends a warm reset notification to remove all clients from the bus and sets device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel module drivers were loaded right after any of the first ISHTP device was registered, regardless of whether it was a matched or an unmatched device. This resulted in all drivers getting registered much before the warm reset notification from ISH. Starting kernel v5.16, this issue got exposed after the change was introduced to load only bus drivers for the respective matching devices. In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are registered after the warm reset device fw_client NULL setting. cros_ec_ishtp driver_register() triggers the callback to ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel panic in guid_equal() when dereferencing fw_client NULL pointer to get protocol_name. Fixes: f155dfeaa4ee ("platform/x86: isthp_eclite: only load for matching devices") Fixes: facfe0a4fdce ("platform/chrome: chros_ec_ishtp: only load for matching devices") Fixes: 0d0cccc0fd83 ("HID: intel-ish-hid: hid-client: only load for matching devices") Fixes: 44e2a58cb880 ("HID: intel-ish-hid: fw-loader: only load for matching devices") Cc: # 5.16+ Signed-off-by: Tanu Malhotra Tested-by: Shaunak Saha Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 5ab83ce0a0f95c612f3f6d81c1c7d725e938c4e2 Author: Mathis Salmen Date: Thu Apr 6 12:11:31 2023 +0200 riscv: add icache flush for nommu sigreturn trampoline commit 8d736482749f6d350892ef83a7a11d43cd49981e upstream. In a NOMMU kernel, sigreturn trampolines are generated on the user stack by setup_rt_frame. Currently, these trampolines are not instruction fenced, thus their visibility to ifetch is not guaranteed. This patch adds a flush_icache_range in setup_rt_frame to fix this problem. Signed-off-by: Mathis Salmen Fixes: 6bd33e1ece52 ("riscv: add nommu support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230406101130.82304-1-mathis.salmen@matsal.de Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit f02edb9debbd36f44efa7567031485892c7df60d Author: David Disseldorp Date: Thu Apr 13 23:49:57 2023 +0900 ksmbd: avoid out of bounds access in decode_preauth_ctxt() commit e7067a446264a7514fa1cfaa4052cdb6803bc6a2 upstream. Confirm that the accessed pneg_ctxt->HashAlgorithms address sits within the SMB request boundary; deassemble_neg_contexts() only checks that the eight byte smb2_neg_context header + (client controlled) DataLength are within the packet boundary, which is insufficient. Checking for sizeof(struct smb2_preauth_neg_context) is overkill given that the type currently assumes SMB311_SALT_SIZE bytes of trailing Salt. Signed-off-by: David Disseldorp Acked-by: Namjae Jeon Cc: Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2780b421b8da4b2032b0769636851d608ac72125 Author: Liam R. Howlett Date: Mon Feb 27 09:36:04 2023 -0800 maple_tree: fix write memory barrier of nodes once dead for RCU mode [ Upstream commit c13af03de46ba27674dd9fb31a17c0d480081139 ] During the development of the maple tree, the strategy of freeing multiple nodes changed and, in the process, the pivots were reused to store pointers to dead nodes. To ensure the readers see accurate pivots, the writers need to mark the nodes as dead and call smp_wmb() to ensure any readers can identify the node as dead before using the pivot values. There were two places where the old method of marking the node as dead without smp_wmb() were being used, which resulted in RCU readers seeing the wrong pivot value before seeing the node was dead. Fix this race condition by using mte_set_node_dead() which has the smp_wmb() call to ensure the race is closed. Add a WARN_ON() to the ma_free_rcu() call to ensure all nodes being freed are marked as dead to ensure there are no other call paths besides the two updated paths. This is necessary for the RCU mode of the maple tree. Link: https://lkml.kernel.org/r/20230227173632.3292573-6-surenb@google.com Fixes: 54a611b60590 ("Maple Tree: add new data structure") Signed-off-by: Liam R. Howlett Signed-off-by: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 75f95216cfadb0fb6796b90cf42b9ea076fa0723 Author: Steven Rostedt (Google) Date: Tue Apr 4 22:21:14 2023 -0400 tracing: Have tracing_snapshot_instance_cond() write errors to the appropriate instance [ Upstream commit 9d52727f8043cfda241ae96896628d92fa9c50bb ] If a trace instance has a failure with its snapshot code, the error message is to be written to that instance's buffer. But currently, the message is written to the top level buffer. Worse yet, it may also disable the top level buffer and not the instance that had the issue. Link: https://lkml.kernel.org/r/20230405022341.688730321@goodmis.org Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Andrew Morton Cc: Ross Zwisler Fixes: 2824f50332486 ("tracing: Make the snapshot trigger work with instances") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit c55902442e9f65a21d7636ff00939349e42f9fe7 Author: Steven Rostedt (Google) Date: Tue Feb 7 12:28:52 2023 -0500 tracing: Add trace_array_puts() to write into instance [ Upstream commit d503b8f7474fe7ac616518f7fc49773cbab49f36 ] Add a generic trace_array_puts() that can be used to "trace_puts()" into an allocated trace_array instance. This is just another variant of trace_array_printk(). Link: https://lkml.kernel.org/r/20230207173026.584717290@goodmis.org Cc: Masami Hiramatsu Cc: Andrew Morton Reviewed-by: Ross Zwisler Signed-off-by: Steven Rostedt (Google) Stable-dep-of: 9d52727f8043 ("tracing: Have tracing_snapshot_instance_cond() write errors to the appropriate instance") Signed-off-by: Sasha Levin commit d9bef87b35f9ee964a7cd5439f3a6be28343d882 Author: Aymeric Wibo Date: Sun Mar 19 03:12:05 2023 +0100 ACPI: resource: Add Medion S17413 to IRQ override quirk [ Upstream commit 2d0ab14634a26e54f8d6d231b47b7ef233e84599 ] Add DMI info of the Medion S17413 (board M1xA) to the IRQ override quirk table. This fixes the keyboard not working on these laptops. Link: https://bugzilla.kernel.org/show_bug.cgi?id=213031 Signed-off-by: Aymeric Wibo [ rjw: Fixed up white space ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b934a3752fbcc7c7791e504f9d8df787b37678e6 Author: Jane Jian Date: Wed Mar 15 18:59:59 2023 +0800 drm/amdgpu/gfx: set cg flags to enter/exit safe mode [ Upstream commit e06bfcc1a1c41bcb8c31470d437e147ce9f0acfd ] sriov needs to enter/exit safe mode in update umd p state add the cg flag to let it enter or exit while needed Signed-off-by: Jane Jian Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d711999534c40d9d7501cf4d9a94d6256e521d37 Author: YuBiao Wang Date: Thu Mar 16 11:30:32 2023 +0800 drm/amdgpu: Force signal hw_fences that are embedded in non-sched jobs [ Upstream commit 033c56474acf567a450f8bafca50e0b610f2b716 ] [Why] For engines not supporting soft reset, i.e. VCN, there will be a failed ib test before mode 1 reset during asic reset. The fences in this case are never signaled and next time when we try to free the sa_bo, kernel will hang. [How] During pre_asic_reset, driver will clear job fences and afterwards the fences' refcount will be reduced to 1. For drm_sched_jobs it will be released in job_free_cb, and for non-sched jobs like ib_test, it's meant to be released in sa_bo_free but only when the fences are signaled. So we have to force signal the non_sched bad job's fence during pre_asic_reset or the clear is not complete. Signed-off-by: YuBiao Wang Acked-by: Luben Tuikov Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3283aaa2f16960c707141f27d80827842f933fe4 Author: Tong Liu01 Date: Wed Mar 15 15:24:22 2023 +0800 drm/amdgpu: add mes resume when do gfx post soft reset [ Upstream commit 4eb0b49a0ad3e004a6a65b84efe37bc7e66d560f ] [why] when gfx do soft reset, mes will also do reset, if mes is not resumed when do recover from soft reset, mes is unable to respond in later sequence [how] resume mes when do gfx post soft reset Signed-off-by: Tong Liu01 Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7b887692194d9f20695a11be44565aaefd4a9ca3 Author: Johannes Berg Date: Fri Mar 17 10:53:25 2023 +0100 wifi: iwlwifi: mvm: protect TXQ list manipulation [ Upstream commit 923bf981eb6ecc027227716e30701bdcc1845fbf ] Some recent upstream debugging uncovered the fact that in iwlwifi, the TXQ list manipulation is racy. Introduce a new state bit for when the TXQ is completely ready and can be used without locking, and if that's not set yet acquire the lock to check everything correctly. Reviewed-by: Benjamin Berg Tested-by: Jose Ignacio Tornos Martinez Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1ce198c6d2b65f94b7ea605c660db3a363771c45 Author: Johannes Berg Date: Fri Mar 17 10:53:24 2023 +0100 wifi: iwlwifi: mvm: fix mvmtxq->stopped handling [ Upstream commit b58e3d4311b54b6dd0e37165277965da0c9eb21d ] This could race if the queue is redirected while full, then the flushing internally would start it while it's not yet usable again. Fix it by using two state bits instead of just one. Reviewed-by: Benjamin Berg Tested-by: Jose Ignacio Tornos Martinez Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit df7f6ad627e74d4ef183039d0b4ca36d40123bb3 Author: Martin George Date: Thu Mar 16 17:20:09 2023 +0530 nvme: send Identify with CNS 06h only to I/O controllers [ Upstream commit def84ab600b71ea3fcc422a876d5d0d0daa7d4f3 ] Identify CNS 06h (I/O Command Set Specific Identify Controller data structure) is supported only on i/o controllers. But nvme_init_non_mdts_limits() currently invokes this on all controllers. Correct this by ensuring this is sent to I/O controllers only. Signed-off-by: Martin George Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit eafbf572be0bad7dc863e7b97eff10dd32227637 Author: Robbie Harwood Date: Mon Feb 20 12:12:54 2023 -0500 asymmetric_keys: log on fatal failures in PE/pkcs7 [ Upstream commit 3584c1dbfffdabf8e3dc1dd25748bb38dd01cd43 ] These particular errors can be encountered while trying to kexec when secureboot lockdown is in place. Without this change, even with a signed debug build, one still needs to reboot the machine to add the appropriate dyndbg parameters (since lockdown blocks debugfs). Accordingly, upgrade all pr_debug() before fatal error into pr_warn(). Signed-off-by: Robbie Harwood Signed-off-by: David Howells cc: Jarkko Sakkinen cc: Eric Biederman cc: Herbert Xu cc: keyrings@vger.kernel.org cc: linux-crypto@vger.kernel.org cc: kexec@lists.infradead.org Link: https://lore.kernel.org/r/20230220171254.592347-3-rharwood@redhat.com/ # v2 Signed-off-by: Sasha Levin commit fb4cb0b3898eefed656903da14815e697ac1e819 Author: Robbie Harwood Date: Mon Feb 20 12:12:53 2023 -0500 verify_pefile: relax wrapper length check [ Upstream commit 4fc5c74dde69a7eda172514aaeb5a7df3600adb3 ] The PE Format Specification (section "The Attribute Certificate Table (Image Only)") states that `dwLength` is to be rounded up to 8-byte alignment when used for traversal. Therefore, the field is not required to be an 8-byte multiple in the first place. Accordingly, pesign has not performed this alignment since version 0.110. This causes kexec failure on pesign'd binaries with "PEFILE: Signature wrapper len wrong". Update the comment and relax the check. Signed-off-by: Robbie Harwood Signed-off-by: David Howells cc: Jarkko Sakkinen cc: Eric Biederman cc: Herbert Xu cc: keyrings@vger.kernel.org cc: linux-crypto@vger.kernel.org cc: kexec@lists.infradead.org Link: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-attribute-certificate-table-image-only Link: https://github.com/rhboot/pesign Link: https://lore.kernel.org/r/20230220171254.592347-2-rharwood@redhat.com/ # v2 Signed-off-by: Sasha Levin commit 1773185a0a87006c1be78a978d9dd61aa7a33db8 Author: Tianyi Jing Date: Sat Mar 18 22:38:51 2023 +0800 hwmon: (xgene) Fix ioremap and memremap leak [ Upstream commit 813cc94c7847ae4a17e9f744fb4dbdf7df6bd732 ] Smatch reports: drivers/hwmon/xgene-hwmon.c:757 xgene_hwmon_probe() warn: 'ctx->pcc_comm_addr' from ioremap() not released on line: 757. This is because in drivers/hwmon/xgene-hwmon.c:701 xgene_hwmon_probe(), ioremap and memremap is not released, which may cause a leak. To fix this, ioremap and memremap is modified to devm_ioremap and devm_memremap. Signed-off-by: Tianyi Jing Reviewed-by: Dongliang Mu Link: https://lore.kernel.org/r/20230318143851.2191625-1-jingfelix@hust.edu.cn [groeck: Fixed formatting and subject] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 1a5054535d7b67fc2e397645ba97cd1b9364d467 Author: Iwona Winiarska Date: Tue Mar 21 10:04:10 2023 +0100 hwmon: (peci/cputemp) Fix miscalculated DTS for SKX [ Upstream commit 2b91c4a870c9830eaf95e744454c9c218cccb736 ] For Skylake, DTS temperature of the CPU is reported in S10.6 format instead of S8.8. Reported-by: Paul Fertser Link: https://lore.kernel.org/lkml/ZBhHS7v+98NK56is@home.paul.comp/ Signed-off-by: Iwona Winiarska Link: https://lore.kernel.org/r/20230321090410.866766-1-iwona.winiarska@intel.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 412343a15f75092c017d2e853733ca251efadefb Author: Hans de Goede Date: Wed Mar 1 10:52:18 2023 +0100 drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Book X90F [ Upstream commit 03aecb1acbcd7a660f97d645ca6c09d9de27ff9d ] Like the Windows Lenovo Yoga Book X91F/L the Android Lenovo Yoga Book X90F/L has a portrait 1200x1920 screen used in landscape mode, add a quirk for this. When the quirk for the X91F/L was initially added it was written to also apply to the X90F/L but this does not work because the Android version of the Yoga Book uses completely different DMI strings. Also adjust the X91F/L quirk to reflect that it only applies to the X91F/L models. Signed-off-by: Hans de Goede Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230301095218.28457-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit c3ffa6723766c87c1a8b87bc61eee89245341892 Author: Hans de Goede Date: Mon Mar 20 16:59:46 2023 +0100 ACPI: video: Add backlight=native DMI quirk for Acer Aspire 3830TG [ Upstream commit 5e7a3bf65db57461d0f47955248fcadf37321a74 ] The Acer Aspire 3830TG predates Windows 8, so it defaults to using acpi_video# for backlight control, but this is non functional on this model. Add a DMI quirk to use the native backlight interface which does work properly. Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 184cfeeb8e881220e0f18cacbb006bde53e050c2 Author: Ming Lei Date: Sat Mar 18 22:12:31 2023 +0800 block: ublk_drv: mark device as LIVE before adding disk [ Upstream commit 4985e7b2c002eb4c5c794a1d3acd91b82c89a0fd ] IO can be started before add_disk() returns, such as reading parititon table, then the monitor work should work for making forward progress. So mark device as LIVE before adding disk, meantime change to DEAD if add_disk() fails. Fixed: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Reviewed-by: Ziyang Zhang Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20230318141231.55562-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2b716dc52bf022e43c5ecb257c7c0edeb72d3ed9 Author: Hans de Goede Date: Tue Mar 14 13:31:03 2023 +0100 efi: sysfb_efi: Add quirk for Lenovo Yoga Book X91F/L [ Upstream commit 5ed213dd64681f84a01ceaa82fb336cf7d59ddcf ] Another Lenovo convertable which reports a landscape resolution of 1920x1200 with a pitch of (1920 * 4) bytes, while the actual framebuffer has a resolution of 1200x1920 with a pitch of (1200 * 4) bytes. Signed-off-by: Hans de Goede Reviewed-by: Javier Martinez Canillas Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit b025e0fd487ae9accd44113334b8ae077ef791bb Author: Yicong Yang Date: Mon Mar 13 15:45:51 2023 +0800 i2c: hisi: Avoid redundant interrupts [ Upstream commit cc9812a3096d1986caca9a23bee99effc45c08df ] After issuing all the messages we can disable the TX_EMPTY interrupts to avoid handling redundant interrupts. For doing a sinlge bus detection (i2cdetect -y -r 0) we can reduce ~97% interrupts (before ~12000 after ~400). Signed-off-by: Sheng Feng Signed-off-by: Yicong Yang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit b2fcd6923a3345f74156cba73806e304d35bea41 Author: Alexander Stein Date: Mon Jan 30 16:32:46 2023 +0100 i2c: imx-lpi2c: clean rx/tx buffers upon new message [ Upstream commit 987dd36c0141f6ab9f0fbf14d6b2ec3342dedb2f ] When start sending a new message clear the Rx & Tx buffer pointers in order to avoid using stale pointers. Signed-off-by: Alexander Stein Tested-by: Emanuele Ghidoli Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 6e80b541d9682192c92630f7bd6424fec828070d Author: Krzysztof Kozlowski Date: Sun Mar 12 14:25:23 2023 +0100 wifi: mwifiex: mark OF related data as maybe unused [ Upstream commit 139f6973bf140c65d4d1d4bde5485badb4454d7a ] The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/net/wireless/marvell/mwifiex/sdio.c:498:34: error: ‘mwifiex_sdio_of_match_table’ defined but not used [-Werror=unused-const-variable=] drivers/net/wireless/marvell/mwifiex/pcie.c:175:34: error: ‘mwifiex_pcie_of_match_table’ defined but not used [-Werror=unused-const-variable=] Signed-off-by: Krzysztof Kozlowski Reviewed-by: Simon Horman Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230312132523.352182-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit bb484ba17bf9db34ea4f5a3c2157865b45c258f9 Author: Alexei Starovoitov Date: Fri Mar 10 12:41:18 2023 -0800 selftests/bpf: Fix progs/find_vma_fail1.c build error. [ Upstream commit 32513d40d908b267508d37994753d9bd1600914b ] The commit 11e456cae91e ("selftests/bpf: Fix compilation errors: Assign a value to a constant") fixed the issue cleanly in bpf-next. This is an alternative fix in bpf tree to avoid merge conflict between bpf and bpf-next. Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1dfda8e24c52b6d2a54b50b35af0cda0dca55081 Author: Denis Arefev Date: Tue Dec 6 12:17:23 2022 +0300 power: supply: axp288_fuel_gauge: Added check for negative values [ Upstream commit bf6c880d5d1448489ebf92e2d13d5713ff644930 ] Variable 'pirq', which may receive negative value in platform_get_irq(). Used as an index in a function regmap_irq_get_virq(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Denis Arefev Reviewed-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 339638dccde5f524ede19d956e292e47f856aa27 Author: Grant Grundler Date: Mon Dec 12 13:38:57 2022 -0800 power: supply: cros_usbpd: reclassify "default case!" as debug [ Upstream commit 14c76b2e75bca4d96e2b85a0c12aa43e84fe3f74 ] This doesn't need to be printed every second as an error: ... <3>[17438.628385] cros-usbpd-charger cros-usbpd-charger.3.auto: Port 1: default case! <3>[17439.634176] cros-usbpd-charger cros-usbpd-charger.3.auto: Port 1: default case! <3>[17440.640298] cros-usbpd-charger cros-usbpd-charger.3.auto: Port 1: default case! ... Reduce priority from ERROR to DEBUG. Signed-off-by: Grant Grundler Reviewed-by: Guenter Roeck Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c453cc38d1ef81c624babe5ff1565f1f0963fd9a Author: Jiapeng Chong Date: Wed Dec 14 11:23:16 2022 +0800 power: supply: rk817: Fix unsigned comparison with less than zero [ Upstream commit 3268a4d9b0b85a4382e93bdf7be5400a73db74c5 ] The tmp is defined as u32 type, which results in invalid processing of tmp<0 in function rk817_read_or_set_full_charge_on_boot(). Therefore, drop the comparison. drivers/power/supply/rk817_charger.c:828 rk817_read_or_set_full_charge_on_boot() warn: unsigned 'tmp' is never less than zero. drivers/power/supply/rk817_charger.c:788 rk817_read_or_set_full_charge_on_boot() warn: unsigned 'tmp' is never less than zero. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3444 Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Tested-by: Chris Morgan Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit f3c18eee53694994b1811d8ddc1559cbe753c49d Author: Brian Masney Date: Tue Mar 7 18:23:40 2023 -0500 arm64: dts: qcom: sa8540p-ride: correct name of remoteproc_nsp0 firmware [ Upstream commit b891251b40d4dc4cfd28341f62f6784c02ad3a78 ] The cdsp.mbn firmware that's referenced in sa8540p-ride.dts is actually named cdsp0.mbn in the deliverables from Qualcomm. Let's go ahead and correct the name to match what's in Qualcomm's deliverable. Signed-off-by: Brian Masney Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20230307232340.2370476-1-bmasney@redhat.com Signed-off-by: Sasha Levin commit fc6e7d364cc37b677c8e4477ce2c1e2a3005ec92 Author: Luca Weiss Date: Wed Mar 8 22:06:03 2023 +0100 ARM: dts: qcom: apq8026-lg-lenok: add missing reserved memory [ Upstream commit ecd240875e877d78fd03efbc62292f550872df3f ] Turns out these two memory regions also need to be avoided, otherwise weird things will happen when Linux tries to use this memory. Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20230308-lenok-reserved-memory-v1-1-b8bf6ff01207@z3ntu.xyz Signed-off-by: Sasha Levin commit fe9c782f2852a4cb8c879e1c08f3d7f7901beba2 Author: Andrew Jeffery Date: Wed Feb 22 00:10:14 2023 +0100 ARM: 9290/1: uaccess: Fix KASAN false-positives [ Upstream commit ceac10c83b330680cc01ceaaab86cd49f4f30d81 ] __copy_to_user_memcpy() and __clear_user_memset() had been calling memcpy() and memset() respectively, leading to false-positive KASAN reports when starting userspace: [ 10.707901] Run /init as init process [ 10.731892] process '/bin/busybox' started with executable stack [ 10.745234] ================================================================== [ 10.745796] BUG: KASAN: user-memory-access in __clear_user_memset+0x258/0x3ac [ 10.747260] Write of size 2687 at addr 000de581 by task init/1 Use __memcpy() and __memset() instead to allow userspace access, which is of course the intent of these functions. Signed-off-by: Andrew Jeffery Signed-off-by: Zev Weiss Reviewed-by: Arnd Bergmann Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 5f692c992a3bb9a8018e3488098b401a4229e7ec Author: Liang Chen Date: Thu Apr 13 17:03:53 2023 +0800 skbuff: Fix a race between coalescing and releasing SKBs [ Upstream commit 0646dc31ca886693274df5749cd0c8c1eaaeb5ca ] Commit 1effe8ca4e34 ("skbuff: fix coalescing for page_pool fragment recycling") allowed coalescing to proceed with non page pool page and page pool page when @from is cloned, i.e. to->pp_recycle --> false from->pp_recycle --> true skb_cloned(from) --> true However, it actually requires skb_cloned(@from) to hold true until coalescing finishes in this situation. If the other cloned SKB is released while the merging is in process, from_shinfo->nr_frags will be set to 0 toward the end of the function, causing the increment of frag page _refcount to be unexpectedly skipped resulting in inconsistent reference counts. Later when SKB(@to) is released, it frees the page directly even though the page pool page is still in use, leading to use-after-free or double-free errors. So it should be prohibited. The double-free error message below prompted us to investigate: BUG: Bad page state in process swapper/1 pfn:0e0d1 page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000 index:0x2 pfn:0xe0d1 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000 raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000 page dumped because: nonzero _refcount CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+ Call Trace: dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_pcp_prepare+0x260/0x2f0 free_unref_page+0x20/0x1c0 skb_release_data+0x10b/0x1a0 napi_consume_skb+0x56/0x150 net_rx_action+0xf0/0x350 ? __napi_schedule+0x79/0x90 __do_softirq+0xc8/0x2b1 __irq_exit_rcu+0xb9/0xf0 common_interrupt+0x82/0xa0 asm_common_interrupt+0x22/0x40 RIP: 0010:default_idle+0xb/0x20 Fixes: 53e0961da1c7 ("page_pool: add frag page recycling support in page pool") Signed-off-by: Liang Chen Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20230413090353.14448-1-liangchen.linux@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5dcf3a6843d0d7cc76960fbe8511d425f217744c Author: Roman Gushchin Date: Wed Apr 12 16:21:44 2023 -0700 net: macb: fix a memory corruption in extended buffer descriptor mode [ Upstream commit e8b74453555872851bdd7ea43a7c0ec39659834f ] For quite some time we were chasing a bug which looked like a sudden permanent failure of networking and mmc on some of our devices. The bug was very sensitive to any software changes and even more to any kernel debug options. Finally we got a setup where the problem was reproducible with CONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma: [ 16.992082] ------------[ cut here ]------------ [ 16.996779] DMA-API: macb ff0b0000.ethernet: device driver tries to free DMA memory it has not allocated [device address=0x0000000875e3e244] [size=1536 bytes] [ 17.011049] WARNING: CPU: 0 PID: 85 at kernel/dma/debug.c:1011 check_unmap+0x6a0/0x900 [ 17.018977] Modules linked in: xxxxx [ 17.038823] CPU: 0 PID: 85 Comm: irq/55-8000f000 Not tainted 5.4.0 #28 [ 17.045345] Hardware name: xxxxx [ 17.049528] pstate: 60000005 (nZCv daif -PAN -UAO) [ 17.054322] pc : check_unmap+0x6a0/0x900 [ 17.058243] lr : check_unmap+0x6a0/0x900 [ 17.062163] sp : ffffffc010003c40 [ 17.065470] x29: ffffffc010003c40 x28: 000000004000c03c [ 17.070783] x27: ffffffc010da7048 x26: ffffff8878e38800 [ 17.076095] x25: ffffff8879d22810 x24: ffffffc010003cc8 [ 17.081407] x23: 0000000000000000 x22: ffffffc010a08750 [ 17.086719] x21: ffffff8878e3c7c0 x20: ffffffc010acb000 [ 17.092032] x19: 0000000875e3e244 x18: 0000000000000010 [ 17.097343] x17: 0000000000000000 x16: 0000000000000000 [ 17.102647] x15: ffffff8879e4a988 x14: 0720072007200720 [ 17.107959] x13: 0720072007200720 x12: 0720072007200720 [ 17.113261] x11: 0720072007200720 x10: 0720072007200720 [ 17.118565] x9 : 0720072007200720 x8 : 000000000000022d [ 17.123869] x7 : 0000000000000015 x6 : 0000000000000098 [ 17.129173] x5 : 0000000000000000 x4 : 0000000000000000 [ 17.134475] x3 : 00000000ffffffff x2 : ffffffc010a1d370 [ 17.139778] x1 : b420c9d75d27bb00 x0 : 0000000000000000 [ 17.145082] Call trace: [ 17.147524] check_unmap+0x6a0/0x900 [ 17.151091] debug_dma_unmap_page+0x88/0x90 [ 17.155266] gem_rx+0x114/0x2f0 [ 17.158396] macb_poll+0x58/0x100 [ 17.161705] net_rx_action+0x118/0x400 [ 17.165445] __do_softirq+0x138/0x36c [ 17.169100] irq_exit+0x98/0xc0 [ 17.172234] __handle_domain_irq+0x64/0xc0 [ 17.176320] gic_handle_irq+0x5c/0xc0 [ 17.179974] el1_irq+0xb8/0x140 [ 17.183109] xiic_process+0x5c/0xe30 [ 17.186677] irq_thread_fn+0x28/0x90 [ 17.190244] irq_thread+0x208/0x2a0 [ 17.193724] kthread+0x130/0x140 [ 17.196945] ret_from_fork+0x10/0x20 [ 17.200510] ---[ end trace 7240980785f81d6f ]--- [ 237.021490] ------------[ cut here ]------------ [ 237.026129] DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000021d79e7b [ 237.033886] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:499 add_dma_entry+0x214/0x240 [ 237.041802] Modules linked in: xxxxx [ 237.061637] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.4.0 #28 [ 237.068941] Hardware name: xxxxx [ 237.073116] pstate: 80000085 (Nzcv daIf -PAN -UAO) [ 237.077900] pc : add_dma_entry+0x214/0x240 [ 237.081986] lr : add_dma_entry+0x214/0x240 [ 237.086072] sp : ffffffc010003c30 [ 237.089379] x29: ffffffc010003c30 x28: ffffff8878a0be00 [ 237.094683] x27: 0000000000000180 x26: ffffff8878e387c0 [ 237.099987] x25: 0000000000000002 x24: 0000000000000000 [ 237.105290] x23: 000000000000003b x22: ffffffc010a0fa00 [ 237.110594] x21: 0000000021d79e7b x20: ffffffc010abe600 [ 237.115897] x19: 00000000ffffffef x18: 0000000000000010 [ 237.121201] x17: 0000000000000000 x16: 0000000000000000 [ 237.126504] x15: ffffffc010a0fdc8 x14: 0720072007200720 [ 237.131807] x13: 0720072007200720 x12: 0720072007200720 [ 237.137111] x11: 0720072007200720 x10: 0720072007200720 [ 237.142415] x9 : 0720072007200720 x8 : 0000000000000259 [ 237.147718] x7 : 0000000000000001 x6 : 0000000000000000 [ 237.153022] x5 : ffffffc010003a20 x4 : 0000000000000001 [ 237.158325] x3 : 0000000000000006 x2 : 0000000000000007 [ 237.163628] x1 : 8ac721b3a7dc1c00 x0 : 0000000000000000 [ 237.168932] Call trace: [ 237.171373] add_dma_entry+0x214/0x240 [ 237.175115] debug_dma_map_page+0xf8/0x120 [ 237.179203] gem_rx_refill+0x190/0x280 [ 237.182942] gem_rx+0x224/0x2f0 [ 237.186075] macb_poll+0x58/0x100 [ 237.189384] net_rx_action+0x118/0x400 [ 237.193125] __do_softirq+0x138/0x36c [ 237.196780] irq_exit+0x98/0xc0 [ 237.199914] __handle_domain_irq+0x64/0xc0 [ 237.204000] gic_handle_irq+0x5c/0xc0 [ 237.207654] el1_irq+0xb8/0x140 [ 237.210789] arch_cpu_idle+0x40/0x200 [ 237.214444] default_idle_call+0x18/0x30 [ 237.218359] do_idle+0x200/0x280 [ 237.221578] cpu_startup_entry+0x20/0x30 [ 237.225493] rest_init+0xe4/0xf0 [ 237.228713] arch_call_rest_init+0xc/0x14 [ 237.232714] start_kernel+0x47c/0x4a8 [ 237.236367] ---[ end trace 7240980785f81d70 ]--- Lars was fast to find an explanation: according to the datasheet bit 2 of the rx buffer descriptor entry has a different meaning in the extended mode: Address [2] of beginning of buffer, or in extended buffer descriptor mode (DMA configuration register [28] = 1), indicates a valid timestamp in the buffer descriptor entry. The macb driver didn't mask this bit while getting an address and it eventually caused a memory corruption and a dma failure. The problem is resolved by explicitly clearing the problematic bit if hw timestamping is used. Fixes: 7b4296148066 ("net: macb: Add support for PTP timestamps in DMA descriptors") Signed-off-by: Roman Gushchin Co-developed-by: Lars-Peter Clausen Signed-off-by: Lars-Peter Clausen Acked-by: Nicolas Ferre Reviewed-by: Jacob Keller Link: https://lore.kernel.org/r/20230412232144.770336-1-roman.gushchin@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1ac56e2d45af612f89c36508536b5aa3692c3592 Author: Xin Long Date: Wed Apr 12 11:13:06 2023 -0400 selftests: add the missing CONFIG_IP_SCTP in net config [ Upstream commit 3a0385be133e7091cc9a9a998c7ec712bb9585db ] The selftest sctp_vrf needs CONFIG_IP_SCTP set in config when building the kernel, so add it. Fixes: a61bd7b9fef3 ("selftests: add a selftest for sctp vrf") Reported-by: Naresh Kamboju Signed-off-by: Xin Long Reviewed-by: Sridhar Samudrala Link: https://lore.kernel.org/r/61dddebc4d2dd98fe7fb145e24d4b2430e42b572.1681312386.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d4588ac7f498a6b1e2cf9e30106b8a92a7c6a002 Author: Eric Dumazet Date: Wed Apr 12 13:03:08 2023 +0000 udp6: fix potential access to stale information [ Upstream commit 1c5950fc6fe996235f1d18539b9c6b64b597f50f ] lena wang reported an issue caused by udpv6_sendmsg() mangling msg->msg_name and msg->msg_namelen, which are later read from ____sys_sendmsg() : /* * If this is sendmmsg() and sending to current destination address was * successful, remember it. */ if (used_address && err >= 0) { used_address->name_len = msg_sys->msg_namelen; if (msg_sys->msg_name) memcpy(&used_address->name, msg_sys->msg_name, used_address->name_len); } udpv6_sendmsg() wants to pretend the remote address family is AF_INET in order to call udp_sendmsg(). A fix would be to modify the address in-place, instead of using a local variable, but this could have other side effects. Instead, restore initial values before we return from udpv6_sendmsg(). Fixes: c71d8ebe7a44 ("net: Fix security_socket_sendmsg() bypass problem.") Reported-by: lena wang Signed-off-by: Eric Dumazet Reviewed-by: Maciej Żenczykowski Link: https://lore.kernel.org/r/20230412130308.1202254-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 506c9d946a12e3e19a1de2a813c6e6c57acbae57 Author: Aaron Conole Date: Wed Apr 12 07:58:28 2023 -0400 selftests: openvswitch: adjust datapath NL message declaration [ Upstream commit 306dc21361993f4fe50a15d4db6b1a4de5d0adb0 ] The netlink message for creating a new datapath takes an array of ports for the PID creation. This shouldn't cause much issue but correct it for future cases where we need to do decode of datapath information that could include the per-cpu PID map. Fixes: 25f16c873fb1 ("selftests: add openvswitch selftest suite") Signed-off-by: Aaron Conole Link: https://lore.kernel.org/r/20230412115828.3991806-1-aconole@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 632d6baf8884d803e598bf5164008d23fd9b736c Author: Saravanan Vajravel Date: Fri Mar 31 23:34:24 2023 -0700 RDMA/core: Fix GID entry ref leak when create_ah fails [ Upstream commit aca3b0fa3d04b40c96934d86cc224cccfa7ea8e0 ] If AH create request fails, release sgid_attr to avoid GID entry referrence leak reported while releasing GID table Fixes: 1a1f460ff151 ("RDMA: Hold the sgid_attr inside the struct ib_ah/qp") Link: https://lore.kernel.org/r/20230401063424.342204-1-saravanan.vajravel@broadcom.com Reviewed-by: Selvin Xavier Signed-off-by: Saravanan Vajravel Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ad988e9b5ff04607e624a459209e8c2d0c15fc73 Author: Xin Long Date: Mon Apr 10 15:43:30 2023 -0400 sctp: fix a potential overflow in sctp_ifwdtsn_skip [ Upstream commit 32832a2caf82663870126c5186cf8f86c8b2a649 ] Currently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it only checks the pos against the end of the chunk. However, the data left for the last pos may be < sizeof(struct sctp_ifwdtsn_skip), and dereference it as struct sctp_ifwdtsn_skip may cause coverflow. This patch fixes it by checking the pos against "the end of the chunk - sizeof(struct sctp_ifwdtsn_skip)" in sctp_ifwdtsn_skip, similar to sctp_fwdtsn_skip. Fixes: 0fc2ea922c8a ("sctp: implement validate_ftsn for sctp_stream_interleave") Signed-off-by: Xin Long Link: https://lore.kernel.org/r/2a71bffcd80b4f2c61fac6d344bb2f11c8fd74f7.1681155810.git.lucien.xin@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8c9ce34a6ff2c544f96ce0b088e8fd3c1b9698c4 Author: Ziyang Xuan Date: Mon Apr 10 09:23:52 2023 +0800 net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume() [ Upstream commit 6417070918de3bcdbe0646e7256dae58fd8083ba ] Syzbot reported a bug as following: ===================================================== BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630 qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd It is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt) in qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post(). But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot scenario. This triggers the uninit variable access bug. Add size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() to fix the bug. Fixes: 5fdeb0d372ab ("net: qrtr: Implement outgoing flow control") Reported-by: syzbot+4436c9630a45820fda76@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=c14607f0963d27d5a3d5f4c8639b500909e43540 Suggested-by: Manivannan Sadhasivam Signed-off-by: Ziyang Xuan Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20230410012352.3997823-1-william.xuanziyang@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ea63dd60823c227d3498f50b053332a9fe9a7120 Author: Martin Willi Date: Tue Apr 11 09:43:19 2023 +0200 rtnetlink: Restore RTM_NEW/DELLINK notification behavior [ Upstream commit 59d3efd27c11c59b32291e5ebc307bed2edb65ee ] The commits referenced below allows userspace to use the NLM_F_ECHO flag for RTM_NEW/DELLINK operations to receive unicast notifications for the affected link. Prior to these changes, applications may have relied on multicast notifications to learn the same information without specifying the NLM_F_ECHO flag. For such applications, the mentioned commits changed the behavior for requests not using NLM_F_ECHO. Multicast notifications are still received, but now use the portid of the requester and the sequence number of the request instead of zero values used previously. For the application, this message may be unexpected and likely handled as a response to the NLM_F_ACKed request, especially if it uses the same socket to handle requests and notifications. To fix existing applications relying on the old notification behavior, set the portid and sequence number in the notification only if the request included the NLM_F_ECHO flag. This restores the old behavior for applications not using it, but allows unicasted notifications for others. Fixes: f3a63cce1b4f ("rtnetlink: Honour NLM_F_ECHO flag in rtnl_delete_link") Fixes: d88e136cab37 ("rtnetlink: Honour NLM_F_ECHO flag in rtnl_newlink_create") Signed-off-by: Martin Willi Acked-by: Guillaume Nault Acked-by: Hangbin Liu Link: https://lore.kernel.org/r/20230411074319.24133-1-martin@strongswan.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 34fbb7b45bae20b551dda24337c7761ca13ce69d Author: Tetsuo Handa Date: Wed Apr 5 22:15:32 2023 +0900 cgroup,freezer: hold cpu_hotplug_lock before freezer_mutex [ Upstream commit 57dcd64c7e036299ef526b400a8d12b8a2352f26 ] syzbot is reporting circular locking dependency between cpu_hotplug_lock and freezer_mutex, for commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic") replaced atomic_inc() in freezer_apply_state() with static_branch_inc() which holds cpu_hotplug_lock. cpu_hotplug_lock => cgroup_threadgroup_rwsem => freezer_mutex cgroup_file_write() { cgroup_procs_write() { __cgroup_procs_write() { cgroup_procs_write_start() { cgroup_attach_lock() { cpus_read_lock() { percpu_down_read(&cpu_hotplug_lock); } percpu_down_write(&cgroup_threadgroup_rwsem); } } cgroup_attach_task() { cgroup_migrate() { cgroup_migrate_execute() { freezer_attach() { mutex_lock(&freezer_mutex); (...snipped...) } } } } (...snipped...) } } } freezer_mutex => cpu_hotplug_lock cgroup_file_write() { freezer_write() { freezer_change_state() { mutex_lock(&freezer_mutex); freezer_apply_state() { static_branch_inc(&freezer_active) { static_key_slow_inc() { cpus_read_lock(); static_key_slow_inc_cpuslocked(); cpus_read_unlock(); } } } mutex_unlock(&freezer_mutex); } } } Swap locking order by moving cpus_read_lock() in freezer_apply_state() to before mutex_lock(&freezer_mutex) in freezer_change_state(). Reported-by: syzbot Link: https://syzkaller.appspot.com/bug?extid=c39682e86c9d84152f93 Suggested-by: Hillf Danton Fixes: f5d39b020809 ("freezer,sched: Rewrite core freezer logic") Signed-off-by: Tetsuo Handa Acked-by: Peter Zijlstra (Intel) Reviewed-by: Mukesh Ojha Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit f3848e89087c483e08eedbd51dd363c3ce9d0c2c Author: Harshit Mogalapalli Date: Sat Apr 8 12:43:21 2023 -0700 net: wwan: iosm: Fix error handling path in ipc_pcie_probe() [ Upstream commit a56ef25619e079bd7d744636cf18d054d1e91982 ] Smatch reports: drivers/net/wwan/iosm/iosm_ipc_pcie.c:298 ipc_pcie_probe() warn: missing unwind goto? When dma_set_mask fails it directly returns without disabling pci device and freeing ipc_pcie. Fix this my calling a correct goto label As dma_set_mask returns either 0 or -EIO, we can use a goto label, as it finally returns -EIO. Add a set_mask_fail goto label which stands consistent with other goto labels in this function.. Fixes: 035e3befc191 ("net: wwan: iosm: fix driver not working with INTEL_IOMMU disabled") Reviewed-by: Simon Horman Signed-off-by: Harshit Mogalapalli Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1cc41c8acfc1ee30b4868559058db97fa44b0137 Author: Kuniyuki Iwashima Date: Sat Apr 8 11:49:43 2023 -0700 smc: Fix use-after-free in tcp_write_timer_handler(). [ Upstream commit 9744d2bf19762703704ecba885b7ac282c02eacf ] With Eric's ref tracker, syzbot finally found a repro for use-after-free in tcp_write_timer_handler() by kernel TCP sockets. [0] If SMC creates a kernel socket in __smc_create(), the kernel socket is supposed to be freed in smc_clcsock_release() by calling sock_release() when we close() the parent SMC socket. However, at the end of smc_clcsock_release(), the kernel socket's sk_state might not be TCP_CLOSE. This means that we have not called inet_csk_destroy_sock() in __tcp_close() and have not stopped the TCP timers. The kernel socket's TCP timers can be fired later, so we need to hold a refcnt for net as we do for MPTCP subflows in mptcp_subflow_create_socket(). [0]: leaked reference. sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108) inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244) __sock_create (net/socket.c:1546) smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284) __sock_create (net/socket.c:1546) __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661) __x64_sys_socket (net/socket.c:1672) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) ================================================================== BUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594) Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091 CPU: 0 PID: 18091 Comm: syzrepro Tainted: G W 6.3.0-rc4-01174-gb5d54eb5899a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:107) print_report (mm/kasan/report.c:320 mm/kasan/report.c:430) kasan_report (mm/kasan/report.c:538) tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594) tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643) call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022) run_timer_softirq (kernel/time/timer.c:2037) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572) __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650) irq_exit_rcu (kernel/softirq.c:664) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14)) Fixes: ac7138746e14 ("smc: establish new socket family") Reported-by: syzbot+7e1e1bdb852961150198@syzkaller.appspotmail.com Link: https://lore.kernel.org/netdev/000000000000a3f51805f8bcc43a@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Tony Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7bb5b0353adbcdd55b69037c25e21003cab62fa4 Author: Denis Plotnikov Date: Fri Apr 7 10:18:49 2023 +0300 qlcnic: check pci_reset_function result [ Upstream commit 7573099e10ca69c3be33995c1fcd0d241226816d ] Static code analyzer complains to unchecked return value. The result of pci_reset_function() is unchecked. Despite, the issue is on the FLR supported code path and in that case reset can be done with pcie_flr(), the patch uses less invasive approach by adding the result check of pci_reset_function(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 7e2cf4feba05 ("qlcnic: change driver hardware interface mechanism") Signed-off-by: Denis Plotnikov Reviewed-by: Simon Horman Reviewed-by: Bjorn Helgaas Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 79f4e029d5f800653cfa4d92365275e16864a6d9 Author: Christophe JAILLET Date: Sun Dec 26 17:34:16 2021 +0100 drm/armada: Fix a potential double free in an error handling path [ Upstream commit b89ce1177d42d5c124e83f3858818cd4e6a2c46f ] 'priv' is a managed resource, so there is no need to free it explicitly or there will be a double free(). Fixes: 90ad200b4cbc ("drm/armada: Use devm_drm_dev_alloc") Signed-off-by: Christophe JAILLET Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/c4f3c9207a9fce35cb6dd2cc60e755275961588a.1640536364.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 49daa251504f817f8392481c168b8a8c0e888b1e Author: Karol Herbst Date: Wed Apr 5 13:04:55 2023 +0200 drm/nouveau/fb: add missing sysmen flush callbacks [ Upstream commit 86d8740dae5a397d8344ae75f8758103c1fcba97 ] Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/203 Fixes: 5728d064190e1 ("drm/nouveau/fb: handle sysmem flush page from common code") Signed-off-by: Karol Herbst Reviewed-by: Lyude Paul Reviewed-by: Ben Skeggs Link: https://patchwork.freedesktop.org/patch/msgid/20230405110455.1368428-1-kherbst@redhat.com Signed-off-by: Sasha Levin commit d60ba965d5be92ac31f6ad4f01d2b02b19c12eb3 Author: Claudia Draghicescu Date: Wed Apr 5 14:19:18 2023 +0300 Bluetooth: Set ISO Data Path on broadcast sink [ Upstream commit d2e4f1b1cba8742db66aaf77374cab7c0c7c8656 ] This patch enables ISO data rx on broadcast sink. Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Signed-off-by: Claudia Draghicescu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b80f1809f7f612885ce8affa7e26b4f6a0f61aec Author: Luiz Augusto von Dentz Date: Thu Mar 30 14:45:03 2023 -0700 Bluetooth: SCO: Fix possible circular locking dependency sco_sock_getsockopt [ Upstream commit 975abc0c90fc485ff9b4a6afa475c3b1398d5d47 ] This attempts to fix the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.3.0-rc2-g68fcb3a7bf97 #4706 Not tainted ------------------------------------------------------ sco-tester/31 is trying to acquire lock: ffff8880025b8070 (&hdev->lock){+.+.}-{3:3}, at: sco_sock_getsockopt+0x1fc/0xa90 but task is already holding lock: ffff888001eeb130 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_getsockopt+0x104/0xa90 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}: lock_sock_nested+0x32/0x80 sco_connect_cfm+0x118/0x4a0 hci_sync_conn_complete_evt+0x1e6/0x3d0 hci_event_packet+0x55c/0x7c0 hci_rx_work+0x34c/0xa00 process_one_work+0x575/0x910 worker_thread+0x89/0x6f0 kthread+0x14e/0x180 ret_from_fork+0x2b/0x50 -> #1 (hci_cb_list_lock){+.+.}-{3:3}: __mutex_lock+0x13b/0xcc0 hci_sync_conn_complete_evt+0x1ad/0x3d0 hci_event_packet+0x55c/0x7c0 hci_rx_work+0x34c/0xa00 process_one_work+0x575/0x910 worker_thread+0x89/0x6f0 kthread+0x14e/0x180 ret_from_fork+0x2b/0x50 -> #0 (&hdev->lock){+.+.}-{3:3}: __lock_acquire+0x18cc/0x3740 lock_acquire+0x151/0x3a0 __mutex_lock+0x13b/0xcc0 sco_sock_getsockopt+0x1fc/0xa90 __sys_getsockopt+0xe9/0x190 __x64_sys_getsockopt+0x5b/0x70 do_syscall_64+0x42/0x90 entry_SYSCALL_64_after_hwframe+0x70/0xda other info that might help us debug this: Chain exists of: &hdev->lock --> hci_cb_list_lock --> sk_lock-AF_BLUETOOTH-BTPROTO_SCO Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO); lock(hci_cb_list_lock); lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO); lock(&hdev->lock); *** DEADLOCK *** 1 lock held by sco-tester/31: #0: ffff888001eeb130 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_getsockopt+0x104/0xa90 Fixes: 248733e87d50 ("Bluetooth: Allow querying of supported offload codecs over SCO socket") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 0a893ad144aba8f17c9d520f9cdf44cdc626fb6a Author: Luiz Augusto von Dentz Date: Fri Mar 24 13:18:20 2023 -0700 Bluetooth: Fix printing errors if LE Connection times out [ Upstream commit b62e72200eaad523f08d8319bba50fc652e032a8 ] This fixes errors like bellow when LE Connection times out since that is actually not a controller error: Bluetooth: hci0: Opcode 0x200d failed: -110 Bluetooth: hci0: request failed to create LE connection: err -110 Instead the code shall properly detect if -ETIMEDOUT is returned and send HCI_OP_LE_CREATE_CONN_CANCEL to give up on the connection. Link: https://github.com/bluez/bluez/issues/340 Fixes: 8e8b92ee60de ("Bluetooth: hci_sync: Add hci_le_create_conn_sync") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 0424c2e3944061b43aac6fd95f671989c611140e Author: Luiz Augusto von Dentz Date: Fri Mar 24 10:57:55 2023 -0700 Bluetooth: hci_conn: Fix not cleaning up on LE Connection failure [ Upstream commit 19cf60bf63cbaf5262eac400c707966e19999b83 ] hci_connect_le_scan_cleanup shall always be invoked to cleanup the states and re-enable passive scanning if necessary, otherwise it may cause the pending action to stay active causing multiple attempts to connect. Fixes: 9b3628d79b46 ("Bluetooth: hci_sync: Cleanup hci_conn if it cannot be aborted") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 56252da41426f3d01957456f13caf46ce670ea29 Author: Felix Huettner Date: Wed Apr 5 07:53:41 2023 +0000 net: openvswitch: fix race on port output [ Upstream commit 066b86787fa3d97b7aefb5ac0a99a22dad2d15f8 ] assume the following setup on a single machine: 1. An openvswitch instance with one bridge and default flows 2. two network namespaces "server" and "client" 3. two ovs interfaces "server" and "client" on the bridge 4. for each ovs interface a veth pair with a matching name and 32 rx and tx queues 5. move the ends of the veth pairs to the respective network namespaces 6. assign ip addresses to each of the veth ends in the namespaces (needs to be the same subnet) 7. start some http server on the server network namespace 8. test if a client in the client namespace can reach the http server when following the actions below the host has a chance of getting a cpu stuck in a infinite loop: 1. send a large amount of parallel requests to the http server (around 3000 curls should work) 2. in parallel delete the network namespace (do not delete interfaces or stop the server, just kill the namespace) there is a low chance that this will cause the below kernel cpu stuck message. If this does not happen just retry. Below there is also the output of bpftrace for the functions mentioned in the output. The series of events happening here is: 1. the network namespace is deleted calling `unregister_netdevice_many_notify` somewhere in the process 2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and then runs `synchronize_net` 3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER` 4. this is then handled by `dp_device_event` which calls `ovs_netdev_detach_dev` (if a vport is found, which is the case for the veth interface attached to ovs) 5. this removes the rx_handlers of the device but does not prevent packages to be sent to the device 6. `dp_device_event` then queues the vport deletion to work in background as a ovs_lock is needed that we do not hold in the unregistration path 7. `unregister_netdevice_many_notify` continues to call `netdev_unregister_kobject` which sets `real_num_tx_queues` to 0 8. port deletion continues (but details are not relevant for this issue) 9. at some future point the background task deletes the vport If after 7. but before 9. a packet is send to the ovs vport (which is not deleted at this point in time) which forwards it to the `dev_queue_xmit` flow even though the device is unregistering. In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there is a while loop (if the packet has a rx_queue recorded) that is infinite if `dev->real_num_tx_queues` is zero. To prevent this from happening we update `do_output` to handle devices without carrier the same as if the device is not found (which would be the code path after 9. is done). Additionally we now produce a warning in `skb_tx_hash` if we will hit the infinite loop. bpftrace (first word is function name): __dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2 ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2 netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 27, reg_state: 2 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 22, reg_state: 2 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 18, reg_state: 2 netdev_unregister_kobject: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 ovs_vport_send server: real_num_tx_queues: 0, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 2 __dev_queue_xmit server: real_num_tx_queues: 0, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 2 netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 0, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 2 broken device server: real_num_tx_queues: 0, cpu: 2, pid: 28024, tid: 28024 ovs_dp_detach_port server: real_num_tx_queues: 0 cpu 9, pid: 9124, tid: 9124, reg_state: 2 synchronize_rcu_expedited: cpu 9, pid: 33604, tid: 33604 stuck message: watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [curl:1929279] Modules linked in: veth pktgen bridge stp llc ip_set_hash_net nft_counter xt_set nft_compat nf_tables ip_set_hash_ip ip_set nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 tls binfmt_misc nls_iso8859_1 input_leds joydev serio_raw dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua sch_fq_codel drm efi_pstore virtio_rng ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel virtio_net ahci net_failover crypto_simd cryptd psmouse libahci virtio_blk failover CPU: 5 PID: 1929279 Comm: curl Not tainted 5.15.0-67-generic #74-Ubuntu Hardware name: OpenStack Foundation OpenStack Nova, BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:netdev_pick_tx+0xf1/0x320 Code: 00 00 8d 48 ff 0f b7 c1 66 39 ca 0f 86 e9 01 00 00 45 0f b7 ff 41 39 c7 0f 87 5b 01 00 00 44 29 f8 41 39 c7 0f 87 4f 01 00 00 f2 0f 1f 44 00 00 49 8b 94 24 28 04 00 00 48 85 d2 0f 84 53 01 RSP: 0018:ffffb78b40298820 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff9c8773adc2e0 RCX: 000000000000083f RDX: 0000000000000000 RSI: ffff9c8773adc2e0 RDI: ffff9c870a25e000 RBP: ffffb78b40298858 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9c870a25e000 R13: ffff9c870a25e000 R14: ffff9c87fe043480 R15: 0000000000000000 FS: 00007f7b80008f00(0000) GS:ffff9c8e5f740000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7b80f6a0b0 CR3: 0000000329d66000 CR4: 0000000000350ee0 Call Trace: netdev_core_pick_tx+0xa4/0xb0 __dev_queue_xmit+0xf8/0x510 ? __bpf_prog_exit+0x1e/0x30 dev_queue_xmit+0x10/0x20 ovs_vport_send+0xad/0x170 [openvswitch] do_output+0x59/0x180 [openvswitch] do_execute_actions+0xa80/0xaa0 [openvswitch] ? kfree+0x1/0x250 ? kfree+0x1/0x250 ? kprobe_perf_func+0x4f/0x2b0 ? flow_lookup.constprop.0+0x5c/0x110 [openvswitch] ovs_execute_actions+0x4c/0x120 [openvswitch] ovs_dp_process_packet+0xa1/0x200 [openvswitch] ? ovs_ct_update_key.isra.0+0xa8/0x120 [openvswitch] ? ovs_ct_fill_key+0x1d/0x30 [openvswitch] ? ovs_flow_key_extract+0x2db/0x350 [openvswitch] ovs_vport_receive+0x77/0xd0 [openvswitch] ? __htab_map_lookup_elem+0x4e/0x60 ? bpf_prog_680e8aff8547aec1_kfree+0x3b/0x714 ? trace_call_bpf+0xc8/0x150 ? kfree+0x1/0x250 ? kfree+0x1/0x250 ? kprobe_perf_func+0x4f/0x2b0 ? kprobe_perf_func+0x4f/0x2b0 ? __mod_memcg_lruvec_state+0x63/0xe0 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23d/0xf00 __netif_receive_skb_one_core+0x3f/0xa0 __netif_receive_skb+0x15/0x60 process_backlog+0x9e/0x170 __napi_poll+0x33/0x180 net_rx_action+0x126/0x280 ? ttwu_do_activate+0x72/0xf0 __do_softirq+0xd9/0x2e7 ? rcu_report_exp_cpu_mult+0x1b0/0x1b0 do_softirq+0x7d/0xb0 __local_bh_enable_ip+0x54/0x60 ip_finish_output2+0x191/0x460 __ip_finish_output+0xb7/0x180 ip_finish_output+0x2e/0xc0 ip_output+0x78/0x100 ? __ip_finish_output+0x180/0x180 ip_local_out+0x5e/0x70 __ip_queue_xmit+0x184/0x440 ? tcp_syn_options+0x1f9/0x300 ip_queue_xmit+0x15/0x20 __tcp_transmit_skb+0x910/0x9c0 ? __mod_memcg_state+0x44/0xa0 tcp_connect+0x437/0x4e0 ? ktime_get_with_offset+0x60/0xf0 tcp_v4_connect+0x436/0x530 __inet_stream_connect+0xd4/0x3a0 ? kprobe_perf_func+0x4f/0x2b0 ? aa_sk_perm+0x43/0x1c0 inet_stream_connect+0x3b/0x60 __sys_connect_file+0x63/0x70 __sys_connect+0xa6/0xd0 ? setfl+0x108/0x170 ? do_fcntl+0xe8/0x5a0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x5c/0xc0 ? __x64_sys_fcntl+0xa9/0xd0 ? exit_to_user_mode_prepare+0x37/0xb0 ? syscall_exit_to_user_mode+0x27/0x50 ? do_syscall_64+0x69/0xc0 ? __sys_setsockopt+0xea/0x1e0 ? exit_to_user_mode_prepare+0x37/0xb0 ? syscall_exit_to_user_mode+0x27/0x50 ? __x64_sys_setsockopt+0x1f/0x30 ? do_syscall_64+0x69/0xc0 ? irqentry_exit+0x1d/0x30 ? exc_page_fault+0x89/0x170 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7f7b8101c6a7 Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 18 89 54 24 0c 48 89 34 24 89 RSP: 002b:00007ffffd6b2198 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7b8101c6a7 RDX: 0000000000000010 RSI: 00007ffffd6b2360 RDI: 0000000000000005 RBP: 0000561f1370d560 R08: 00002795ad21d1ac R09: 0030312e302e302e R10: 00007ffffd73f080 R11: 0000000000000246 R12: 0000561f1370c410 R13: 0000000000000000 R14: 0000000000000005 R15: 0000000000000000 Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action") Co-developed-by: Luca Czesla Signed-off-by: Luca Czesla Signed-off-by: Felix Huettner Reviewed-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/ZC0pBXBAgh7c76CA@kernel-bug-kernel-bug Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d4aec9d6aff1c71e072b10ef74a73a11f28f77ca Author: Ahmed Zaki Date: Thu Apr 6 15:35:28 2023 -0600 iavf: remove active_cvlans and active_svlans bitmaps [ Upstream commit 9c85b7fa12ef2e4fc11a4e31ac595fb5f9d0ddf9 ] The VLAN filters info is currently being held in a list and 2 bitmaps (active_cvlans and active_svlans). We are experiencing some racing where data is not in sync in the list and bitmaps. For example, the VLAN is initially added to the list but only when the PF replies, it is added to the bitmap. If a user adds many V2 VLANS before the PF responds: while [ $((i++)) ] ip l add l eth0 name eth0.$i type vlan id $i we might end up with more VLAN list entries than the designated limit. Also, The "ip link show" will show more links added than the PF limit. On the other and, the bitmaps are only used to check the number of VLAN filters and to re-enable the filters when the interface goes from DOWN to UP. This patch gets rid of the bitmaps and uses the list only. To do that, the states of the VLAN filter are modified: 1 - IAVF_VLAN_REMOVE: the entry needs to be totally removed after informing the PF. This is the "ip link del eth0.$i" path. 2 - IAVF_VLAN_DISABLE: (new) the netdev went down. The filter needs to be removed from the PF and then marked INACTIVE. 3 - IAVF_VLAN_INACTIVE: (new) no PF filter exists, but the user did not delete the VLAN. Fixes: 48ccc43ecf10 ("iavf: Add support VIRTCHNL_VF_OFFLOAD_VLAN_V2 during netdev config") Signed-off-by: Ahmed Zaki Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e5596bba06e3ad4edf3ab03bf72557ff893a8136 Author: Ahmed Zaki Date: Thu Apr 6 15:35:27 2023 -0600 iavf: refactor VLAN filter states [ Upstream commit 0c0da0e951053fda20412cd284e2714bbbb31bff ] The VLAN filter states are currently being saved as individual bits. This is error prone as multiple bits might be mistakenly set. Fix by replacing the bits with a single state enum. Also, add an "ACTIVE" state for filters that are accepted by the PF. Signed-off-by: Ahmed Zaki Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Stable-dep-of: 9c85b7fa12ef ("iavf: remove active_cvlans and active_svlans bitmaps") Signed-off-by: Sasha Levin commit 9dcf3d36f0312414f003f381f41867359a04cc10 Author: Hangbin Liu Date: Thu Apr 6 16:23:50 2023 +0800 bonding: fix ns validation on backup slaves [ Upstream commit 4598380f9c548aa161eb4e990a1583f0a7d1e0d7 ] When arp_validate is set to 2, 3, or 6, validation is performed for backup slaves as well. As stated in the bond documentation, validation involves checking the broadcast ARP request sent out via the active slave. This helps determine which slaves are more likely to function in the event of an active slave failure. However, when the target is an IPv6 address, the NS message sent from the active interface is not checked on backup slaves. Additionally, based on the bond_arp_rcv() rule b, we must reverse the saddr and daddr when checking the NS message. Note that when checking the NS message, the destination address is a multicast address. Therefore, we must convert the target address to solicited multicast in the bond_get_targets_ip6() function. Prior to the fix, the backup slaves had a mii status of "down", but after the fix, all of the slaves' mii status was updated to "UP". Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets") Reviewed-by: Jonathan Toppins Acked-by: Jay Vosburgh Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8ec0541b1c1707160036b3103df7ffb9d52262cf Author: YueHaibing Date: Thu Apr 6 14:34:50 2023 +0800 tcp: restrict net.ipv4.tcp_app_win [ Upstream commit dc5110c2d959c1707e12df5f792f41d90614adaa ] UBSAN: shift-out-of-bounds in net/ipv4/tcp_input.c:555:23 shift exponent 255 is too large for 32-bit type 'int' CPU: 1 PID: 7907 Comm: ssh Not tainted 6.3.0-rc4-00161-g62bad54b26db-dirty #206 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x136/0x150 __ubsan_handle_shift_out_of_bounds+0x21f/0x5a0 tcp_init_transfer.cold+0x3a/0xb9 tcp_finish_connect+0x1d0/0x620 tcp_rcv_state_process+0xd78/0x4d60 tcp_v4_do_rcv+0x33d/0x9d0 __release_sock+0x133/0x3b0 release_sock+0x58/0x1b0 'maxwin' is int, shifting int for 32 or more bits is undefined behaviour. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: YueHaibing Reviewed-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 32622ba23c6acf9a405937e3e3af2bf755fa39e2 Author: Harshit Mogalapalli Date: Wed Apr 5 23:31:18 2023 -0700 niu: Fix missing unwind goto in niu_alloc_channels() [ Upstream commit 8ce07be703456acb00e83d99f3b8036252c33b02 ] Smatch reports: drivers/net/ethernet/sun/niu.c:4525 niu_alloc_channels() warn: missing unwind goto? If niu_rbr_fill() fails, then we are directly returning 'err' without freeing the channels. Fix this by changing direct return to a goto 'out_err'. Fixes: a3138df9f20e ("[NIU]: Add Sun Neptune ethernet driver.") Signed-off-by: Harshit Mogalapalli Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6e83bde56955511c168e6a7bc05efac832de2e1c Author: Fuad Tabba Date: Tue Apr 4 16:23:21 2023 +0100 KVM: arm64: Advertise ID_AA64PFR0_EL1.CSV2/3 to protected VMs [ Upstream commit e81625218bf7986ba1351a98c43d346b15601d26 ] The existing pKVM code attempts to advertise CSV2/3 using values initialized to 0, but never set. To advertise CSV2/3 to protected guests, pass the CSV2/3 values to hyp when initializing hyp's view of guests' ID_AA64PFR0_EL1. Similar to non-protected KVM, these are system-wide, rather than per cpu, for simplicity. Fixes: 6c30bfb18d0b ("KVM: arm64: Add handlers for protected VM System Registers") Signed-off-by: Fuad Tabba Link: https://lore.kernel.org/r/20230404152321.413064-1-tabba@google.com Signed-off-by: Oliver Upton Signed-off-by: Sasha Levin commit eabc166919d169e105263974991f52b0351e431a Author: Xu Kuohai Date: Sat Apr 1 19:41:44 2023 -0400 bpf, arm64: Fixed a BTI error on returning to patched function [ Upstream commit 738a96c4a8c36950803fdd27e7c30aca92dccefd ] When BPF_TRAMP_F_CALL_ORIG is set, BPF trampoline uses BLR to jump back to the instruction next to call site to call the patched function. For BTI-enabled kernel, the instruction next to call site is usually PACIASP, in this case, it's safe to jump back with BLR. But when the call site is not followed by a PACIASP or bti, a BTI exception is triggered. Here is a fault log: Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI CPU: 0 PID: 263 Comm: test_progs Tainted: GF Hardware name: linux,dummy-virt (DT) pstate: 40400805 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c) pc : bpf_fentry_test1+0xc/0x30 lr : bpf_trampoline_6442573892_0+0x48/0x1000 sp : ffff80000c0c3a50 x29: ffff80000c0c3a90 x28: ffff0000c2e6c080 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000050 x23: 0000000000000000 x22: 0000ffffcfd2a7f0 x21: 000000000000000a x20: 0000ffffcfd2a7f0 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffcfd2a7f0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff80000914f5e4 x9 : ffff8000082a1528 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0101010101010101 x5 : 0000000000000000 x4 : 00000000fffffff2 x3 : 0000000000000001 x2 : ffff8001f4b82000 x1 : 0000000000000000 x0 : 0000000000000001 Kernel panic - not syncing: Unhandled exception CPU: 0 PID: 263 Comm: test_progs Tainted: GF Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0xec/0x144 show_stack+0x24/0x7c dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x1cc/0x3ec __el0_error_handler_common+0x0/0x130 el1h_64_sync_handler+0x60/0xd0 el1h_64_sync+0x78/0x7c bpf_fentry_test1+0xc/0x30 bpf_fentry_test1+0xc/0x30 bpf_prog_test_run_tracing+0xdc/0x2a0 __sys_bpf+0x438/0x22a0 __arm64_sys_bpf+0x30/0x54 invoke_syscall+0x78/0x110 el0_svc_common.constprop.0+0x6c/0x1d0 do_el0_svc+0x38/0xe0 el0_svc+0x30/0xd0 el0t_64_sync_handler+0x1ac/0x1b0 el0t_64_sync+0x1a0/0x1a4 Kernel Offset: disabled CPU features: 0x0000,00034c24,f994fdab Memory Limit: none And the instruction next to call site of bpf_fentry_test1 is ADD, not PACIASP: : bti c nop nop add w0, w0, #0x1 paciasp For BPF prog, JIT always puts a PACIASP after call site for BTI-enabled kernel, so there is no problem. To fix it, replace BLR with RET to bypass the branch target check. Fixes: efc9909fdce0 ("bpf, arm64: Add bpf trampoline for arm64") Reported-by: Florent Revest Signed-off-by: Xu Kuohai Signed-off-by: Daniel Borkmann Tested-by: Florent Revest Acked-by: Florent Revest Link: https://lore.kernel.org/bpf/20230401234144.3719742-1-xukuohai@huaweicloud.com Signed-off-by: Sasha Levin commit e7dcd834af53c79418ca3cd1c42749a314b9f7dc Author: Zheng Wang Date: Mon Mar 13 22:43:25 2023 +0800 9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition [ Upstream commit ea4f1009408efb4989a0f139b70fb338e7f687d0 ] In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring to init priv->rings and bound &ring->work with p9_xen_response. When it calls xen_9pfs_front_event_handler to handle IRQ requests, it will finally call schedule_work to start the work. When we call xen_9pfs_front_remove to remove the driver, there may be a sequence as follows: Fix it by finishing the work before cleanup in xen_9pfs_front_free. Note that, this bug is found by static analysis, which might be false positive. CPU0 CPU1 |p9_xen_response xen_9pfs_front_remove| xen_9pfs_front_free| kfree(priv) | //free priv | |p9_tag_lookup |//use priv->client Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend") Signed-off-by: Zheng Wang Reviewed-by: Michal Swiatkowski Signed-off-by: Eric Van Hensbergen Signed-off-by: Sasha Levin commit fd4d88e68c75caf5c6f8293a36bc3ae289e0369e Author: Martin Povišer Date: Fri Feb 24 16:22:21 2023 +0100 dmaengine: apple-admac: Fix 'current_tx' not getting freed [ Upstream commit d9503be5a100c553731c0e8a82c7b4201e8a970c ] In terminate_all we should queue up all submitted descriptors to be freed. We do that for the content of the 'issued' and 'submitted' lists, but the 'current_tx' descriptor falls through the cracks as it's removed from the 'issued' list once it gets assigned to be the current descriptor. Explicitly queue up freeing of the 'current_tx' descriptor to address a memory leak that is otherwise present. Fixes: b127315d9a78 ("dmaengine: apple-admac: Add Apple ADMAC driver") Signed-off-by: Martin Povišer Link: https://lore.kernel.org/r/20230224152222.26732-2-povik+lin@cutebit.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1755eb628b2d4d6eae2399363e9fdd9e52ec2108 Author: Martin Povišer Date: Fri Feb 24 16:22:22 2023 +0100 dmaengine: apple-admac: Set src_addr_widths capability [ Upstream commit 6e96adcaa7a29827ac8ee8df290a44957a4823ec ] Add missing setting of 'src_addr_widths', which is the same as for the other direction. Fixes: b127315d9a78 ("dmaengine: apple-admac: Add Apple ADMAC driver") Signed-off-by: Martin Povišer Link: https://lore.kernel.org/r/20230224152222.26732-3-povik+lin@cutebit.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f6ff55786e472aa291ec44c192688ea80d2564eb Author: Martin Povišer Date: Fri Feb 24 16:22:20 2023 +0100 dmaengine: apple-admac: Handle 'global' interrupt flags [ Upstream commit a288fd158fbf85c06a9ac01cecabf97ac5d962e7 ] In addition to TX channel and RX channel interrupt flags there's another class of 'global' interrupt flags with unknown semantics. Those weren't being handled up to now, and they are the suspected cause of stuck IRQ states that have been sporadically occurring. Check the global flags and clear them if raised. Fixes: b127315d9a78 ("dmaengine: apple-admac: Add Apple ADMAC driver") Signed-off-by: Martin Povišer Link: https://lore.kernel.org/r/20230224152222.26732-1-povik+lin@cutebit.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d9263793f77e3ac366164d4f316c440c69c5b629 Author: George Guo Date: Tue Mar 28 15:13:35 2023 +0800 LoongArch, bpf: Fix jit to skip speculation barrier opcode [ Upstream commit a6f6a95f25803500079513780d11a911ce551d76 ] Just skip the opcode(BPF_ST | BPF_NOSPEC) in the BPF JIT instead of failing to JIT the entire program, given LoongArch currently has no couterpart of a speculation barrier instruction. To verify the issue, use the ltp testcase as shown below. Also, Wang says: I can confirm there's currently no speculation barrier equivalent on LonogArch. (Loongson says there are builtin mitigations for Spectre-V1 and V2 on their chips, and AFAIK efforts to port the exploits to mips/LoongArch have all failed a few years ago.) Without this patch: $ ./bpf_prog02 [...] bpf_common.c:123: TBROK: Failed verification: ??? (524) [...] Summary: passed 0 failed 0 broken 1 skipped 0 warnings 0 With this patch: $ ./bpf_prog02 [...] Summary: passed 0 failed 0 broken 0 skipped 0 warnings 0 Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support") Signed-off-by: George Guo Signed-off-by: Daniel Borkmann Acked-by: WANG Xuerui Cc: Tiezhu Yang Link: https://lore.kernel.org/bpf/20230328071335.2664966-1-guodongtai@kylinos.cn Signed-off-by: Sasha Levin commit 2b4468f3341586a9a930d25abf3bd4596570f088 Author: Martin KaFai Lau Date: Mon Mar 27 17:42:32 2023 -0700 bpf: tcp: Use sock_gen_put instead of sock_put in bpf_iter_tcp [ Upstream commit 580031ff9952b7dbf48dedba6b56a100ae002bef ] While reviewing the udp-iter batching patches, noticed the bpf_iter_tcp calling sock_put() is incorrect. It should call sock_gen_put instead because bpf_iter_tcp is iterating the ehash table which has the req sk and tw sk. This patch replaces all sock_put with sock_gen_put in the bpf_iter_tcp codepath. Fixes: 04c7820b776f ("bpf: tcp: Bpf iter batching and lock_sock") Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20230328004232.2134233-1-martin.lau@linux.dev Signed-off-by: Sasha Levin commit bb18b9dbac2bbdf7695e0bfaac4bf944ff7b207d Author: Mark Zhang Date: Mon Mar 20 12:59:55 2023 +0200 RDMA/cma: Allow UD qp_type to join multicast only [ Upstream commit 58e84f6b3e84e46524b7e5a916b53c1ad798bc8f ] As for multicast: - The SIDR is the only mode that makes sense; - Besides PS_UDP, other port spaces like PS_IB is also allowed, as it is UD compatible. In this case qkey also needs to be set [1]. This patch allows only UD qp_type to join multicast, and set qkey to default if it's not set, to fix an uninit-value error: the ib->rec.qkey field is accessed without being initialized. ===================================================== BUG: KMSAN: uninit-value in cma_set_qkey drivers/infiniband/core/cma.c:510 [inline] BUG: KMSAN: uninit-value in cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570 cma_set_qkey drivers/infiniband/core/cma.c:510 [inline] cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570 cma_iboe_join_multicast drivers/infiniband/core/cma.c:4782 [inline] rdma_join_multicast+0x2b83/0x30a0 drivers/infiniband/core/cma.c:4814 ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479 ucma_join_multicast+0x1e3/0x250 drivers/infiniband/core/ucma.c:1546 ucma_write+0x639/0x6d0 drivers/infiniband/core/ucma.c:1732 vfs_write+0x8ce/0x2030 fs/read_write.c:588 ksys_write+0x28c/0x520 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __ia32_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline] __do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180 do_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c Local variable ib.i created at: cma_iboe_join_multicast drivers/infiniband/core/cma.c:4737 [inline] rdma_join_multicast+0x586/0x30a0 drivers/infiniband/core/cma.c:4814 ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479 CPU: 0 PID: 29874 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 ===================================================== [1] https://lore.kernel.org/linux-rdma/20220117183832.GD84788@nvidia.com/ Fixes: b5de0c60cc30 ("RDMA/cma: Fix use after free race in roce multicast join") Reported-by: syzbot+8fcbb77276d43cc8b693@syzkaller.appspotmail.com Signed-off-by: Mark Zhang Link: https://lore.kernel.org/r/58a4a98323b5e6b1282e83f6b76960d06e43b9fa.1679309909.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a983967602675880d6160a17ace2c0f48717ff33 Author: Alexander Stein Date: Fri Mar 10 08:49:40 2023 +0100 clk: rs9: Fix suspend/resume [ Upstream commit 632e04739c8f45c2d9ca4d4c5bd18d80c2ac9296 ] Disabling the cache in commit 2ff4ba9e3702 ("clk: rs9: Fix I2C accessors") without removing cache synchronization in resume path results in a kernel panic as map->cache_ops is unset, due to REGCACHE_NONE. Enable flat cache again to support resume again. num_reg_defaults_raw is necessary to read the cache defaults from hardware. Some registers are strapped in hardware and cannot be provided in software. Fixes: 2ff4ba9e3702 ("clk: rs9: Fix I2C accessors") Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20230310074940.3475703-1-alexander.stein@ew.tq-group.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 7c18dbfa017cd5a9e0214dd4f006ca1037073655 Author: Cheng Xu Date: Mon Mar 20 16:46:52 2023 +0800 RDMA/erdma: Defer probing if netdevice can not be found [ Upstream commit 6bd1bca858f1734a75572a788213d1e1143f2f0a ] ERDMA device may be probed before its associated netdevice, returning -EPROBE_DEFER allows OS try to probe erdma device later. Fixes: d55e6fb4803c ("RDMA/erdma: Add the erdma module") Signed-off-by: Cheng Xu Link: https://lore.kernel.org/r/20230320084652.16807-5-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 2d78e502d855830e392f2279e1697ca527eedfe0 Author: Cheng Xu Date: Mon Mar 20 16:46:51 2023 +0800 RDMA/erdma: Inline mtt entries into WQE if supported [ Upstream commit 0dd83a4d7756713f81990d6c5547500f212a1190 ] The max inline mtt count supported is ERDMA_MAX_INLINE_MTT_ENTRIES. When mr->mem.mtt_nents == ERDMA_MAX_INLINE_MTT_ENTRIES, inline mtt is also supported, fix it. Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation") Signed-off-by: Cheng Xu Link: https://lore.kernel.org/r/20230320084652.16807-4-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 55ce6da17f80b95314a002ccaf48026c6ee2369f Author: Cheng Xu Date: Mon Mar 20 16:46:50 2023 +0800 RDMA/erdma: Update default EQ depth to 4096 and max_send_wr to 8192 [ Upstream commit 6256aa9ae955d10ec73a434533ca62034eff1b76 ] Max EQ depth of hardware is 32K, the current default EQ depth is too small for some applications, so change the default depth to 4096. Max send WRs the hardware can support is 8K, but the driver limits the value to 4K. Remove this limitation. Fixes: be3cff0f242d ("RDMA/erdma: Add the hardware related definitions") Fixes: db23ae64caac ("RDMA/erdma: Add verbs header file") Signed-off-by: Cheng Xu Link: https://lore.kernel.org/r/20230320084652.16807-3-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 194f3aa560cb47163d6be9a9d1a61a9e8fa669c5 Author: Cheng Xu Date: Mon Mar 20 16:46:49 2023 +0800 RDMA/erdma: Fix some typos [ Upstream commit 3fe26c0493e4c2da4b7d8ba8c975a6f48fb75ec2 ] FAA is short for atomic fetch and add, not FAD. Fix this. Fixes: 0ca9c2e2844a ("RDMA/erdma: Implement atomic operations support") Signed-off-by: Cheng Xu Link: https://lore.kernel.org/r/20230320084652.16807-2-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 3d0cd97f61fca40809d7fc81a4468dbad80b6f05 Author: Maher Sanalla Date: Thu Mar 16 15:40:49 2023 +0200 IB/mlx5: Add support for 400G_8X lane speed [ Upstream commit 88c9483faf15ada14eca82714114656893063458 ] Currently, when driver queries PTYS to report which link speed is being used on its RoCE ports, it does not check the case of having 400Gbps transmitted over 8 lanes. Thus it fails to report the said speed and instead it defaults to report 10G over 4 lanes. Add a check for the said speed when querying PTYS and report it back correctly when needed. Fixes: 08e8676f1607 ("IB/mlx5: Add support for 50Gbps per lane link modes") Signed-off-by: Maher Sanalla Reviewed-by: Aya Levin Reviewed-by: Saeed Mahameed Link: https://lore.kernel.org/r/ec9040548d119d22557d6a4b4070d6f421701fd4.1678973994.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4f6b91993090262c8fdbfa3c7fb7d3acdc3ba86b Author: Tatyana Nikolova Date: Wed Mar 15 09:52:31 2023 -0500 RDMA/irdma: Add ipv4 check to irdma_find_listener() [ Upstream commit e4522c097ec10f23ea0933e9e69d4fa9d8ae9441 ] Add ipv4 check to irdma_find_listener(). Otherwise the function incorrectly finds and returns a listener with a different addr family for the zero IP addr, if a listener with a zero IP addr and the same port as the one searched for has already been created. Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager") Signed-off-by: Tatyana Nikolova Signed-off-by: Shiraz Saleem Link: https://lore.kernel.org/r/20230315145231.931-5-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 270f3530f7dec1b3b18fdcf3db7be30ade25b0d9 Author: Mustafa Ismail Date: Wed Mar 15 09:52:30 2023 -0500 RDMA/irdma: Increase iWARP CM default rexmit count [ Upstream commit 8385a875c9eecc429b2f72970efcbb0e5cb5b547 ] When running perftest with large number of connections in iWARP mode, the passive side could be slow to respond. Increase the rexmit counter default to allow scaling connections. Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager") Signed-off-by: Mustafa Ismail Signed-off-by: Shiraz Saleem Link: https://lore.kernel.org/r/20230315145231.931-4-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit adf58bd4018fbcd990c62e840afd2f178eefad60 Author: Mustafa Ismail Date: Wed Mar 15 09:52:29 2023 -0500 RDMA/irdma: Fix memory leak of PBLE objects [ Upstream commit b69a6979dbaa2453675fe9c71bdc2497fedb11f9 ] On rmmod of irdma, the PBLE object memory is not being freed. PBLE object memory are not statically pre-allocated at function initialization time unlike other HMC objects. PBLEs objects and the Segment Descriptors (SD) for it can be dynamically allocated during scale up and SD's remain allocated till function deinitialization. Fix this leak by adding IRDMA_HMC_IW_PBLE to the iw_hmc_obj_types[] table and skip pbles in irdma_create_hmc_obj but not in irdma_del_hmc_objects(). Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions") Signed-off-by: Mustafa Ismail Signed-off-by: Shiraz Saleem Link: https://lore.kernel.org/r/20230315145231.931-3-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c4e7f76dafd885a4cd0c0e06bfae6db3c3a58324 Author: Mustafa Ismail Date: Wed Mar 15 09:52:28 2023 -0500 RDMA/irdma: Do not generate SW completions for NOPs [ Upstream commit 30ed9ee9a10a90ae719dcfcacead1d0506fa45ed ] Currently, artificial SW completions are generated for NOP wqes which can generate unexpected completions with wr_id = 0. Skip the generation of artificial completions for NOPs. Fixes: 81091d7696ae ("RDMA/irdma: Add SW mechanism to generate completions on error") Signed-off-by: Mustafa Ismail Signed-off-by: Shiraz Saleem Link: https://lore.kernel.org/r/20230315145231.931-2-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a19b58887040bb3ee1594217946a59f2e8535002 Author: Chunyan Zhang Date: Thu Mar 16 10:36:24 2023 +0800 clk: sprd: set max_register according to mapping range [ Upstream commit 47d43086531f10539470a63e8ad92803e686a3dd ] In sprd clock driver, regmap_config.max_register was set to a fixed value which is likely larger than the address range configured in device tree, when reading registers through debugfs it would cause access violation. Fixes: d41f59fd92f2 ("clk: sprd: Add common infrastructure") Signed-off-by: Chunyan Zhang Link: https://lore.kernel.org/r/20230316023624.758204-1-chunyan.zhang@unisoc.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit fda4233d2425dc19349954c20eae2c46c87b4a14 Author: Ming Lei Date: Fri Apr 14 15:53:13 2023 +0800 io_uring: complete request via task work in case of DEFER_TASKRUN commit 860e1c7f8b0b43fbf91b4d689adfaa13adb89452 upstream. So far io_req_complete_post() only covers DEFER_TASKRUN by completing request via task work when the request is completed from IOWQ. However, uring command could be completed from any context, and if io uring is setup with DEFER_TASKRUN, the command is required to be completed from current context, otherwise wait on IORING_ENTER_GETEVENTS can't be wakeup, and may hang forever. The issue can be observed on removing ublk device, but turns out it is one generic issue for uring command & DEFER_TASKRUN, so solve it in io_uring core code. Fixes: e6aeb2721d3b ("io_uring: complete all requests in task context") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-block/b3fc9991-4c53-9218-a8cc-5b4dd3952108@kernel.dk/ Reported-by: Jens Axboe Cc: Kanchan Joshi Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0610761d3e8c05038aaf7e9e739440303b11b33c Author: Jani Nikula Date: Wed Mar 1 17:14:09 2023 +0200 drm/i915/dsi: fix DSS CTL register offsets for TGL+ commit 6b8446859c971a5783a2cdc90adf32e64de3bd23 upstream. On TGL+ the DSS control registers are at different offsets, and there's one per pipe. Fix the offsets to fix dual link DSI for TGL+. There would be helpers for this in the DSC code, but just do the quick fix now for DSI. Long term, we should probably move all the DSS handling into intel_vdsc.c, so exporting the helpers seems counter-productive. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8232 Cc: Ville Syrjala Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20230301151409.1581574-1-jani.nikula@intel.com (cherry picked from commit 1a62dd9895dca78bee28bba3a36f08836fdd143d) Signed-off-by: Greg Kroah-Hartman commit 62055fa6fbf8f1f1457f5d6a7d17ce1a45972613 Author: Daniel Vetter Date: Wed Apr 12 17:31:46 2023 +0200 fbcon: set_con2fb_map needs to set con2fb_map! commit fffb0b52d5258554c645c966c6cbef7de50b851d upstream. I got really badly confused in d443d9386472 ("fbcon: move more common code into fb_open()") because we set the con2fb_map before the failure points, which didn't look good. But in trying to fix that I moved the assignment into the wrong path - we need to do it for _all_ vc we take over, not just the first one (which additionally requires the call to con2fb_acquire_newinfo). I've figured this out because of a KASAN bug report, where the fbcon_registered_fb and fbcon_display arrays went out of sync in fbcon_mode_deleted() because the con2fb_map pointed at the old fb_info, but the modes and everything was updated for the new one. Signed-off-by: Daniel Vetter Reviewed-by: Javier Martinez Canillas Acked-by: Helge Deller Tested-by: Xingyuan Mo Fixes: d443d9386472 ("fbcon: move more common code into fb_open()") Reported-by: Xingyuan Mo Cc: Thomas Zimmermann Cc: Sam Ravnborg Cc: Xingyuan Mo Cc: Thomas Zimmermann Cc: Helge Deller Cc: # v5.19+ Signed-off-by: Greg Kroah-Hartman commit e1e757d75471ab4765fc7b60f0cb8ae8f046dd30 Author: Daniel Vetter Date: Wed Apr 12 17:23:49 2023 +0200 fbcon: Fix error paths in set_con2fb_map commit edf79dd2172233452ff142dcc98b19d955fc8974 upstream. This is a regressoin introduced in b07db3958485 ("fbcon: Ditch error handling for con2fb_release_oldinfo"). I failed to realize what the if (!err) checks. The mentioned commit was dropping the con2fb_release_oldinfo() return value but the if (!err) was also checking whether the con2fb_acquire_newinfo() function call above failed or not. Fix this with an early return statement. Note that there's still a difference compared to the orginal state of the code, the below lines are now also skipped on error: if (!search_fb_in_map(info_idx)) info_idx = newidx; These are only needed when we've actually thrown out an old fb_info from the console mappings, which only happens later on. Also move the fbcon_add_cursor_work() call into the same if block, it's all protected by console_lock so doesn't matter when we set up the blinking cursor delayed work anyway. This further simplifies the control flow and allows us to ditch the found local variable. v2: Clarify commit message (Javier) Signed-off-by: Daniel Vetter Reviewed-by: Javier Martinez Canillas Acked-by: Helge Deller Tested-by: Xingyuan Mo Fixes: b07db3958485 ("fbcon: Ditch error handling for con2fb_release_oldinfo") Cc: Thomas Zimmermann Cc: Sam Ravnborg Cc: Xingyuan Mo Cc: Thomas Zimmermann Cc: Helge Deller Cc: # v5.19+ Signed-off-by: Greg Kroah-Hartman commit 0cc6fdf79bb0ad15e3f9e4a08db0ba200da04dee Author: Reiji Watanabe Date: Tue Mar 28 19:39:44 2023 -0700 KVM: arm64: PMU: Restore the guest's EL0 event counting after migration commit f9ea835e99bc8d049bf2a3ec8fa5a7cb4fcade23 upstream. Currently, with VHE, KVM enables the EL0 event counting for the guest on vcpu_load() or KVM enables it as a part of the PMU register emulation process, when needed. However, in the migration case (with VHE), the same handling is lacking, as vPMU register values that were restored by userspace haven't been propagated yet (the PMU events haven't been created) at the vcpu load-time on the first KVM_RUN (kvm_vcpu_pmu_restore_guest() called from vcpu_load() on the first KVM_RUN won't do anything as events_{guest,host} of kvm_pmu_events are still zero). So, with VHE, enable the guest's EL0 event counting on the first KVM_RUN (after the migration) when needed. More specifically, have kvm_pmu_handle_pmcr() call kvm_vcpu_pmu_restore_guest() so that kvm_pmu_handle_pmcr() on the first KVM_RUN can take care of it. Fixes: d0c94c49792c ("KVM: arm64: Restore PMU configuration on first run") Cc: stable@vger.kernel.org Reviewed-by: Marc Zyngier Signed-off-by: Reiji Watanabe Link: https://lore.kernel.org/r/20230329023944.2488484-1-reijiw@google.com Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 0e7d87616bda31ca4e6304bdebb6ca1beebf22d9 Author: Christophe Kerello Date: Tue Mar 28 17:58:19 2023 +0200 mtd: rawnand: stm32_fmc2: use timings.mode instead of checking tRC_min commit ddbb664b6ab8de7dffa388ae0c88cd18616494e5 upstream. Use timings.mode value instead of checking tRC_min timing for EDO mode support. Signed-off-by: Christophe Kerello Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver") Cc: stable@vger.kernel.org #v5.10+ Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20230328155819.225521-3-christophe.kerello@foss.st.com Signed-off-by: Greg Kroah-Hartman commit caad39579010d17a78f8d68cd8f7c631acabfc35 Author: Christophe Kerello Date: Tue Mar 28 17:58:18 2023 +0200 mtd: rawnand: stm32_fmc2: remove unsupported EDO mode commit f71e0e329c152c7f11ddfd97ffc62aba152fad3f upstream. Remove the EDO mode support from as the FMC2 controller does not support the feature. Signed-off-by: Christophe Kerello Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver") Cc: stable@vger.kernel.org #v5.4+ Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20230328155819.225521-2-christophe.kerello@foss.st.com Signed-off-by: Greg Kroah-Hartman commit adcb8f32b244afc9890e73df6e9d9059e7e99dc2 Author: Arseniy Krasnov Date: Wed Mar 29 10:47:26 2023 +0300 mtd: rawnand: meson: fix bitmask for length in command word commit 93942b70461574ca7fc3d91494ca89b16a4c64c7 upstream. Valid mask is 0x3FFF, without this patch the following problems were found: 1) [ 0.938914] Could not find a valid ONFI parameter page, trying bit-wise majority to recover it [ 0.947384] ONFI parameter recovery failed, aborting 2) Read with disabled ECC mode was broken. Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Cc: Signed-off-by: Arseniy Krasnov Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/3794ffbf-dfea-e96f-1f97-fe235b005e19@sberdevices.ru Signed-off-by: Greg Kroah-Hartman commit 928cdec4944071764a198f2b1284d58b2ed23ad0 Author: Bang Li Date: Wed Mar 29 00:30:12 2023 +0800 mtdblock: tolerate corrected bit-flips commit 0c3089601f064d80b3838eceb711fcac04bceaad upstream. mtd_read() may return -EUCLEAN in case of corrected bit-flips.This particular condition should not be treated like an error. Signed-off-by: Bang Li Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") Cc: # v3.7 Acked-by: Richard Weinberger Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20230328163012.4264-1-libang.linuxer@gmail.com Signed-off-by: Greg Kroah-Hartman commit e8afd5221f5de3f0dac2a6f0f625cda9da8f1ae8 Author: Daniel Vetter Date: Tue Apr 4 21:39:34 2023 +0200 fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace commit 6fd33a3333c7916689b8f051a185defe4dd515b0 upstream. This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore") - I failed to realize that nasty userspace could set this. It's not pretty to mix up kernel-internal and userspace uapi flags like this, but since the entire fb_var_screeninfo structure is uapi we'd need to either add a new parameter to the ->fb_set_par callback and fb_set_par() function, which has a _lot_ of users. Or some other fairly ugly side-channel int fb_info. Neither is a pretty prospect. Instead just correct the issue at hand by filtering out this kernel-internal flag in the ioctl handling code. Reviewed-by: Javier Martinez Canillas Acked-by: Maarten Lankhorst Signed-off-by: Daniel Vetter Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore") Cc: Alex Deucher Cc: shlomo@fastmail.com Cc: Michel Dänzer Cc: Noralf Trønnes Cc: Thomas Zimmermann Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: # v5.7+ Cc: Bartlomiej Zolnierkiewicz Cc: Geert Uytterhoeven Cc: Nathan Chancellor Cc: Qiujun Huang Cc: Peter Rosin Cc: linux-fbdev@vger.kernel.org Cc: Helge Deller Cc: Sam Ravnborg Cc: Geert Uytterhoeven Cc: Samuel Thibault Cc: Tetsuo Handa Cc: Shigeru Yoshida Link: https://patchwork.freedesktop.org/patch/msgid/20230404193934.472457-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman commit 60a17be360a55afcc5f0da577a6c25fac5233448 Author: Christoph Hellwig Date: Wed Mar 29 09:13:05 2023 +0900 btrfs: fix fast csum implementation detection commit 68d99ab0e9221ef54506f827576c5a914680eeaf upstream. The BTRFS_FS_CSUM_IMPL_FAST flag is currently set whenever a non-generic crc32c is detected, which is the incorrect check if the file system uses a different checksumming algorithm. Refactor the code to only check this if crc32c is actually used. Note that in an ideal world the information if an algorithm is hardware accelerated or not should be provided by the crypto API instead, but that's left for another day. CC: stable@vger.kernel.org # 5.4.x: c8a5f8ca9a9c: btrfs: print checksum type and implementation at mount time CC: stable@vger.kernel.org # 5.4.x Signed-off-by: Christoph Hellwig Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit cee77e41c6ad3c788325eee9590730cbd7e7bbd9 Author: Christoph Hellwig Date: Tue Mar 28 12:56:13 2023 +0900 btrfs: restore the thread_pool= behavior in remount for the end I/O workqueues commit 40fac6472f22a59f5694496e179988ab4a1dfe07 upstream. Commit d7b9416fe5c5 ("btrfs: remove btrfs_end_io_wq") converted the read and I/O handling from btrfs_workqueues to Linux workqueues, and as part of that lost the code to apply the thread_pool= based max_active limit on remount. Restore it. Fixes: d7b9416fe5c5 ("btrfs: remove btrfs_end_io_wq") CC: stable@vger.kernel.org # 6.0+ Signed-off-by: Christoph Hellwig Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit dba0f922d57408fdbd32b9964fcca1d3f1acc9c2 Author: Luiz Augusto von Dentz Date: Mon Apr 3 14:19:14 2023 -0700 Bluetooth: hci_conn: Fix possible UAF commit 5dc7d23e167e2882ef118456ceccd57873e876d8 upstream. This fixes the following trace: ================================================================== BUG: KASAN: slab-use-after-free in hci_conn_del+0xba/0x3a0 Write of size 8 at addr ffff88800208e9c8 by task iso-tester/31 CPU: 0 PID: 31 Comm: iso-tester Not tainted 6.3.0-rc2-g991aa4a69a47 #4716 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc36 04/01/2014 Call Trace: dump_stack_lvl+0x1d/0x70 print_report+0xce/0x610 ? __virt_addr_valid+0xd4/0x150 ? hci_conn_del+0xba/0x3a0 kasan_report+0xdd/0x110 ? hci_conn_del+0xba/0x3a0 hci_conn_del+0xba/0x3a0 hci_conn_hash_flush+0xf2/0x120 hci_dev_close_sync+0x388/0x920 hci_unregister_dev+0x122/0x260 vhci_release+0x4f/0x90 __fput+0x102/0x430 task_work_run+0xf1/0x160 ? __pfx_task_work_run+0x10/0x10 ? mark_held_locks+0x24/0x90 exit_to_user_mode_prepare+0x170/0x180 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x4e/0x90 entry_SYSCALL_64_after_hwframe+0x70/0xda Fixes: 0f00cd322d22 ("Bluetooth: Free potentially unfreed SCO connection") Link: https://syzkaller.appspot.com/bug?extid=8bb72f86fc823817bc5d Cc: Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit ac9f4bac140f89e996bc97c8989dd1ba324ea39b Author: Archie Pusaka Date: Fri Feb 3 17:30:55 2023 +0800 Bluetooth: Free potentially unfreed SCO connection commit 0f00cd322d22d4441de51aa80bcce5bb6a8cbb44 upstream. It is possible to initiate a SCO connection while deleting the corresponding ACL connection, e.g. in below scenario: (1) < hci setup sync connect command (2) > hci disconn complete event (for the acl connection) (3) > hci command complete event (for(1), failure) When it happens, hci_cs_setup_sync_conn won't be able to obtain the reference to the SCO connection, so it will be stuck and potentially hinder subsequent connections to the same device. This patch prevents that by also deleting the SCO connection if it is still not established when the corresponding ACL connection is deleted. Signed-off-by: Archie Pusaka Reviewed-by: Ying Hsu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 89395943819935875bc225f77264627ce3dd34d8 Author: Sasha Finkelstein Date: Fri Mar 10 11:28:42 2023 +0100 bluetooth: btbcm: Fix logic error in forming the board name. commit b76abe4648c1acc791a207e7c08d1719eb9f4ea8 upstream. This patch fixes an incorrect loop exit condition in code that replaces '/' symbols in the board name. There might also be a memory corruption issue here, but it is unlikely to be a real problem. Cc: Signed-off-by: Sasha Finkelstein Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 248af9feca062a4ca9c3f2ccf67056c8a5eb817f Author: Min Li Date: Sat Mar 4 22:23:30 2023 +0800 Bluetooth: Fix race condition in hidp_session_thread commit c95930abd687fcd1aa040dc4fe90dff947916460 upstream. There is a potential race condition in hidp_session_thread that may lead to use-after-free. For instance, the timer is active while hidp_del_timer is called in hidp_session_thread(). After hidp_session_put, then 'session' will be freed, causing kernel panic when hidp_idle_timeout is running. The solution is to use del_timer_sync instead of del_timer. Here is the call trace: ? hidp_session_probe+0x780/0x780 call_timer_fn+0x2d/0x1e0 __run_timers.part.0+0x569/0x940 hidp_session_probe+0x780/0x780 call_timer_fn+0x1e0/0x1e0 ktime_get+0x5c/0xf0 lapic_next_deadline+0x2c/0x40 clockevents_program_event+0x205/0x320 run_timer_softirq+0xa9/0x1b0 __do_softirq+0x1b9/0x641 __irq_exit_rcu+0xdc/0x190 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0xa1/0xc0 Cc: stable@vger.kernel.org Signed-off-by: Min Li Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit d82a439c3cfdb28aa7e82e2e849c5c4dd9fca284 Author: Luiz Augusto von Dentz Date: Thu Apr 6 09:33:09 2023 -0700 Bluetooth: L2CAP: Fix use-after-free in l2cap_disconnect_{req,rsp} commit a2a9339e1c9deb7e1e079e12e27a0265aea8421a upstream. Similar to commit d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put"), just use l2cap_chan_hold_unless_zero to prevent referencing a channel that is about to be destroyed. Cc: stable@kernel.org Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Min Li Signed-off-by: Greg Kroah-Hartman commit 2f09c9049b7cdd6b4da37b8809ad011f2fdc5fb2 Author: Kai Vehmanen Date: Thu Apr 13 22:11:53 2023 +0300 ALSA: hda/hdmi: disable KAE for Intel DG2 commit 6ab6f98fcdc9d4fbe245aa67de03542deea65322 upstream. Use of keep-alive (KAE) has resulted in loss of audio on some A750/770 cards as the transition from keep-alive to stream playback is not working as expected. As there is limited benefit of the new KAE mode on discrete cards, revert back to older silent-stream implementation on these systems. Cc: stable@vger.kernel.org Fixes: 15175a4f2bbb ("ALSA: hda/hdmi: add keep-alive support for ADL-P and DG2") Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8307 Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20230413191153.3692049-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ae1eaba8369561ac29320e0f4c331ec8701e81e8 Author: Oswald Buddenhagen Date: Wed Apr 5 22:12:20 2023 +0200 ALSA: hda/sigmatel: fix S/PDIF out on Intel D*45* motherboards commit f342ac00da1064eb4f94b1f4bcacbdfea955797a upstream. The BIOS botches this one completely - it says the 2nd S/PDIF output is used, while in fact it's the 1st one. This is tested on DP45SG, but I'm assuming it's valid for the other boards in the series as well. Also add some comments regarding the pins. FWIW, the codec is apparently still sold by Tempo Semiconductor, Inc., where one can download the documentation. Signed-off-by: Oswald Buddenhagen Cc: Link: https://lore.kernel.org/r/20230405201220.2197826-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a4b56afa299f63c56b8c0cdb4f50aa33634dc277 Author: Oswald Buddenhagen Date: Wed Apr 5 22:12:20 2023 +0200 ALSA: emu10k1: don't create old pass-through playback device on Audigy commit 8dd13214a810c695044aa168c0ddba1a9c433e4f upstream. It could have never worked, as snd_emu10k1_fx8010_playback_prepare() and snd_emu10k1_fx8010_playback_hw_free() assume the emu10k1 offset for the ETRAM, and the default DSP code includes no handler for it. It also wouldn't make a lot of sense to make it work, as Audigy has an own, much simpler, pass-through mechanism. So just skip creation of the device. Signed-off-by: Oswald Buddenhagen Cc: Link: https://lore.kernel.org/r/20230405201220.2197938-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 60abed5d86c589404b1c493256e7112cf6c2fd25 Author: Xu Biang Date: Thu Apr 6 06:28:01 2023 -0700 ALSA: firewire-tascam: add missing unwind goto in snd_tscm_stream_start_duplex() commit fb4a624f88f658c7b7ae124452bd42eaa8ac7168 upstream. Smatch Warns: sound/firewire/tascam/tascam-stream.c:493 snd_tscm_stream_start_duplex() warn: missing unwind goto? The direct return will cause the stream list of "&tscm->domain" unemptied and the session in "tscm" unfinished if amdtp_domain_start() returns with an error. Fix this by changing the direct return to a goto which will empty the stream list of "&tscm->domain" and finish the session in "tscm". The snd_tscm_stream_start_duplex() function is called in the prepare callback of PCM. According to "ALSA Kernel API Documentation", the prepare callback of PCM will be called many times at each setup. So, if the "&d->streams" list is not emptied, when the prepare callback is called next time, snd_tscm_stream_start_duplex() will receive -EBUSY from amdtp_domain_add_stream() that tries to add an existing stream to the domain. The error handling code after the "error" label will be executed in this case, and the "&d->streams" list will be emptied. So not emptying the "&d->streams" list will not cause an issue. But it is more efficient and readable to empty it on the first error by changing the direct return to a goto statement. The session in "tscm" has been begun before amdtp_domain_start(), so it needs to be finished when amdtp_domain_start() fails. Fixes: c281d46a51e3 ("ALSA: firewire-tascam: support AMDTP domain") Signed-off-by: Xu Biang Reviewed-by: Dan Carpenter Acked-by: Takashi Sakamoto Cc: Link: https://lore.kernel.org/r/20230406132801.105108-1-xubiang@hust.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 886f7b69e59cf46e43c388abece0174463a0229c Author: Stefan Binding Date: Wed Apr 12 17:05:31 2023 +0100 ALSA: hda/realtek: Add quirks for Lenovo Z13/Z16 Gen2 commit 8eda19cd59cedbfe4ec11aea4bcecabe4c98e9e4 upstream. These Lenovo laptops use Realtek HDA codec combined with 2xCS35L41 Amplifiers using I2C with External Boost. Signed-off-by: Stefan Binding Cc: Link: https://lore.kernel.org/r/20230412160531.182007-1-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6b683905134ad05e2f4a7adfa20ae7248883e775 Author: Pierre-Louis Bossart Date: Thu Apr 6 10:27:25 2023 -0500 ALSA: hda: patch_realtek: add quirk for Asus N7601ZM commit e959f2beec8e655dba79c5a7111beedae5e757e0 upstream. Add pins and verbs needed to enable speakers and jack. The pins and verbs configurations were identified by snooping the Windows driver commands, with a nice write-up here: https://brakkee.org/site/2023/02/07/fixing-sound-on-the-asus-n7601zm/ Reported-by: Erik Brakkee Link: https://github.com/thesofproject/linux/issues/4176 Tested-by: Erik Brakkee Signed-off-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Cc: Link: https://lore.kernel.org/r/20230406152725.15191-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 81b1feaf1bcedac225d8756775500d3da3d4f02a Author: Oswald Buddenhagen Date: Wed Apr 5 22:12:19 2023 +0200 ALSA: i2c/cs8427: fix iec958 mixer control deactivation commit e98e7a82bca2b6dce3e03719cff800ec913f9af7 upstream. snd_cs8427_iec958_active() would always delete SNDRV_CTL_ELEM_ACCESS_INACTIVE, even though the function has an argument `active`. Signed-off-by: Oswald Buddenhagen Cc: Link: https://lore.kernel.org/r/20230405201219.2197811-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b9496a3c14f4e61d2962f82f97870118bc3f5276 Author: Oswald Buddenhagen Date: Wed Apr 5 22:12:19 2023 +0200 ALSA: hda/sigmatel: add pin overrides for Intel DP45SG motherboard commit c17f8fd31700392b1bb9e7b66924333568cb3700 upstream. Like the other boards from the D*45* series, this one sets up the outputs not quite correctly. Signed-off-by: Oswald Buddenhagen Cc: Link: https://lore.kernel.org/r/20230405201220.2197826-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 85f211f797a89fee40a3ae345b699cae9f0f7f32 Author: Oswald Buddenhagen Date: Wed Apr 5 22:12:20 2023 +0200 ALSA: emu10k1: fix capture interrupt handler unlinking commit b09c551c77c7e01dc6e4f3c8bf06b5ffa7b06db5 upstream. Due to two copy/pastos, closing the MIC or EFX capture device would make a running ADC capture hang due to unsetting its interrupt handler. In principle, this would have also allowed dereferencing dangling pointers, but we're actually rather thorough at disabling and flushing the ints. While it may sound like one, this actually wasn't a hypothetical bug: PortAudio will open a capture stream at startup (and close it right away) even if not asked to. If the first device is busy, it will just proceed with the next one ... thus killing a concurrent capture. Signed-off-by: Oswald Buddenhagen Cc: Link: https://lore.kernel.org/r/20230405201220.2197923-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c7ed73b767bcc27b39e79f6bcdb7bddd1f9a949a Author: Ville Syrjälä Date: Mon Mar 20 11:54:36 2023 +0200 drm/i915: Workaround ICL CSC_MODE sticky arming commit 4d4e766f8b7dbdefa7a78e91eb9c7a29d0d818b8 upstream. Unlike SKL/GLK the ICL CSC unit suffers from a new issue where CSC_MODE arming is sticky. That is, once armed it remains armed causing the CSC coeff/offset registers to become effectively self-arming. CSC coeff/offset registers writes no longer disarm the CSC, but fortunately register read still do. So we can use that to disarm the CSC unit once the registers for the current frame have been latched. This avoid s the self-arming behaviour from persisting into the next frame's .color_commit_noarm() call. Cc: #v5.19+ Cc: Manasi Navare Cc: Drew Davenport Cc: Imre Deak Cc: Jouni Högander Fixes: d13dde449580 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20230320095438.17328-5-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak (cherry picked from commit 92736f1b452bbb8a66bdb5b1d263ad00e04dd3b8) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 3715df26444e9c3ba922d347e87c7caec422a6f2 Author: Wayne Lin Date: Fri Feb 17 13:26:56 2023 +0800 drm/amd/display: Pass the right info to drm_dp_remove_payload commit b8ca445f550a9a079134f836466ddda3bfad6108 upstream. [Why & How] drm_dp_remove_payload() interface was changed. Correct amdgpu dm code to pass the right parameter to the drm helper function. Reviewed-by: Jerry Zuo Acked-by: Qingqing Zhuo Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry-picked from b8ca445f550a9a079134f836466ddda3bfad6108) [Hand modified due to missing f0127cb11299df80df45583b216e13f27c408545 which failed to apply due to missing 94dfeaa46925bb6b4d43645bbb6234e846dec257] Reported-and-tested-by: Veronika Schwan Fixes: d7b5638bd337 ("drm/amd/display: Take FEC Overhead into Timeslot Calculation") Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman commit 75facd07cc0c41ca0c8de649c7bcf439e1de2e1b Author: Kornel Dulęba Date: Tue Apr 11 13:49:32 2023 +0000 Revert "pinctrl: amd: Disable and mask interrupts on resume" commit 534e465845ebfb4a97eb5459d3931a0b35e3b9a5 upstream. This reverts commit b26cd9325be4c1fcd331b77f10acb627c560d4d7. This patch introduces a regression on Lenovo Z13, which can't wake from the lid with it applied; and some unspecified AMD based Dell platforms are unable to wake from hitting the power button Signed-off-by: Kornel Dulęba Reviewed-by: Mario Limonciello Link: https://lore.kernel.org/r/20230411134932.292287-1-korneld@chromium.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman