commit f00712e27083550be3031099b7697925533a6e01 Author: Greg Kroah-Hartman Date: Thu Nov 25 09:49:08 2021 +0100 Linux 5.15.5 Link: https://lore.kernel.org/r/20211124115718.776172708@linuxfoundation.org Tested-by: Fox Chen Tested-by: Ronald Warsow Tested-by: Salvatore Bonaccorso Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Rudi Heitbaum Signed-off-by: Greg Kroah-Hartman commit e6818963e0b093387898898b3bb20377d21ddbbb Author: Pierre-Louis Bossart Date: Fri Sep 24 14:24:14 2021 -0500 ALSA: hda: hdac_stream: fix potential locking issue in snd_hdac_stream_assign() commit 1465d06a6d8580e73ae65f8590392df58c5ed2fd upstream. The fields 'opened', 'running', 'assigned_key' are all protected by a spinlock, but the spinlock is not taken when looking for a stream. This can result in a possible race between assign() and release(). Fix by taking the spinlock before walking through the bus stream list. Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210924192417.169243-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Cc: Scott Bruce Signed-off-by: Greg Kroah-Hartman commit 01085644673f73b47b5c3dae162a542b98e15c90 Author: Pierre-Louis Bossart Date: Fri Sep 24 14:24:16 2021 -0500 ALSA: hda: hdac_ext_stream: fix potential locking issues commit 868ddfcef31ff93ea8961b2e81ea7fe12f6f144b upstream. The code for hdac_ext_stream seems inherited from hdac_stream, and similar locking issues are present: the use of the bus->reg_lock spinlock is inconsistent, with only writes to specific fields being protected. Apply similar fix as in hdac_stream by protecting all accesses to 'link_locked' and 'decoupled' fields, with a new helper snd_hdac_ext_stream_decouple_locked() added to simplify code changes. Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210924192417.169243-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit faed25ba98db9e610260d429eced20ca352b3db2 Author: Randy Dunlap Date: Fri Sep 10 00:19:21 2021 -0700 x86/Kconfig: Fix an unused variable error in dell-smm-hwmon commit ef775a0e36c6a81c5b07cb228c02f967133fe768 upstream. When CONFIG_PROC_FS is not set, there is a build warning (turned into an error): ../drivers/hwmon/dell-smm-hwmon.c: In function 'i8k_init_procfs': ../drivers/hwmon/dell-smm-hwmon.c:624:24: error: unused variable 'data' [-Werror=unused-variable] struct dell_smm_data *data = dev_get_drvdata(dev); Make I8K depend on PROC_FS and HWMON (instead of selecting HWMON -- it is strongly preferred to not select entire subsystems). Build tested in all possible combinations of SENSORS_DELL_SMM, I8K, and PROC_FS. Fixes: 039ae58503f3 ("hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k") Reported-by: Arnd Bergmann Signed-off-by: Randy Dunlap Signed-off-by: Borislav Petkov Reviewed-by: Arnd Bergmann Acked-by: Guenter Roeck Acked-by: Pali Rohár Link: https://lkml.kernel.org/r/20210910071921.16777-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman commit fa5f8606353fd09af052d609e7988ee26fc1f2d5 Author: Eric Dumazet Date: Mon Nov 1 17:45:55 2021 -0700 net: add and use skb_unclone_keeptruesize() helper commit c4777efa751d293e369aec464ce6875e957be255 upstream. While commit 097b9146c0e2 ("net: fix up truesize of cloned skb in skb_prepare_for_shift()") fixed immediate issues found when KFENCE was enabled/tested, there are still similar issues, when tcp_trim_head() hits KFENCE while the master skb is cloned. This happens under heavy networking TX workloads, when the TX completion might be delayed after incoming ACK. This patch fixes the WARNING in sk_stream_kill_queues when sk->sk_mem_queued/sk->sk_forward_alloc are not zero. Fixes: d3fb45f370d9 ("mm, kfence: insert KFENCE hooks for SLAB") Signed-off-by: Eric Dumazet Acked-by: Marco Elver Link: https://lore.kernel.org/r/20211102004555.1359210-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f14c857331548f3b33000db8028c58d8c313f777 Author: Josef Bacik Date: Thu Oct 14 13:11:01 2021 -0400 btrfs: update device path inode time instead of bd_inode commit 54fde91f52f515e0b1514f0f0fa146e87a672227 upstream. Christoph pointed out that I'm updating bdev->bd_inode for the device time when we remove block devices from a btrfs file system, however this isn't actually exposed to anything. The inode we want to update is the one that's associated with the path to the device, usually on devtmpfs, so that blkid notices the difference. We still don't want to do the blkdev_open, so use kern_path() to get the path to the given device and do the update time on that inode. Fixes: 8f96a5bfa150 ("btrfs: update the bdev time directly when closing") Reported-by: Christoph Hellwig Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 22efa065ff016fc1ed3d3c507770b46526437918 Author: Josef Bacik Date: Thu Oct 14 13:11:00 2021 -0400 fs: export an inode_update_time helper commit e60feb445fce9e51c1558a6aa7faf9dd5ded533b upstream. If you already have an inode and need to update the time on the inode there is no way to do this properly. Export this helper to allow file systems to update time on the inode so the appropriate handler is called, either ->update_time or generic_update_time. Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 148ed0e75c5e7e5364ff9c4fd1cbf18b6256af5e Author: Leon Romanovsky Date: Thu Sep 23 21:12:52 2021 +0300 ice: Delete always true check of PF pointer commit 2ff04286a9569675948f39cec2c6ad47c3584633 upstream. PF pointer is always valid when PCI core calls its .shutdown() and .remove() callbacks. There is no need to check it again. Fixes: 837f08fdecbe ("ice: Add basic driver framework for Intel(R) E800 Series") Signed-off-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0190a2f88823cb2399140e36c26563faae3ae0ae Author: Brett Creeley Date: Fri Feb 26 13:19:23 2021 -0800 ice: Fix VF true promiscuous mode commit 1a8c7778bcde5981463a5b9f9b2caa44a327ff93 upstream. When a VF requests promiscuous mode and it's trusted and true promiscuous mode is enabled the PF driver attempts to enable unicast and/or multicast promiscuous mode filters based on the request. This is fine, but there are a couple issues with the current code. [1] The define to configure the unicast promiscuous mode mask also includes bits to configure the multicast promiscuous mode mask, which causes multicast to be set/cleared unintentionally. [2] All 4 cases for enable/disable unicast/multicast mode are not handled in the promiscuous mode message handler, which causes unexpected results regarding the current promiscuous mode settings. To fix [1] make sure any promiscuous mask defines include the correct bits for each of the promiscuous modes. To fix [2] make sure that all 4 cases are handled since there are 2 bits (FLAG_VF_UNICAST_PROMISC and FLAG_VF_MULTICAST_PROMISC) that can be either set or cleared. Also, since either unicast and/or multicast promiscuous configuration can fail, introduce two separate error values to handle each of these cases. Fixes: 01b5e89aab49 ("ice: Add VF promiscuous support") Signed-off-by: Brett Creeley Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit d87edd01ce22397b46703b6cc376206118eb1a20 Author: Uwe Kleine-König Date: Mon Oct 18 22:40:28 2021 +0200 usb: max-3421: Use driver data instead of maintaining a list of bound devices commit fc153aba3ef371d0d76eb88230ed4e0dee5b38f2 upstream. Instead of maintaining a single-linked list of devices that must be searched linearly in .remove() just use spi_set_drvdata() to remember the link between the spi device and the driver struct. Then the global list and the next member can be dropped. This simplifies the driver, reduces the memory footprint and the time to search the list. Also it makes obvious that there is always a corresponding driver struct for a given device in .remove(), so the error path for !max3421_hcd can be dropped, too. As a side effect this fixes a data inconsistency when .probe() races with itself for a second max3421 device in manipulating max3421_hcd_list. A similar race is fixed in .remove(), too. Fixes: 2d53139f3162 ("Add support for using a MAX3421E chip as a host driver.") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20211018204028.2914597-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman commit 11a8768144ea75b6672832b44d50961f5097456c Author: Kuninori Morimoto Date: Mon Nov 8 13:22:55 2021 +0900 ASoC: rsnd: fixup DMAEngine API commit 2ce1b21cb3326e12af3c72c47e1d294b19d73947 upstream. commit d5bb69dc54ec1 ("ASoC: sh: rcar: dma: : use proper DMAENGINE API for termination") updated DMAEngine API _all() to _sync(), but it should be _async(). _all() and _async() are almost same, the difference is only return error code. _sync() will call dmaengine_synchronize() and will be kernel panic. This patch is needed for v5.15 or later. [ 27.293264] BUG: scheduling while atomic: irq/130-ec70000/131/0x00000003 [ 27.300084] 2 locks held by irq/130-ec70000/131: [ 27.304743] #0: ffff0004c274d908 (&group->lock){....}-{2:2}, at: _snd_pcm_stream_lock_irqsave+0x48/0x54 [ 27.314344] #1: ffff0004c1788c60 (&priv->lock#2){....}-{2:2}, at: rsnd_soc_dai_trigger+0x70/0x7bc [ 27.323409] irq event stamp: 206 [ 27.326664] hardirqs last enabled at (205): [] _raw_spin_unlock_irq+0x50/0xa0 [ 27.335529] hardirqs last disabled at (206): [] _raw_spin_lock_irqsave+0xc4/0xd0 [ 27.344564] softirqs last enabled at (0): [] copy_process+0x644/0x1b10 [ 27.352819] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 27.359142] CPU: 0 PID: 131 Comm: irq/130-ec70000 Not tainted 5.14.0-rc1+ #918 [ 27.366429] Hardware name: Renesas H3ULCB Kingfisher board based on r8a77950 (DT) [ 27.373975] Call trace: [ 27.376442] dump_backtrace+0x0/0x1b4 [ 27.380141] show_stack+0x24/0x30 [ 27.383488] dump_stack_lvl+0x8c/0xb8 [ 27.387184] dump_stack+0x18/0x34 [ 27.390528] __schedule_bug+0x8c/0x9c [ 27.394224] __schedule+0x790/0x8dc [ 27.397746] schedule+0x7c/0x110 [ 27.401003] synchronize_irq+0x94/0xd0 [ 27.404786] rcar_dmac_device_synchronize+0x20/0x2c [ 27.409710] rsnd_dmaen_stop+0x50/0x64 [ 27.413495] rsnd_soc_dai_trigger+0x554/0x7bc [ 27.417890] snd_soc_pcm_dai_trigger+0xe8/0x264 Cc: Fixes: commit d5bb69dc54ec1 ("ASoC: sh: rcar: dma: : use proper DMAENGINE API for termination") Link: https://lore.kernel.org/r/TY2PR01MB3692889E1A7476C4322CC296D8AE9@TY2PR01MB3692.jpnprd01.prod.outlook.com Reported-by: Yoshihiro Shimoda Acked-by: Wolfram Sang Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87mtmfz36o.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 330651b2c0d7643ba52c80eb6a33dd2cc06c542c Author: Takashi Iwai Date: Fri Nov 5 10:09:25 2021 +0100 ASoC: DAPM: Cover regression by kctl change notification fix commit 827b0913a9d9d07a0c3e559dbb20ca4d6d285a54 upstream. The recent fix for DAPM to correct the kctl change notification by the commit 5af82c81b2c4 ("ASoC: DAPM: Fix missing kctl change notifications") caused other regressions since it changed the behavior of snd_soc_dapm_set_pin() that is called from several API functions. Formerly it returned always 0 for success, but now it returns 0 or 1. This patch addresses it, restoring the old behavior of snd_soc_dapm_set_pin() while keeping the fix in snd_soc_dapm_put_pin_switch(). Fixes: 5af82c81b2c4 ("ASoC: DAPM: Fix missing kctl change notifications") Reported-by: Yu-Hsuan Hsu Cc: Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20211105090925.20575-1-tiwai@suse.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 83c8ab8503adf56bf68dafc7a382f4946c87da79 Author: Ondrej Mosnacek Date: Fri Nov 19 14:45:20 2021 +0100 selinux: fix NULL-pointer dereference when hashtab allocation fails commit dc27f3c5d10c58069672215787a96b4fae01818b upstream. When the hash table slot array allocation fails in hashtab_init(), h->size is left initialized with a non-zero value, but the h->htable pointer is NULL. This may then cause a NULL pointer dereference, since the policydb code relies on the assumption that even after a failed hashtab_init(), hashtab_map() and hashtab_destroy() can be safely called on it. Yet, these detect an empty hashtab only by looking at the size. Fix this by making sure that hashtab_init() always leaves behind a valid empty hashtab when the allocation fails. Cc: stable@vger.kernel.org Fixes: 03414a49ad5f ("selinux: do not allocate hashtabs dynamically") Signed-off-by: Ondrej Mosnacek Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 439b99314b635b40f2e0622eabe62d7055bb409b Author: Dmitrii Banshchikov Date: Sat Nov 13 18:22:26 2021 +0400 bpf: Forbid bpf_ktime_get_coarse_ns and bpf_timer_* in tracing progs commit 5e0bc3082e2e403ac0753e099c2b01446bb35578 upstream. Use of bpf_ktime_get_coarse_ns() and bpf_timer_* helpers in tracing progs may result in locking issues. bpf_ktime_get_coarse_ns() uses ktime_get_coarse_ns() time accessor that isn't safe for any context: ====================================================== WARNING: possible circular locking dependency detected 5.15.0-syzkaller #0 Not tainted ------------------------------------------------------ syz-executor.4/14877 is trying to acquire lock: ffffffff8cb30008 (tk_core.seq.seqcount){----}-{0:0}, at: ktime_get_coarse_ts64+0x25/0x110 kernel/time/timekeeping.c:2255 but task is already holding lock: ffffffff90dbf200 (&obj_hash[i].lock){-.-.}-{2:2}, at: debug_object_deactivate+0x61/0x400 lib/debugobjects.c:735 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&obj_hash[i].lock){-.-.}-{2:2}: lock_acquire+0x19f/0x4d0 kernel/locking/lockdep.c:5625 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd1/0x120 kernel/locking/spinlock.c:162 __debug_object_init+0xd9/0x1860 lib/debugobjects.c:569 debug_hrtimer_init kernel/time/hrtimer.c:414 [inline] debug_init kernel/time/hrtimer.c:468 [inline] hrtimer_init+0x20/0x40 kernel/time/hrtimer.c:1592 ntp_init_cmos_sync kernel/time/ntp.c:676 [inline] ntp_init+0xa1/0xad kernel/time/ntp.c:1095 timekeeping_init+0x512/0x6bf kernel/time/timekeeping.c:1639 start_kernel+0x267/0x56e init/main.c:1030 secondary_startup_64_no_verify+0xb1/0xbb -> #0 (tk_core.seq.seqcount){----}-{0:0}: check_prev_add kernel/locking/lockdep.c:3051 [inline] check_prevs_add kernel/locking/lockdep.c:3174 [inline] validate_chain+0x1dfb/0x8240 kernel/locking/lockdep.c:3789 __lock_acquire+0x1382/0x2b00 kernel/locking/lockdep.c:5015 lock_acquire+0x19f/0x4d0 kernel/locking/lockdep.c:5625 seqcount_lockdep_reader_access+0xfe/0x230 include/linux/seqlock.h:103 ktime_get_coarse_ts64+0x25/0x110 kernel/time/timekeeping.c:2255 ktime_get_coarse include/linux/timekeeping.h:120 [inline] ktime_get_coarse_ns include/linux/timekeeping.h:126 [inline] ____bpf_ktime_get_coarse_ns kernel/bpf/helpers.c:173 [inline] bpf_ktime_get_coarse_ns+0x7e/0x130 kernel/bpf/helpers.c:171 bpf_prog_a99735ebafdda2f1+0x10/0xb50 bpf_dispatcher_nop_func include/linux/bpf.h:721 [inline] __bpf_prog_run include/linux/filter.h:626 [inline] bpf_prog_run include/linux/filter.h:633 [inline] BPF_PROG_RUN_ARRAY include/linux/bpf.h:1294 [inline] trace_call_bpf+0x2cf/0x5d0 kernel/trace/bpf_trace.c:127 perf_trace_run_bpf_submit+0x7b/0x1d0 kernel/events/core.c:9708 perf_trace_lock+0x37c/0x440 include/trace/events/lock.h:39 trace_lock_release+0x128/0x150 include/trace/events/lock.h:58 lock_release+0x82/0x810 kernel/locking/lockdep.c:5636 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:149 [inline] _raw_spin_unlock_irqrestore+0x75/0x130 kernel/locking/spinlock.c:194 debug_hrtimer_deactivate kernel/time/hrtimer.c:425 [inline] debug_deactivate kernel/time/hrtimer.c:481 [inline] __run_hrtimer kernel/time/hrtimer.c:1653 [inline] __hrtimer_run_queues+0x2f9/0xa60 kernel/time/hrtimer.c:1749 hrtimer_interrupt+0x3b3/0x1040 kernel/time/hrtimer.c:1811 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1086 [inline] __sysvec_apic_timer_interrupt+0xf9/0x270 arch/x86/kernel/apic/apic.c:1103 sysvec_apic_timer_interrupt+0x8c/0xb0 arch/x86/kernel/apic/apic.c:1097 asm_sysvec_apic_timer_interrupt+0x12/0x20 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] _raw_spin_unlock_irqrestore+0xd4/0x130 kernel/locking/spinlock.c:194 try_to_wake_up+0x702/0xd20 kernel/sched/core.c:4118 wake_up_process kernel/sched/core.c:4200 [inline] wake_up_q+0x9a/0xf0 kernel/sched/core.c:953 futex_wake+0x50f/0x5b0 kernel/futex/waitwake.c:184 do_futex+0x367/0x560 kernel/futex/syscalls.c:127 __do_sys_futex kernel/futex/syscalls.c:199 [inline] __se_sys_futex+0x401/0x4b0 kernel/futex/syscalls.c:180 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae There is a possible deadlock with bpf_timer_* set of helpers: hrtimer_start() lock_base(); trace_hrtimer...() perf_event() bpf_run() bpf_timer_start() hrtimer_start() lock_base() <- DEADLOCK Forbid use of bpf_ktime_get_coarse_ns() and bpf_timer_* helpers in BPF_PROG_TYPE_KPROBE, BPF_PROG_TYPE_TRACEPOINT, BPF_PROG_TYPE_PERF_EVENT and BPF_PROG_TYPE_RAW_TRACEPOINT prog types. Fixes: d05512618056 ("bpf: Add bpf_ktime_get_coarse_ns helper") Fixes: b00628b1c7d5 ("bpf: Introduce bpf timers.") Reported-by: syzbot+43fd005b5a1b4d10781e@syzkaller.appspotmail.com Signed-off-by: Dmitrii Banshchikov Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211113142227.566439-2-me@ubique.spb.ru Signed-off-by: Greg Kroah-Hartman commit 354313514e972f7bb67cedd7bc19218ae851a904 Author: Leon Romanovsky Date: Sun Nov 7 08:40:47 2021 +0200 RDMA/netlink: Add __maybe_unused to static inline in C file commit 83dde7498fefeb920b1def317421262317d178e5 upstream. Like other commits in the tree add __maybe_unused to a static inline in a C file because some clang compilers will complain about unused code: >> drivers/infiniband/core/nldev.c:2543:1: warning: unused function '__chk_RDMA_NL_NLDEV' MODULE_ALIAS_RDMA_NETLINK(RDMA_NL_NLDEV, 5); ^ Fixes: e3bf14bdc17a ("rdma: Autoload netlink client modules") Link: https://lore.kernel.org/r/4a8101919b765e01d7fde6f27fd572c958deeb4a.1636267207.git.leonro@nvidia.com Reported-by: kernel test robot Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 556d59293a2a94863797a7a50890992aa5e8db16 Author: Nadav Amit Date: Sun Nov 21 12:40:07 2021 -0800 hugetlbfs: flush TLBs correctly after huge_pmd_unshare commit a4a118f2eead1d6c49e00765de89878288d4b890 upstream. When __unmap_hugepage_range() calls to huge_pmd_unshare() succeed, a TLB flush is missing. This TLB flush must be performed before releasing the i_mmap_rwsem, in order to prevent an unshared PMDs page from being released and reused before the TLB flush took place. Arguably, a comprehensive solution would use mmu_gather interface to batch the TLB flushes and the PMDs page release, however it is not an easy solution: (1) try_to_unmap_one() and try_to_migrate_one() also call huge_pmd_unshare() and they cannot use the mmu_gather interface; and (2) deferring the release of the page reference for the PMDs page until after i_mmap_rwsem is dropeed can confuse huge_pmd_unshare() into thinking PMDs are shared when they are not. Fix __unmap_hugepage_range() by adding the missing TLB flush, and forcing a flush when unshare is successful. Fixes: 24669e58477e ("hugetlb: use mmu_gather instead of a temporary linked list for accumulating pages)" # 3.6 Signed-off-by: Nadav Amit Reviewed-by: Mike Kravetz Cc: Aneesh Kumar K.V Cc: KAMEZAWA Hiroyuki Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 686bf792032a1361b7a0a83688779786f0c86a17 Author: Eric W. Biederman Date: Thu Nov 18 14:23:21 2021 -0600 signal: Replace force_fatal_sig with force_exit_sig when in doubt commit fcb116bc43c8c37c052530ead79872f8b2615711 upstream. Recently to prevent issues with SECCOMP_RET_KILL and similar signals being changed before they are delivered SA_IMMUTABLE was added. Unfortunately this broke debuggers[1][2] which reasonably expect to be able to trap synchronous SIGTRAP and SIGSEGV even when the target process is not configured to handle those signals. Add force_exit_sig and use it instead of force_fatal_sig where historically the code has directly called do_exit. This has the implementation benefits of going through the signal exit path (including generating core dumps) without the danger of allowing userspace to ignore or change these signals. This avoids userspace regressions as older kernels exited with do_exit which debuggers also can not intercept. In the future is should be possible to improve the quality of implementation of the kernel by changing some of these force_exit_sig calls to force_fatal_sig. That can be done where it matters on a case-by-case basis with careful analysis. Reported-by: Kyle Huey Reported-by: kernel test robot [1] https://lkml.kernel.org/r/CAP045AoMY4xf8aC_4QU_-j7obuEPYgTcnQQP3Yxk=2X90jtpjw@mail.gmail.com [2] https://lkml.kernel.org/r/20211117150258.GB5403@xsang-OptiPlex-9020 Fixes: 00b06da29cf9 ("signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed") Fixes: a3616a3c0272 ("signal/m68k: Use force_sigsegv(SIGSEGV) in fpsp040_die") Fixes: 83a1f27ad773 ("signal/powerpc: On swapcontext failure force SIGSEGV") Fixes: 9bc508cf0791 ("signal/s390: Use force_sigsegv in default_trap_handler") Fixes: 086ec444f866 ("signal/sparc32: In setup_rt_frame and setup_fram use force_fatal_sig") Fixes: c317d306d550 ("signal/sparc32: Exit with a fatal signal when try_to_clear_window_buffer fails") Fixes: 695dd0d634df ("signal/x86: In emulate_vsyscall force a signal instead of calling do_exit") Fixes: 1fbd60df8a85 ("signal/vm86_32: Properly send SIGSEGV when the vm86 state cannot be saved.") Fixes: 941edc5bf174 ("exit/syscall_user_dispatch: Send ordinary signals on failure") Link: https://lkml.kernel.org/r/871r3dqfv8.fsf_-_@email.froward.int.ebiederm.org Reviewed-by: Kees Cook Tested-by: Kees Cook Tested-by: Kyle Huey Signed-off-by: "Eric W. Biederman" Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit 7614e046ed489a70f71b90274a1f59ee863f2821 Author: Eric W. Biederman Date: Thu Nov 18 11:11:13 2021 -0600 signal: Don't always set SA_IMMUTABLE for forced signals commit e349d945fac76bddc78ae1cb92a0145b427a87ce upstream. Recently to prevent issues with SECCOMP_RET_KILL and similar signals being changed before they are delivered SA_IMMUTABLE was added. Unfortunately this broke debuggers[1][2] which reasonably expect to be able to trap synchronous SIGTRAP and SIGSEGV even when the target process is not configured to handle those signals. Update force_sig_to_task to support both the case when we can allow the debugger to intercept and possibly ignore the signal and the case when it is not safe to let userspace know about the signal until the process has exited. Suggested-by: Linus Torvalds Reported-by: Kyle Huey Reported-by: kernel test robot Cc: stable@vger.kernel.org [1] https://lkml.kernel.org/r/CAP045AoMY4xf8aC_4QU_-j7obuEPYgTcnQQP3Yxk=2X90jtpjw@mail.gmail.com [2] https://lkml.kernel.org/r/20211117150258.GB5403@xsang-OptiPlex-9020 Fixes: 00b06da29cf9 ("signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed") Link: https://lkml.kernel.org/r/877dd5qfw5.fsf_-_@email.froward.int.ebiederm.org Reviewed-by: Kees Cook Tested-by: Kees Cook Tested-by: Kyle Huey Signed-off-by: "Eric W. Biederman" Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit 02d28b5fdb414ebb885e76aa01f6489a2a3d5843 Author: Eric W. Biederman Date: Mon Oct 25 10:50:57 2021 -0500 signal: Replace force_sigsegv(SIGSEGV) with force_fatal_sig(SIGSEGV) commit e21294a7aaae32c5d7154b187113a04db5852e37 upstream. Now that force_fatal_sig exists it is unnecessary and a bit confusing to use force_sigsegv in cases where the simpler force_fatal_sig is wanted. So change every instance we can to make the code clearer. Acked-by: Geert Uytterhoeven Reviewed-by: Philippe Mathieu-Daudé Link: https://lkml.kernel.org/r/877de7jrev.fsf@disp2133 Signed-off-by: "Eric W. Biederman" Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit 3e61002d05976c312b2fdee741131ecb12263cf4 Author: Eric W. Biederman Date: Wed Oct 20 12:44:03 2021 -0500 signal/x86: In emulate_vsyscall force a signal instead of calling do_exit commit 695dd0d634df8903e5ead8aa08d326f63b23368a upstream. Directly calling do_exit with a signal number has the problem that all of the side effects of the signal don't happen, such as killing all of the threads of a process instead of just the calling thread. So replace do_exit(SIGSYS) with force_fatal_sig(SIGSYS) which causes the signal handling to take it's normal path and work as expected. Cc: Andy Lutomirski Link: https://lkml.kernel.org/r/20211020174406.17889-17-ebiederm@xmission.com Signed-off-by: Eric W. Biederman Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit 3c4d5a38ca93d0bf64489d3222f68e4dba5a84ad Author: Eric W. Biederman Date: Wed Oct 20 12:43:56 2021 -0500 signal/vm86_32: Properly send SIGSEGV when the vm86 state cannot be saved. commit 1fbd60df8a852d9c55de8cd3621899cf4c72a5b7 upstream. Update save_v86_state to always complete all of it's work except possibly some of the copies to userspace even if save_v86_state takes a fault. This ensures that the kernel is always in a sane state, even if userspace has done something silly. When save_v86_state takes a fault update it to force userspace to take a SIGSEGV and terminate the userspace application. As Andy pointed out in review of the first version of this change there are races between sigaction and the application terinating. Now that the code has been modified to always perform all save_v86_state's work (except possibly copying to userspace) those races do not matter from a kernel perspective. Forcing the userspace application to terminate (by resetting it's handler to SIGDFL) is there to keep everything as close to the current behavior as possible while removing the unique (and difficult to maintain) use of do_exit. If this new SIGSEGV happens during handle_signal the next time around the exit_to_user_mode_loop, SIGSEGV will be delivered to userspace. All of the callers of handle_vm86_trap and handle_vm86_fault run the exit_to_user_mode_loop before they return to userspace any signal sent to the current task during their execution will be delivered to the current task before that tasks exits to usermode. Cc: Andy Lutomirski Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: x86@kernel.org Cc: H Peter Anvin v1: https://lkml.kernel.org/r/20211020174406.17889-10-ebiederm@xmission.com Link: https://lkml.kernel.org/r/877de1xcr6.fsf_-_@disp2133 Signed-off-by: Eric W. Biederman Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit 1998d85c83e38a10c8137995d90c506937aaf5cd Author: Eric W. Biederman Date: Wed Oct 20 12:44:02 2021 -0500 signal/sparc32: In setup_rt_frame and setup_fram use force_fatal_sig commit 086ec444f86660e103de8945d0dcae9b67132ac9 upstream. Modify the 32bit version of setup_rt_frame and setup_frame to act similar to the 64bit version of setup_rt_frame and fail with a signal instead of calling do_exit. Replacing do_exit(SIGILL) with force_fatal_signal(SIGILL) ensures that the process will be terminated cleanly when the stack frame is invalid, instead of just killing off a single thread and leaving the process is a weird state. Cc: David Miller Cc: sparclinux@vger.kernel.org Link: https://lkml.kernel.org/r/20211020174406.17889-16-ebiederm@xmission.com Signed-off-by: Eric W. Biederman Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit 905e8609419bdfbc5fd8c3a5f3262e13c0695a59 Author: Eric W. Biederman Date: Wed Oct 20 12:44:01 2021 -0500 signal/sparc32: Exit with a fatal signal when try_to_clear_window_buffer fails commit c317d306d55079525c9610267fdaf3a8a6d2f08b upstream. The function try_to_clear_window_buffer is only called from rtrap_32.c. After it is called the signal pending state is retested, and signals are handled if TIF_SIGPENDING is set. This allows try_to_clear_window_buffer to call force_fatal_signal and then rely on the signal being delivered to kill the process, without any danger of returning to userspace, or otherwise using possible corrupt state on failure. The functional difference between force_fatal_sig and do_exit is that do_exit will only terminate a single thread, and will never trigger a core-dump. A multi-threaded program for which a single thread terminates unexpectedly is hard to reason about. Calling force_fatal_sig does not give userspace a chance to catch the signal, but otherwise is an ordinary fatal signal exit, and it will trigger a coredump of the offending process if core dumps are enabled. Cc: David Miller Cc: sparclinux@vger.kernel.org Link: https://lkml.kernel.org/r/20211020174406.17889-15-ebiederm@xmission.com Signed-off-by: Eric W. Biederman Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit 58484ab427f147cf0d2c1ff912294ee9e001ed2e Author: Eric W. Biederman Date: Wed Oct 20 12:43:57 2021 -0500 signal/s390: Use force_sigsegv in default_trap_handler commit 9bc508cf0791c8e5a37696de1a046d746fcbd9d8 upstream. Reading the history it is unclear why default_trap_handler calls do_exit. It is not even menthioned in the commit where the change happened. My best guess is that because it is unknown why the exception happened it was desired to guarantee the process never returned to userspace. Using do_exit(SIGSEGV) has the problem that it will only terminate one thread of a process, leaving the process in an undefined state. Use force_sigsegv(SIGSEGV) instead which effectively has the same behavior except that is uses the ordinary signal mechanism and terminates all threads of a process and is generally well defined. Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Cc: linux-s390@vger.kernel.org Fixes: ca2ab03237ec ("[PATCH] s390: core changes") History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Reviewed-by: Christian Borntraeger Link: https://lkml.kernel.org/r/20211020174406.17889-11-ebiederm@xmission.com Signed-off-by: Eric W. Biederman Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit c7b7868dba816bfda54d5036ae5bb9365dac5c8a Author: Eric W. Biederman Date: Wed Oct 20 12:43:53 2021 -0500 signal/powerpc: On swapcontext failure force SIGSEGV commit 83a1f27ad773b1d8f0460d3a676114c7651918cc upstream. If the register state may be partial and corrupted instead of calling do_exit, call force_sigsegv(SIGSEGV). Which properly kills the process with SIGSEGV and does not let any more userspace code execute, instead of just killing one thread of the process and potentially confusing everything. Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-dev@lists.ozlabs.org History-tree: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Fixes: 756f1ae8a44e ("PPC32: Rework signal code and add a swapcontext system call.") Fixes: 04879b04bf50 ("[PATCH] ppc64: VMX (Altivec) support & signal32 rework, from Ben Herrenschmidt") Link: https://lkml.kernel.org/r/20211020174406.17889-7-ebiederm@xmission.com Signed-off-by: Eric W. Biederman Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit fe67da49f784f031a6ee5ccb4ca1bc4d33f925b6 Author: Eric W. Biederman Date: Wed Oct 20 12:44:00 2021 -0500 exit/syscall_user_dispatch: Send ordinary signals on failure commit 941edc5bf174b67f94db19817cbeab0a93e0c32a upstream. Use force_fatal_sig instead of calling do_exit directly. This ensures the ordinary signal handling path gets invoked, core dumps as appropriate get created, and for multi-threaded processes all of the threads are terminated not just a single thread. When asked Gabriel Krisman Bertazi said [1]: > ebiederm@xmission.com (Eric W. Biederman) asked: > > > Why does do_syscal_user_dispatch call do_exit(SIGSEGV) and > > do_exit(SIGSYS) instead of force_sig(SIGSEGV) and force_sig(SIGSYS)? > > > > Looking at the code these cases are not expected to happen, so I would > > be surprised if userspace depends on any particular behaviour on the > > failure path so I think we can change this. > > Hi Eric, > > There is not really a good reason, and the use case that originated the > feature doesn't rely on it. > > Unless I'm missing yet another problem and others correct me, I think > it makes sense to change it as you described. > > > Is using do_exit in this way something you copied from seccomp? > > I'm not sure, its been a while, but I think it might be just that. The > first prototype of SUD was implemented as a seccomp mode. If at some point it becomes interesting we could relax "force_fatal_sig(SIGSEGV)" to instead say "force_sig_fault(SIGSEGV, SEGV_MAPERR, sd->selector)". I avoid doing that in this patch to avoid making it possible to catch currently uncatchable signals. Cc: Gabriel Krisman Bertazi Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Andy Lutomirski [1] https://lkml.kernel.org/r/87mtr6gdvi.fsf@collabora.com Link: https://lkml.kernel.org/r/20211020174406.17889-14-ebiederm@xmission.com Signed-off-by: Eric W. Biederman Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit 110ae07d2268b176c470d3b26eaddd3c5f1b157b Author: Eric W. Biederman Date: Wed Oct 20 12:43:59 2021 -0500 signal: Implement force_fatal_sig commit 26d5badbccddcc063dc5174a2baffd13a23322aa upstream. Add a simple helper force_fatal_sig that causes a signal to be delivered to a process as if the signal handler was set to SIG_DFL. Reimplement force_sigsegv based upon this new helper. This fixes force_sigsegv so that when it forces the default signal handler to be used the code now forces the signal to be unblocked as well. Reusing the tested logic in force_sig_info_to_task that was built for force_sig_seccomp this makes the implementation trivial. This is interesting both because it makes force_sigsegv simpler and because there are a couple of buggy places in the kernel that call do_exit(SIGILL) or do_exit(SIGSYS) because there is no straight forward way today for those places to simply force the exit of a process with the chosen signal. Creating force_fatal_sig allows those places to be implemented with normal signal exits. Link: https://lkml.kernel.org/r/20211020174406.17889-13-ebiederm@xmission.com Signed-off-by: Eric W. Biederman Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit 21d727a394f01525f26603f1ca8db7a0e77b69f6 Author: Evan Quan Date: Fri Nov 5 15:25:30 2021 +0800 drm/amd/pm: avoid duplicate powergate/ungate setting commit 6ee27ee27ba8b2e725886951ba2d2d87f113bece upstream. Just bail out if the target IP block is already in the desired powergate/ungate state. This can avoid some duplicate settings which sometimes may cause unexpected issues. Link: https://lore.kernel.org/all/YV81vidWQLWvATMM@zn.tnic/ Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214921 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215025 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1789 Fixes: bf756fb833cb ("drm/amdgpu: add missing cleanups for Polaris12 UVD/VCE on suspend") Signed-off-by: Evan Quan Tested-by: Borislav Petkov Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ca28919fe90d02647702f3f49a96ff108dbb5260 Author: hongao Date: Thu Nov 11 11:32:07 2021 +0800 drm/amdgpu: fix set scaling mode Full/Full aspect/Center not works on vga and dvi connectors commit bf552083916a7f8800477b5986940d1c9a31b953 upstream. amdgpu_connector_vga_get_modes missed function amdgpu_get_native_mode which assign amdgpu_encoder->native_mode with *preferred_mode result in amdgpu_encoder->native_mode.clock always be 0. That will cause amdgpu_connector_set_property returned early on: if ((rmx_type != DRM_MODE_SCALE_NONE) && (amdgpu_encoder->native_mode.clock == 0)) when we try to set scaling mode Full/Full aspect/Center. Add the missing function to amdgpu_connector_vga_get_mode can fix this. It also works on dvi connectors because amdgpu_connector_dvi_helper_funcs.get_mode use the same method. Signed-off-by: hongao Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2e3eb81884de8f7ad09dd42006f6b89da3a7ca19 Author: Ville Syrjälä Date: Mon Oct 25 17:21:47 2021 +0300 drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern platforms commit 1977e8eb40ed53f0cac7db1a78295726f4ac0b24 upstream. Looks like we never updated intel_bios_is_port_dp_dual_mode() when the VBT port mapping became erratic on modern platforms. This is causing us to look up the wrong child device and thus throwing the heuristic off (ie. we might end looking at a child device for a genuine DP++ port when we were supposed to look at one for a native HDMI port). Fix it up by not using the outdated port_mapping[] in intel_bios_is_port_dp_dual_mode() and rely on intel_bios_encoder_data_lookup() instead. Cc: stable@vger.kernel.org Tested-by: Randy Dunlap Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4138 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20211025142147.23897-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula (cherry picked from commit 32c2bc89c7420fad2959ee23ef5b6be8b05d2bde) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit a2dda2817a9a4381399fe95b677de6fa7fac5ce3 Author: Imre Deak Date: Mon Oct 18 12:41:51 2021 +0300 drm/i915/dp: Ensure max link params are always valid commit cc99bc62ff6902688ee7bd3a7b25eefc620fbb6a upstream. Atm until the DPCD for a connector is read the max link rate and lane count params are invalid. If the connector is modeset, in intel_dp_compute_config(), intel_dp_common_len_rate_limit(max_link_rate) will return 0, leading to a intel_dp->common_rates[-1] access. Fix the above by making sure the max link params are always valid. The above access leads to an undefined behaviour by definition, though not causing a user visible problem to my best knowledge, see the previous patch why. Nevertheless it is an undefined behaviour and it triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable. Cc: Ville Syrjälä Cc: Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Acked-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-4-imre.deak@intel.com (cherry picked from commit 9ad87de4735620ffc555592e8c5f580478fa3ed0) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 72704e07a0038c9825e1c0db956ae0c8e24692de Author: Imre Deak Date: Mon Oct 18 17:34:17 2021 +0300 drm/i915/dp: Ensure sink rate values are always valid commit 6c34bd4532a3f39952952ddc102737595729afc4 upstream. Atm, there are no sink rate values set for DP (vs. eDP) sinks until the DPCD capabilities are successfully read from the sink. During this time intel_dp->num_common_rates is 0 which can lead to a intel_dp->common_rates[-1] (*) access, which is an undefined behaviour, in the following cases: - In intel_dp_sync_state(), if the encoder is enabled without a sink connected to the encoder's connector (BIOS enabled a monitor, but the user unplugged the monitor until the driver loaded). - In intel_dp_sync_state() if the encoder is enabled with a sink connected, but for some reason the DPCD read has failed. - In intel_dp_compute_link_config() if modesetting a connector without a sink connected on it. - In intel_dp_compute_link_config() if modesetting a connector with a a sink connected on it, but before probing the connector first. To avoid the (*) access in all the above cases, make sure that the sink rate table - and hence the common rate table - is always valid, by setting a default minimum sink rate when registering the connector before anything could use it. I also considered setting all the DP link rates by default, so that modesetting with higher resolution modes also succeeds in the last two cases above. However in case a sink is not connected that would stop working after the first modeset, due to the LT fallback logic. So this would need more work, beyond the scope of this fix. As I mentioned in the previous patch, I don't think the issue this patch fixes is user visible, however it is an undefined behaviour by definition and triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable. v2: Clear the default sink rates, before initializing these for eDP. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4297 References: https://gitlab.freedesktop.org/drm/intel/-/issues/4298 Suggested-by: Ville Syrjälä Cc: Ville Syrjälä Cc: Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Acked-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20211018143417.1452632-1-imre.deak@intel.com (cherry picked from commit 3f61ef9777c0ab0f03f4af0ed6fd3e5250537a8d) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit c3d06f6067bf4a6bb3e988251e1b718a295bb60b Author: Jeremy Cline Date: Wed Nov 25 15:26:48 2020 -0500 drm/nouveau: clean up all clients on device removal commit f55aaf63bde0d0336c3823bb3713bd4a464abbcf upstream. The postclose handler can run after the device has been removed (or the driver has been unbound) since userspace clients are free to hold the file open as long as they want. Because the device removal callback frees the entire nouveau_drm structure, any reference to it in the postclose handler will result in a use-after-free. To reproduce this, one must simply open the device file, unbind the driver (or physically remove the device), and then close the device file. This was found and can be reproduced easily with the IGT core_hotunplug tests. To avoid this, all clients are cleaned up in the device finalization rather than deferring it to the postclose handler, and the postclose handler is protected by a critical section which ensures the drm_dev_unplug() and the postclose handler won't race. This is not an ideal fix, since as I understand the proposed plan for the kernel<->userspace interface for hotplug support, destroying the client before the file is closed will cause problems. However, I believe to properly fix this issue, the lifetime of the nouveau_drm structure needs to be extended to match the drm_device, and this proved to be a rather invasive change. Thus, I've broken this out so the fix can be easily backported. This fixes with the two previous commits CVE-2020-27820 (Karol). Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Jeremy Cline Reviewed-by: Lyude Paul Reviewed-by: Ben Skeggs Tested-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20201125202648.5220-4-jcline@redhat.com Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14 Signed-off-by: Greg Kroah-Hartman commit 0b1a35d63995497a9186113c60a16e7ae59642c1 Author: Jeremy Cline Date: Wed Nov 25 15:26:46 2020 -0500 drm/nouveau: use drm_dev_unplug() during device removal commit aff2299e0d81b26304ccc6a1ec0170e437f38efc upstream. Nouveau does not currently support hot-unplugging, but it still makes sense to switch from drm_dev_unregister() to drm_dev_unplug(). drm_dev_unplug() calls drm_dev_unregister() after marking the device as unplugged, but only after any device critical sections are finished. Since nouveau isn't using drm_dev_enter() and drm_dev_exit(), there are no critical sections so this is nearly functionally equivalent. However, the DRM layer does check to see if the device is unplugged, and if it is returns appropriate error codes. In the future nouveau can add critical sections in order to truly support hot-unplugging. Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Jeremy Cline Reviewed-by: Lyude Paul Reviewed-by: Ben Skeggs Tested-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20201125202648.5220-2-jcline@redhat.com Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14 Signed-off-by: Greg Kroah-Hartman commit 4ee6807a1ad756ca151eaa4ac57c96ffbbac926f Author: Jeremy Cline Date: Wed Nov 25 15:26:47 2020 -0500 drm/nouveau: Add a dedicated mutex for the clients list commit abae9164a421bc4a41a3769f01ebcd1f9d955e0e upstream. Rather than protecting the nouveau_drm clients list with the lock within the "client" nouveau_cli, add a dedicated lock to serialize access to the list. This is both clearer and necessary to avoid lockdep being upset with us when we need to iterate through all the clients in the list and potentially lock their mutex, which is the same class as the lock protecting the entire list. Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Jeremy Cline Reviewed-by: Lyude Paul Reviewed-by: Ben Skeggs Tested-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20201125202648.5220-3-jcline@redhat.com Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14 Signed-off-by: Greg Kroah-Hartman commit 4f8e469a2384dfa4047145b0093126462cbb6dc0 Author: Anand K Mistry Date: Thu Sep 30 09:00:07 2021 +1000 drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap commit 8244a3bc27b3efd057da154b8d7e414670d5044f upstream. drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." Signed-off-by: Anand K Mistry Fixes: 9786b65bc61a ("drm/ttm: fix mmap refcounting") Cc: Gerd Hoffmann Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: # v5.5+ Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20210930085932.1.I8043d61cc238e0168e2f4ca5f4783223434aa587@changeid Signed-off-by: Greg Kroah-Hartman commit 59fb48db328b040e82783fdcbdf1cd9f9d195528 Author: Johan Hovold Date: Mon Oct 25 13:53:53 2021 +0200 drm/udl: fix control-message timeout commit 5591c8f79db1729d9c5ac7f5b4d3a5c26e262d93 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 5320918b9a87 ("drm/udl: initial UDL driver (v4)") Cc: stable@vger.kernel.org # 3.4 Signed-off-by: Johan Hovold Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20211025115353.5089-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit f5b5ea1654408018e0515fcb62b35fe22ef81ca3 Author: Matthew Brost Date: Thu Sep 9 09:47:24 2021 -0700 drm/i915/guc: Unwind context requests in reverse order commit c39f51cc980dd918c5b3da61d54c4725785e766e upstream. When unwinding requests on a reset context, if other requests in the context are in the priority list the requests could be resubmitted out of seqno order. Traverse the list of active requests in reverse and append to the head of the priority list to fix this. Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Signed-off-by: Matthew Brost Reviewed-by: Daniele Ceraolo Spurio Cc: Signed-off-by: John Harrison Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-4-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman commit 413e603c1447d117261ed33c6571688964636c0b Author: Matthew Brost Date: Thu Sep 9 09:47:25 2021 -0700 drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context commit 88209a8ecb8b8752322908a3c3362a001bdc3a39 upstream. Don't drop ce->guc_active.lock when unwinding a context after reset. At one point we had to drop this because of a lock inversion but that is no longer the case. It is much safer to hold the lock so let's do that. Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Reviewed-by: Daniele Ceraolo Spurio Signed-off-by: Matthew Brost Cc: Signed-off-by: John Harrison Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-5-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman commit 2a45b1c66ccc589699102ef95a12a719fa69c6b6 Author: Matthew Brost Date: Thu Sep 9 09:47:27 2021 -0700 drm/i915/guc: Workaround reset G2H is received after schedule done G2H commit 1ca36cff0166b0483fe3b99e711e9c800ebbfaa4 upstream. If the context is reset as a result of the request cancellation the context reset G2H is received after schedule disable done G2H which is the wrong order. The schedule disable done G2H release the waiting request cancellation code which resubmits the context. This races with the context reset G2H which also wants to resubmit the context but in this case it really should be a NOP as request cancellation code owns the resubmit. Use some clever tricks of checking the context state to seal this race until the GuC firmware is fixed. v2: (Checkpatch) - Fix typos v3: (Daniele) - State that is a bug in the GuC firmware Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost Cc: Reviewed-by: Daniele Ceraolo Spurio Signed-off-by: John Harrison Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-7-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman commit ad583a961905f843c420279a8db230e2719f60d1 Author: Matthew Brost Date: Thu Sep 9 09:47:30 2021 -0700 drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registered commit 9888beaaf118b6878347e1fe2b369fc66d756d18 upstream. When unblocking a context, do not enable scheduling if the context is banned, guc_id invalid, or not registered. v2: (Daniele) - Add helper for unblock Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost Reviewed-by: Daniele Ceraolo Spurio Cc: Signed-off-by: John Harrison Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-10-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman commit 519bd9107ef60d1137ba48106925a7f861624fd8 Author: Matthew Brost Date: Thu Sep 9 09:47:23 2021 -0700 drm/i915/guc: Fix outstanding G2H accounting commit 669b949c1a44d0cb2bcd18ff6ab4fd0c21e7cf6f upstream. A small race that could result in incorrect accounting of the number of outstanding G2H. Basically prior to this patch we did not increment the number of outstanding G2H if we encoutered a GT reset while sending a H2G. This was incorrect as the context state had already been updated to anticipate a G2H response thus the counter should be incremented. As part of this change we remove a legacy (now unused) path that was the last caller requiring a G2H response that was not guaranteed to loop. This allows us to simplify the accounting as we don't need to handle the case where the send fails due to the channel being busy. Also always use helper when decrementing this value. v2 (Daniele): update GEM_BUG_ON check, pull in dead code removal from later patch, remove loop param from context_deregister. Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in buffer") Signed-off-by: Matthew Brost Signed-off-by: Daniele Ceraolo Spurio Cc: Reviewed-by: John Harrison Signed-off-by: John Harrison Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-3-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman commit 296188ce0360113cadcdb55313f14cd4d4b5ecfa Author: Roman Li Date: Fri Jul 30 18:30:41 2021 -0400 drm/amd/display: Limit max DSC target bpp for specific monitors commit 55eea8ef98641f6e1e1c202bd3a49a57c1dd4059 upstream. [Why] Some monitors exhibit corruption at 16bpp DSC. [How] - Add helpers for patching edid caps. - Use it for limiting DSC target bitrate to 15bpp for known monitors Reviewed-by: Rodrigo Siqueira Acked-by: Qingqing Zhuo Signed-off-by: Roman Li Cc: stable@vger.kernel.org Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d4b7d7b80bb6b9e2695061446fecf6c083f8042f Author: Alvin Lee Date: Fri Jul 30 16:55:06 2021 -0400 drm/amd/display: Update swizzle mode enums commit 58065a1e524de30df9a2d8214661d5d7eed0a2d9 upstream. [Why] Swizzle mode enum for DC_SW_VAR_R_X was existing, but not mapped correctly. [How] Update mapping and conversion for DC_SW_VAR_R_X. Reviewed-by: XiangBing Foo Reviewed-by: Martin Leung Acked-by: Qingqing Zhuo Signed-off-by: Alvin Lee Cc: stable@vger.kernel.org Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 76025be187d2396efd7a1bbd45084154f4eea01a Author: Felix Fietkau Date: Wed Nov 10 22:22:01 2021 +0100 mac80211: drop check for DONT_REORDER in __ieee80211_select_queue commit f6ab25d41b18f3d26883cb9c20875e1a85c4f05b upstream. When __ieee80211_select_queue is called, skb->cb has not been cleared yet, which means that info->control.flags can contain garbage. In some cases this leads to IEEE80211_TX_CTRL_DONT_REORDER being set, causing packets marked for other queues to randomly end up in BE instead. This flag only needs to be checked in ieee80211_select_queue_80211, since the radiotap parser is the only piece of code that sets it Fixes: 66d06c84730c ("mac80211: adhere to Tx control flag that prevents frame reordering") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20211110212201.35452-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 60a3a889efe5f56f0ed90059b49d85a6ccfaa2df Author: Johannes Berg Date: Tue Nov 9 10:02:04 2021 +0100 mac80211: fix radiotap header generation commit c033a38a81bc539d6c0db8c5387e0b14d819a0cf upstream. In commit 8c89f7b3d3f2 ("mac80211: Use flex-array for radiotap header bitmap") we accidentally pointed the position to the wrong place, so we overwrite a present bitmap, and thus cause all kinds of trouble. To see the issue, note that the previous code read: pos = (void *)(it_present + 1); The requirement now is that we need to calculate pos via it_optional, to not trigger the compiler hardening checks, as: pos = (void *)&rthdr->it_optional[...]; Rewriting the original expression, we get (obviously, since that just adds "+ x - x" terms): pos = (void *)(it_present + 1 + rthdr->it_optional - rthdr->it_optional) and moving the "+ rthdr->it_optional" outside to be used as an array: pos = (void *)&rthdr->it_optional[it_present + 1 - rthdr->it_optional]; The original is off by one, fix it. Cc: stable@vger.kernel.org Fixes: 8c89f7b3d3f2 ("mac80211: Use flex-array for radiotap header bitmap") Reported-by: Sid Hayn Signed-off-by: Johannes Berg Tested-by: Sid Hayn Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20211109100203.c61007433ed6.I1dade57aba7de9c4f48d68249adbae62636fd98c@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 5a9b671c8d74a3e1b999e7a0c7f366079bcc93dd Author: Nguyen Dinh Phi Date: Thu Oct 28 01:37:22 2021 +0800 cfg80211: call cfg80211_stop_ap when switch from P2P_GO type commit 563fbefed46ae4c1f70cffb8eb54c02df480b2c2 upstream. If the userspace tools switch from NL80211_IFTYPE_P2P_GO to NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it does not call the cleanup cfg80211_stop_ap(), this leads to the initialization of in-use data. For example, this path re-init the sdata->assigned_chanctx_list while it is still an element of assigned_vifs list, and makes that linked list corrupt. Signed-off-by: Nguyen Dinh Phi Reported-by: syzbot+bbf402b783eeb6d908db@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20211027173722.777287-1-phind.uet@gmail.com Cc: stable@vger.kernel.org Fixes: ac800140c20e ("cfg80211: .stop_ap when interface is going down") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a1c9455f10bedd84ec1d3d420ad1dafd6f187090 Author: Sven Schnelle Date: Sun Nov 14 17:08:17 2021 +0100 parisc/sticon: fix reverse colors commit bec05f33ebc1006899c6d3e59a00c58881fe7626 upstream. sticon_build_attr() checked the reverse argument and flipped background and foreground color, but returned the non-reverse value afterwards. Fix this and also add two local variables for foreground and background color to make the code easier to read. Signed-off-by: Sven Schnelle Cc: Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 61b26492e7d18aadd4c54e64bd45c1f7c056973c Author: Thomas Gleixner Date: Mon Nov 15 16:21:23 2021 +0100 net: stmmac: Fix signed/unsigned wreckage commit 3751c3d34cd5a750c86d1c8eaf217d8faf7f9325 upstream. The recent addition of timestamp correction to compensate the CDC error introduced a subtle signed/unsigned bug in stmmac_get_tx_hwtstamp() while it managed for some obscure reason to avoid that in stmmac_get_rx_hwtstamp(). The issue is: s64 adjust = 0; u64 ns; adjust += -(2 * (NSEC_PER_SEC / priv->plat->clk_ptp_rate)); ns += adjust; works by chance on 64bit, but falls apart on 32bit because the compiler knows that adjust fits into 32bit and then treats the addition as a u64 + u32 resulting in an off by ~2 seconds failure. The RX variant uses an u64 for adjust and does the adjustment via ns -= adjust; because consistency is obviously overrated. Get rid of the pointless zero initialized adjust variable and do: ns -= (2 * NSEC_PER_SEC) / priv->plat->clk_ptp_rate; which is obviously correct and spares the adjust obfuscation. Aside of that it yields a more accurate result because the multiplication takes place before the integer divide truncation and not afterwards. Stick the calculation into an inline so it can't be accidentally disimproved. Return an u32 from that inline as the result is guaranteed to fit which lets the compiler optimize the substraction. Cc: stable@vger.kernel.org Fixes: 3600be5f58c1 ("net: stmmac: add timestamp correction to rid CDC sync error") Reported-by: Benedikt Spranger Signed-off-by: Thomas Gleixner Tested-by: Benedikt Spranger Tested-by: Kurt Kanzenbach # Intel EHL Link: https://lore.kernel.org/r/87mtm578cs.ffs@tglx Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7c48010ba348668602da7b280f56177f4b687287 Author: Christian Brauner Date: Tue Nov 9 15:57:12 2021 +0100 fs: handle circular mappings correctly commit 968219708108440b23bc292e0486e3cc1d9a1bed upstream. When calling setattr_prepare() to determine the validity of the attributes the ia_{g,u}id fields contain the value that will be written to inode->i_{g,u}id. When the {g,u}id attribute of the file isn't altered and the caller's fs{g,u}id matches the current {g,u}id attribute the attribute change is allowed. The value in ia_{g,u}id does already account for idmapped mounts and will have taken the relevant idmapping into account. So in order to verify that the {g,u}id attribute isn't changed we simple need to compare the ia_{g,u}id value against the inode's i_{g,u}id value. This only has any meaning for idmapped mounts as idmapping helpers are idempotent without them. And for idmapped mounts this really only has a meaning when circular idmappings are used, i.e. mappings where e.g. id 1000 is mapped to id 1001 and id 1001 is mapped to id 1000. Such ciruclar mappings can e.g. be useful when sharing the same home directory between multiple users at the same time. As an example consider a directory with two files: /source/file1 owned by {g,u}id 1000 and /source/file2 owned by {g,u}id 1001. Assume we create an idmapped mount at /target with an idmapping that maps files owned by {g,u}id 1000 to being owned by {g,u}id 1001 and files owned by {g,u}id 1001 to being owned by {g,u}id 1000. In effect, the idmapped mount at /target switches the ownership of /source/file1 and source/file2, i.e. /target/file1 will be owned by {g,u}id 1001 and /target/file2 will be owned by {g,u}id 1000. This means that a user with fs{g,u}id 1000 must be allowed to setattr /target/file2 from {g,u}id 1000 to {g,u}id 1000. Similar, a user with fs{g,u}id 1001 must be allowed to setattr /target/file1 from {g,u}id 1001 to {g,u}id 1001. Conversely, a user with fs{g,u}id 1000 must fail to setattr /target/file1 from {g,u}id 1001 to {g,u}id 1000. And a user with fs{g,u}id 1001 must fail to setattr /target/file2 from {g,u}id 1000 to {g,u}id 1000. Both cases must fail with EPERM for non-capable callers. Before this patch we could end up denying legitimate attribute changes and allowing invalid attribute changes when circular mappings are used. To even get into this situation the caller must've been privileged both to create that mapping and to create that idmapped mount. This hasn't been seen in the wild anywhere but came up when expanding the testsuite during work on a series of hardening patches. All idmapped fstests pass without any regressions and we add new tests to verify the behavior of circular mappings. Link: https://lore.kernel.org/r/20211109145713.1868404-1-brauner@kernel.org Fixes: 2f221d6f7b88 ("attr: handle idmapped mounts") Cc: Seth Forshee Cc: Christoph Hellwig Cc: Al Viro Cc: stable@vger.kernel.org CC: linux-fsdevel@vger.kernel.org Reviewed-by: Christoph Hellwig Acked-by: Seth Forshee Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 47e6f9f69153247109042010f3a77579e9dc61ff Author: Nikolay Borisov Date: Tue Nov 2 14:49:16 2021 +0200 btrfs: fix memory ordering between normal and ordered work functions commit 45da9c1767ac31857df572f0a909fbe88fd5a7e9 upstream. Ordered work functions aren't guaranteed to be handled by the same thread which executed the normal work functions. The only way execution between normal/ordered functions is synchronized is via the WORK_DONE_BIT, unfortunately the used bitops don't guarantee any ordering whatsoever. This manifested as seemingly inexplicable crashes on ARM64, where async_chunk::inode is seen as non-null in async_cow_submit which causes submit_compressed_extents to be called and crash occurs because async_chunk::inode suddenly became NULL. The call trace was similar to: pc : submit_compressed_extents+0x38/0x3d0 lr : async_cow_submit+0x50/0xd0 sp : ffff800015d4bc20 Call trace: submit_compressed_extents+0x38/0x3d0 async_cow_submit+0x50/0xd0 run_ordered_work+0xc8/0x280 btrfs_work_helper+0x98/0x250 process_one_work+0x1f0/0x4ac worker_thread+0x188/0x504 kthread+0x110/0x114 ret_from_fork+0x10/0x18 Fix this by adding respective barrier calls which ensure that all accesses preceding setting of WORK_DONE_BIT are strictly ordered before setting the flag. At the same time add a read barrier after reading of WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads would be strictly ordered after reading the bit. This in turn ensures are all accesses before WORK_DONE_BIT are going to be strictly ordered before any access that can occur in ordered_func. Reported-by: Chris Murphy Fixes: 08a9ff326418 ("btrfs: Added btrfs_workqueue_struct implemented ordered execution based on kernel workqueue") CC: stable@vger.kernel.org # 4.4+ Link: https://bugzilla.redhat.com/show_bug.cgi?id=2011928 Reviewed-by: Josef Bacik Tested-by: Chris Murphy Signed-off-by: Nikolay Borisov Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit cd198aea9e8dc1a16a40ed52a6a4d42be470c151 Author: Boqun Feng Date: Mon Nov 1 23:00:26 2021 +0800 Drivers: hv: balloon: Use VMBUS_RING_SIZE() wrapper for dm_ring_size commit 8a7eb2d476c6823cd44d8c25a6230a52417d7ef8 upstream. Baihua reported an error when boot an ARM64 guest with PAGE_SIZE=64k and BALLOON is enabled: hv_vmbus: registering driver hv_balloon hv_vmbus: probe failed for device 1eccfd72-4b41-45ef-b73a-4a6e44c12924 (-22) The cause of this is that the ringbuffer size for hv_balloon is not adjusted with VMBUS_RING_SIZE(), which makes the size not large enough for ringbuffers on guest with PAGE_SIZE=64k. Therefore use VMBUS_RING_SIZE() to calculate the ringbuffer size. Note that the old size (20 * 1024) counts a 4k header in the total size, while VMBUS_RING_SIZE() expects the parameter as the payload size, so use 16 * 1024. Cc: # 5.15.x Reported-by: Baihua Lu Signed-off-by: Boqun Feng Tested-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/20211101150026.736124-1-boqun.feng@gmail.com Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit d8f574fb5eb2c604aaacb0fafb756c7d9f610d57 Author: Meng Li Date: Mon Nov 15 15:04:23 2021 +0800 net: stmmac: socfpga: add runtime suspend/resume callback for stratix10 platform commit 9119570039481d56350af1c636f040fb300b8cf3 upstream. According to upstream commit 5ec55823438e("net: stmmac: add clocks management for gmac driver"), it improve clocks management for stmmac driver. So, it is necessary to implement the runtime callback in dwmac-socfpga driver because it doesn't use the common stmmac_pltfr_pm_ops instance. Otherwise, clocks are not disabled when system enters suspend status. Fixes: 5ec55823438e ("net: stmmac: add clocks management for gmac driver") Cc: stable@vger.kernel.org Signed-off-by: Meng Li Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 37330f37f6666c7739a44b2b6b95b047ccdbed2d Author: Michael Walle Date: Thu Nov 11 09:37:13 2021 +0100 spi: fix use-after-free of the add_lock mutex commit 6c53b45c71b4920b5e62f0ea8079a1da382b9434 upstream. Commit 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on SPI buses") introduced a per-controller mutex. But mutex_unlock() of said lock is called after the controller is already freed: spi_unregister_controller(ctlr) -> put_device(&ctlr->dev) -> spi_controller_release(dev) -> mutex_unlock(&ctrl->add_lock) Move the put_device() after the mutex_unlock(). Fixes: 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on SPI buses") Signed-off-by: Michael Walle Reviewed-by: Uwe Kleine-König Reviewed-by: Lukas Wunner Cc: stable@vger.kernel.org # v5.15 Link: https://lore.kernel.org/r/20211111083713.3335171-1-michael@walle.cc Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 77a5baefe1be118fec7deefd9935e2bc0d4ec596 Author: Jan Kara Date: Thu Nov 4 15:22:35 2021 +0100 udf: Fix crash after seekdir commit a48fc69fe6588b48d878d69de223b91a386a7cb4 upstream. udf_readdir() didn't validate the directory position it should start reading from. Thus when user uses lseek(2) on directory file descriptor it can trick udf_readdir() into reading from a position in the middle of directory entry which then upsets directory parsing code resulting in errors or even possible kernel crashes. Similarly when the directory is modified between two readdir calls, the directory position need not be valid anymore. Add code to validate current offset in the directory. This is actually rather expensive for UDF as we need to read from the beginning of the directory and parse all directory entries. This is because in UDF a directory is just a stream of data containing directory entries and since file names are fully under user's control we cannot depend on detecting magic numbers and checksums in the header of directory entry as a malicious attacker could fake them. We skip this step if we detect that nothing changed since the last readdir call. Reported-by: Nathan Wilson CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit c3b0ab956d90969bb3c07101375853bd93c9793a Author: Nicholas Piggin Date: Sun Nov 7 14:51:16 2021 +1000 printk: restore flushing of NMI buffers on remote CPUs after NMI backtraces commit 5d5e4522a7f404d1a96fd6c703989d32a9c9568d upstream. printk from NMI context relies on irq work being raised on the local CPU to print to console. This can be a problem if the NMI was raised by a lockup detector to print lockup stack and regs, because the CPU may not enable irqs (because it is locked up). Introduce printk_trigger_flush() that can be called another CPU to try to get those messages to the console, call that where printk_safe_flush was previously called. Fixes: 93d102f094be ("printk: remove safe buffers") Cc: stable@vger.kernel.org # 5.15 Signed-off-by: Nicholas Piggin Reviewed-by: Petr Mladek Reviewed-by: John Ogness Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20211107045116.1754411-1-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit 76b46fa3f8d95c51b808e2227a5e0fc5f8005842 Author: Thomas Zimmermann Date: Thu Jul 8 19:51:46 2021 +0200 drm/cma-helper: Release non-coherent memory with dma_free_noncoherent() commit 995f54ea962e03ec08b8bc6a4fe11a32b420edd3 upstream. The GEM CMA helpers allocate non-coherent (i.e., cached) backing storage with dma_alloc_noncoherent(), but release it with dma_free_wc(). Fix this with a call to dma_free_noncoherent(). Writecombining storage is still released with dma_free_wc(). Signed-off-by: Thomas Zimmermann Fixes: cf8ccbc72d61 ("drm: Add support for GEM buffers backed by non-coherent memory") Acked-by: Paul Cercueil Cc: Thomas Zimmermann Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: # v5.14+ Link: https://patchwork.freedesktop.org/patch/msgid/20210708175146.10618-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 94cc0809e525907d38a5c7a9c47fa952d662b378 Author: Maxim Levitsky Date: Mon Nov 15 15:18:36 2021 +0200 KVM: nVMX: don't use vcpu->arch.efer when checking host state on nested state load commit af957eebfcc17433ee83ab85b1195a933ab5049c upstream. When loading nested state, don't use check vcpu->arch.efer to get the L1 host's 64-bit vs. 32-bit state and don't check it for consistency with respect to VM_EXIT_HOST_ADDR_SPACE_SIZE, as register state in vCPU may be stale when KVM_SET_NESTED_STATE is called---and architecturally does not exist. When restoring L2 state in KVM, the CPU is placed in non-root where nested VMX code has no snapshot of L1 host state: VMX (conditionally) loads host state fields loaded on VM-exit, but they need not correspond to the state before entry. A simple case occurs in KVM itself, where the host RIP field points to vmx_vmexit rather than the instruction following vmlaunch/vmresume. However, for the particular case of L1 being in 32- or 64-bit mode on entry, the exit controls can be treated instead as the source of truth regarding the state of L1 on entry, and can be used to check that vmcs12.VM_EXIT_HOST_ADDR_SPACE_SIZE matches vmcs12.HOST_EFER if vmcs12.VM_EXIT_LOAD_IA32_EFER is set. The consistency check on CPU EFER vs. vmcs12.VM_EXIT_HOST_ADDR_SPACE_SIZE, instead, happens only on VM-Enter. That's because, again, there's conceptually no "current" L1 EFER to check on KVM_SET_NESTED_STATE. Suggested-by: Paolo Bonzini Signed-off-by: Maxim Levitsky Message-Id: <20211115131837.195527-2-mlevitsk@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 679a6ffd07b6a0d91bd854fd5dc08dba19b38c73 Author: Sean Christopherson Date: Tue Nov 9 21:50:56 2021 +0000 KVM: SEV: Disallow COPY_ENC_CONTEXT_FROM if target has created vCPUs commit 79b11142763791bdead8b6460052cbdde8e08e2f upstream. Reject COPY_ENC_CONTEXT_FROM if the destination VM has created vCPUs. KVM relies on SEV activation to occur before vCPUs are created, e.g. to set VMCB flags and intercepts correctly. Fixes: 54526d1fd593 ("KVM: x86: Support KVM VMs sharing SEV context") Cc: stable@vger.kernel.org Cc: Peter Gonda Cc: Marc Orr Cc: Sean Christopherson Cc: Nathan Tempelman Cc: Brijesh Singh Cc: Tom Lendacky Signed-off-by: Sean Christopherson Message-Id: <20211109215101.2211373-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 90342e02b471345f5e698a4e668b1045170da0e0 Author: Javier Martinez Canillas Date: Thu Nov 11 12:57:57 2021 +0100 fbdev: Prevent probing generic drivers if a FB is already registered commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee upstream. The efifb and simplefb drivers just render to a pre-allocated frame buffer and rely on the display hardware being initialized before the kernel boots. But if another driver already probed correctly and registered a fbdev, the generic drivers shouldn't be probed since an actual driver for the display hardware is already present. This is more likely to occur after commit d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support") since the "efi-framebuffer" and "simple-framebuffer" platform devices are registered at a later time. Link: https://lore.kernel.org/r/20211110200253.rfudkt3edbd3nsyj@lahvuun/ Fixes: d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by: Ilya Trukhanov Cc: # 5.15.x Signed-off-by: Javier Martinez Canillas Reviewed-by: Daniel Vetter Tested-by: Ilya Trukhanov Link: https://patchwork.freedesktop.org/patch/msgid/20211111115757.1351045-1-javierm@redhat.com Signed-off-by: Greg Kroah-Hartman commit 1560763677ffdb82504bf6504575c73d757720e4 Author: Alistair Delva Date: Mon Nov 15 18:16:55 2021 +0000 block: Check ADMIN before NICE for IOPRIO_CLASS_RT commit 94c4b4fd25e6c3763941bdec3ad54f2204afa992 upstream. Booting to Android userspace on 5.14 or newer triggers the following SELinux denial: avc: denied { sys_nice } for comm="init" capability=23 scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=capability permissive=0 Init is PID 0 running as root, so it already has CAP_SYS_ADMIN. For better compatibility with older SEPolicy, check ADMIN before NICE. Fixes: 9d3a39a5f1e4 ("block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE") Signed-off-by: Alistair Delva Cc: Khazhismel Kumykov Cc: Bart Van Assche Cc: Serge Hallyn Cc: Jens Axboe Cc: Greg Kroah-Hartman Cc: Paul Moore Cc: selinux@vger.kernel.org Cc: linux-security-module@vger.kernel.org Cc: kernel-team@android.com Cc: stable@vger.kernel.org # v5.14+ Reviewed-by: Bart Van Assche Acked-by: Serge Hallyn Link: https://lore.kernel.org/r/20211115181655.3608659-1-adelva@google.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 520f8ac91f2bf0f862a0ee6bd542da1364ee4907 Author: Alexander Egorenkov Date: Mon Nov 15 07:40:25 2021 +0100 s390/dump: fix copying to user-space of swapped kdump oldmem commit 3b90954419d4c05651de9cce6d7632bcf6977678 upstream. This commit fixes a bug introduced by commit e9e7870f90e3 ("s390/dump: introduce boot data 'oldmem_data'"). OLDMEM_BASE was mistakenly replaced by oldmem_data.size instead of oldmem_data.start. This bug caused the following error during kdump: kdump.sh[878]: No program header covering vaddr 0x3434f5245found kexec bug? Fixes: e9e7870f90e3 ("s390/dump: introduce boot data 'oldmem_data'") Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Alexander Egorenkov Reviewed-by: Marc Hartmayer Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit c0849d3157a8832f4e43f5642638966fa803ea7f Author: Baoquan He Date: Tue Nov 16 11:31:01 2021 +0800 s390/kexec: fix memory leak of ipl report buffer commit 4aa9340584e37debef06fa99b56d064beb723891 upstream. unreferenced object 0x38000195000 (size 4096): comm "kexec", pid 8548, jiffies 4294953647 (age 32443.270s) hex dump (first 32 bytes): 00 00 00 c8 20 00 00 00 00 00 00 c0 02 80 00 00 .... ........... 40 40 40 40 40 40 40 40 00 00 00 00 00 00 00 00 @@@@@@@@........ backtrace: [<0000000011a2f199>] __vmalloc_node_range+0xc0/0x140 [<0000000081fa2752>] vzalloc+0x5a/0x70 [<0000000063a4c92d>] ipl_report_finish+0x2c/0x180 [<00000000553304da>] kexec_file_add_ipl_report+0xf4/0x150 [<00000000862d033f>] kexec_file_add_components+0x124/0x160 [<000000000d2717bb>] arch_kexec_kernel_image_load+0x62/0x90 [<000000002e0373b6>] kimage_file_alloc_init+0x1aa/0x2e0 [<0000000060f2d14f>] __do_sys_kexec_file_load+0x17c/0x2c0 [<000000008c86fe5a>] __s390x_sys_kexec_file_load+0x40/0x50 [<000000001fdb9dac>] __do_syscall+0x1bc/0x1f0 [<000000003ee4258d>] system_call+0x78/0xa0 Signed-off-by: Baoquan He Reviewed-by: Philipp Rudo Fixes: 99feaa717e55 ("s390/kexec_file: Create ipl report and pass to next kernel") Cc: # v5.2: 20c76e242e70: s390/kexec: fix return code handling Cc: # v5.2 Link: https://lore.kernel.org/r/20211116033101.GD21646@MiWiFi-R3L-srv Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit cc8b2e0d5bd75b67d7ee24de2685d2ee3d28e2d9 Author: Sven Schnelle Date: Thu Nov 11 10:58:26 2021 +0100 s390/vdso: filter out -mstack-guard and -mstack-size commit 00b55eaf45549ce26424224d069a091c7e5d8bac upstream. When CONFIG_VMAP_STACK is disabled, the user can enable CONFIG_STACK_CHECK, which adds a stack overflow check to each C function in the kernel. This is also done for functions in the vdso page. These functions are run in user context and user stack sizes are usually different to what the kernel uses. This might trigger the stack check although the stack size is valid. Therefore filter the -mstack-guard and -mstack-size flags when compiling vdso C files. Cc: stable@kernel.org # 5.10+ Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO") Reported-by: Janosch Frank Signed-off-by: Sven Schnelle Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 44b6cc4367cc6f9c3803bd19df509ae7c1e3496e Author: Vasily Gorbik Date: Thu Oct 14 13:53:54 2021 +0200 s390/boot: simplify and fix kernel memory layout setup commit 9a39abb7c9aab50eec4ac4421e9ee7f3de013d24 upstream. Initial KASAN shadow memory range was picked to preserve original kernel modules area position. With protected execution support, which might impose addressing limitation on vmalloc area and hence affect modules area position, current fixed KASAN shadow memory range is only making kernel memory layout setup more complex. So move it to the very end of available virtual space and simplify calculations. At the same time return to previous kernel address space split. In particular commit 0c4f2623b957 ("s390: setup kernel memory layout early") introduced precise identity map size calculation and keeping vmemmap left most starting from a fresh region table entry. This didn't take into account additional mapping region requirement for potential DCSS mapping above available physical memory. So go back to virtual space split between 1:1 mapping & vmemmap array once vmalloc area size is subtracted. Cc: stable@vger.kernel.org Fixes: 0c4f2623b957 ("s390: setup kernel memory layout early") Reported-by: Gerald Schaefer Reviewed-by: Heiko Carstens Reviewed-by: Alexander Gordeev Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit a4c7fe4409c5474bf6ed4681749bd63a8be9afd3 Author: Vasily Gorbik Date: Thu Oct 14 13:33:45 2021 +0200 s390/setup: avoid reserving memory above identity mapping commit 420f48f636b98fd685f44a3acc4c0a7c0840910d upstream. Such reserved memory region, if not cleaned up later causes problems when memblock_free_all() is called to release free pages to the buddy allocator and those reserved regions are carried over to reserve_bootmem_region() which marks the pages as PageReserved. Instead use memblock_set_current_limit() to make sure memblock allocations do not go over identity mapping (which could happen when "mem=" option is used or during kdump). Cc: stable@vger.kernel.org Fixes: 73045a08cf55 ("s390: unify identity mapping limits handling") Reported-by: Gerald Schaefer Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit f07220f7d56844b5ebb85076acbb7ba99f32be38 Author: Sergio Paracuellos Date: Sun Oct 31 07:40:46 2021 +0100 pinctrl: ralink: include 'ralink_regs.h' in 'pinctrl-mt7620.c' commit a5b9703fe11cd1d6d7a60102aa2abe686dc1867f upstream. mt7620.h, included by pinctrl-mt7620.c, mentions MT762X_SOC_MT7628AN declared in ralink_regs.h. Fixes: 745ec436de72 ("pinctrl: ralink: move MT7620 SoC pinmux config into a new 'pinctrl-mt7620.c' file") Cc: stable@vger.kernel.org Signed-off-by: Luiz Angelo Daros de Luca Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20211031064046.13533-1-sergio.paracuellos@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 4ac27afaf79d604073ace3253ee66125f2354b47 Author: Ewan D. Milne Date: Mon Nov 8 13:30:12 2021 -0500 scsi: qla2xxx: Fix mailbox direction flags in qla2xxx_get_adapter_id() commit 392006871bb26166bcfafa56faf49431c2cfaaa8 upstream. The SCM changes set the flags in mcp->out_mb instead of mcp->in_mb so the data was not actually being read into the mcp->mb[] array from the adapter. Link: https://lore.kernel.org/r/20211108183012.13895-1-emilne@redhat.com Fixes: 9f2475fe7406 ("scsi: qla2xxx: SAN congestion management implementation") Cc: stable@vger.kernel.org Reviewed-by: Himanshu Madhani Reviewed-by: Arun Easi Signed-off-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit e449d2e69ad7304a7ff1512e1e79bd1d881289cd Author: Damien Le Moal Date: Mon Nov 15 12:47:26 2021 +0900 ata: libata: add missing ata_identify_page_supported() calls commit 06f6c4c6c3e8354dceddd77bd58f9a7a84c67246 upstream. ata_dev_config_ncq_prio() and ata_dev_config_devslp() both access pages of the IDENTIFY DEVICE data log. Before calling ata_read_log_page(), make sure to check for the existence of the IDENTIFY DEVICE data log and of the log page accessed using ata_identify_page_supported(). This avoids useless error messages from ata_read_log_page() and failures with some LLDD scsi drivers using libsas. Reported-by: Nikolay Cc: stable@kernel.org # 5.15 Signed-off-by: Damien Le Moal Tested-by: Matthew Perkowski Signed-off-by: Greg Kroah-Hartman commit 08a667e440d72864f0732c0084d1c1d370d28a84 Author: Damien Le Moal Date: Mon Nov 15 12:37:46 2021 +0900 ata: libata: improve ata_read_log_page() error message commit 23ef63d5e14f916c5bba39128ebef395859d7c0f upstream. If ata_read_log_page() fails to read a log page, the ata_dev_err() error message only print the page number, omitting the log number. In case of error, facilitate debugging by also printing the log number. Cc: stable@kernel.org # 5.15 Signed-off-by: Damien Le Moal Tested-by: Matthew Perkowski Signed-off-by: Greg Kroah-Hartman commit 4ca2a26feeb435a439a206bc22a0e5df256e9a88 Author: Helge Deller Date: Wed Nov 17 11:05:07 2021 +0100 Revert "parisc: Reduce sigreturn trampoline to 3 instructions" commit 79df39d535c7a3770856fe9f5aba8c0ad1eebdb6 upstream. This reverts commit e4f2006f1287e7ea17660490569cff323772dac4. This patch shows problems with signal handling. Revert it for now. Signed-off-by: Helge Deller Cc: # v5.15 Signed-off-by: Greg Kroah-Hartman commit 586afe2b8420c41b4354a88a81e08eec6c1c139d Author: Vandita Kulkarni Date: Tue Nov 9 17:34:28 2021 +0530 Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping" commit f15863b27752682bb700c21de5f83f613a0fb77e upstream. This reverts commit 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"). The Bspec was updated recently with the pll ungate sequence similar to that of icl dsi enable sequence. Hence reverting. Bspec: 49187 Fixes: 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping") Cc: # v5.4+ Signed-off-by: Vandita Kulkarni Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20211109120428.15211-1-vandita.kulkarni@intel.com (cherry picked from commit 4579509ef181480f4e4510d436c691519167c5c2) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit de04ee7d7d543fd82e57589e21c49c737eafe10f Author: Christophe Leroy Date: Mon Nov 15 09:08:36 2021 +0100 powerpc/8xx: Fix pinned TLBs with CONFIG_STRICT_KERNEL_RWX commit 1e35eba4055149c578baf0318d2f2f89ea3c44a0 upstream. As spotted and explained in commit c12ab8dbc492 ("powerpc/8xx: Fix Oops with STRICT_KERNEL_RWX without DEBUG_RODATA_TEST"), the selection of STRICT_KERNEL_RWX without selecting DEBUG_RODATA_TEST has spotted the lack of the DIRTY bit in the pinned kernel data TLBs. This problem should have been detected a lot earlier if things had been working as expected. But due to an incredible level of chance or mishap, this went undetected because of a set of bugs: In fact the DTLBs were not pinned, because instead of setting the reserve bit in MD_CTR, it was set in MI_CTR that is the register for ITLBs. But then, another huge bug was there: the physical address was reset to 0 at the boundary between RO and RW areas, leading to the same physical space being mapped at both 0xc0000000 and 0xc8000000. This had by miracle no consequence until now because the entry was not really pinned so it was overwritten soon enough to go undetected. Of course, now that we really pin the DTLBs, it must be fixed as well. Fixes: f76c8f6d257c ("powerpc/8xx: Add function to set pinned TLBs") Cc: stable@vger.kernel.org # v5.8+ Signed-off-by: Christophe Leroy Depends-on: c12ab8dbc492 ("powerpc/8xx: Fix Oops with STRICT_KERNEL_RWX without DEBUG_RODATA_TEST") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/a21e9a057fe2d247a535aff0d157a54eefee017a.1636963688.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit 54e11a4e9df6f410a587f0ccdeac727f0ae8da1a Author: Cédric Le Goater Date: Tue Nov 16 14:40:22 2021 +0100 powerpc/xive: Change IRQ domain to a tree domain commit 8e80a73fa9a7747e3e8255cb149c543aabf65a24 upstream. Commit 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains exclusive") introduced an IRQ_DOMAIN_FLAG_NO_MAP flag to isolate the 'nomap' domains still in use under the powerpc arch. With this new flag, the revmap_tree of the IRQ domain is not used anymore. This change broke the support of shared LSIs [1] in the XIVE driver because it was relying on a lookup in the revmap_tree to query previously mapped interrupts. Linux now creates two distinct IRQ mappings on the same HW IRQ which can lead to unexpected behavior in the drivers. The XIVE IRQ domain is not a direct mapping domain and its HW IRQ interrupt number space is rather large : 1M/socket on POWER9 and POWER10, change the XIVE driver to use a 'tree' domain type instead. [1] For instance, a linux KVM guest with virtio-rng and virtio-balloon devices. Fixes: 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains exclusive") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Cédric Le Goater Tested-by: Greg Kurz Acked-by: Marc Zyngier Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211116134022.420412-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman commit 7cc16be1ae662a51f77c6a69f15a13e0555a5eae Author: Christophe Leroy Date: Mon Nov 15 09:52:55 2021 +0100 powerpc/signal32: Fix sigset_t copy commit 5499802b2284331788a440585869590f1bd63f7f upstream. The conversion from __copy_from_user() to __get_user() by commit d3ccc9781560 ("powerpc/signal: Use __get_user() to copy sigset_t") introduced a regression in __get_user_sigset() for powerpc/32. The bug was subsequently moved into unsafe_get_user_sigset(). The bug is due to the copied 64 bit value being truncated to 32 bits while being assigned to dst->sig[0] The regression was reported by users of the Xorg packages distributed in Debian/powerpc -- "The symptoms are that the fb screen goes blank, with the backlight remaining on and no errors logged in /var/log; wdm (or startx) run with no effect (I tried logging in in the blind, with no effect). And they are hard to kill, requiring 'kill -KILL ...'" Fix the regression by copying each word of the sigset, not only the first one. __get_user_sigset() was tentatively optimised to copy 64 bits at once in order to minimise KUAP unlock/lock impact, but the unsafe variant doesn't suffer that, so it can just copy words. Fixes: 887f3ceb51cd ("powerpc/signal32: Convert do_setcontext[_tm]() to user access block") Cc: stable@vger.kernel.org # v5.13+ Reported-by: Finn Thain Reported-and-tested-by: Stan Johnson Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/99ef38d61c0eb3f79c68942deb0c35995a93a777.1636966353.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit c897c53642b9c143639077f92f1cafd33a92b157 Author: David Woodhouse Date: Mon Nov 15 16:50:21 2021 +0000 KVM: x86/xen: Fix get_attr of KVM_XEN_ATTR_TYPE_SHARED_INFO commit 4e8436479ad3be76a3823e6ce466ae464ce71300 upstream. In commit 319afe68567b ("KVM: xen: do not use struct gfn_to_hva_cache") we stopped storing this in-kernel as a GPA, and started storing it as a GFN. Which means we probably should have stopped calling gpa_to_gfn() on it when userspace asks for it back. Cc: stable@vger.kernel.org Fixes: 319afe68567b ("KVM: xen: do not use struct gfn_to_hva_cache") Signed-off-by: David Woodhouse Message-Id: <20211115165030.7422-2-dwmw2@infradead.org> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b22ef13e8e3a2021acdac9a6e284e4824b408bc3 Author: Maxim Levitsky Date: Mon Nov 15 15:18:37 2021 +0200 KVM: x86/mmu: include EFER.LMA in extended mmu role commit b8453cdcf26020030da182f0156d7bf59ae5719f upstream. Incorporate EFER.LMA into kvm_mmu_extended_role, as it used to compute the guest root level and is not reflected in kvm_mmu_page_role.level when TDP is in use. When simply running the guest, it is impossible for EFER.LMA and kvm_mmu.root_level to get out of sync, as the guest cannot transition from PAE paging to 64-bit paging without toggling CR0.PG, i.e. without first bouncing through a different MMU context. And stuffing guest state via KVM_SET_SREGS{,2} also ensures a full MMU context reset. However, if KVM_SET_SREGS{,2} is followed by KVM_SET_NESTED_STATE, e.g. to set guest state when migrating the VM while L2 is active, the vCPU state will reflect L2, not L1. If L1 is using TDP for L2, then root_mmu will have been configured using L2's state, despite not being used for L2. If L2.EFER.LMA != L1.EFER.LMA, and L2 is using PAE paging, then root_mmu will be configured for guest PAE paging, but will match the mmu_role for 64-bit paging and cause KVM to not reconfigure root_mmu on the next nested VM-Exit. Alternatively, the root_mmu's role could be invalidated after a successful KVM_SET_NESTED_STATE that yields vcpu->arch.mmu != vcpu->arch.root_mmu, i.e. that switches the active mmu to guest_mmu, but doing so is unnecessarily tricky, and not even needed if L1 and L2 do have the same role (e.g., they are both 64-bit guests and run with the same CR4). Suggested-by: Sean Christopherson Signed-off-by: Maxim Levitsky Message-Id: <20211115131837.195527-3-mlevitsk@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c3168ef1f12d817759508b3efbefc467cf2c4cc6 Author: 黄乐 Date: Mon Nov 15 14:08:29 2021 +0000 KVM: x86: Fix uninitialized eoi_exit_bitmap usage in vcpu_load_eoi_exitmap() commit c5adbb3af051079f35abfa26551107e2c653087f upstream. In vcpu_load_eoi_exitmap(), currently the eoi_exit_bitmap[4] array is initialized only when Hyper-V context is available, in other path it is just passed to kvm_x86_ops.load_eoi_exitmap() directly from on the stack, which would cause unexpected interrupt delivery/handling issues, e.g. an *old* linux kernel that relies on PIT to do clock calibration on KVM might randomly fail to boot. Fix it by passing ioapic_handled_vectors to load_eoi_exitmap() when Hyper-V context is not available. Fixes: f2bc14b69c38 ("KVM: x86: hyper-v: Prepare to meet unallocated Hyper-V context") Cc: stable@vger.kernel.org Reviewed-by: Vitaly Kuznetsov Signed-off-by: Huang Le Message-Id: <62115b277dab49ea97da5633f8522daf@jd.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5969e2435cbd7f0ce8c28d717bfc39987ee8d8f1 Author: Tom Lendacky Date: Mon May 24 12:48:57 2021 -0500 KVM: x86: Assume a 64-bit hypercall for guests with protected state commit b5aead0064f33ae5e693a364e3204fe1c0ac9af2 upstream. When processing a hypercall for a guest with protected state, currently SEV-ES guests, the guest CS segment register can't be checked to determine if the guest is in 64-bit mode. For an SEV-ES guest, it is expected that communication between the guest and the hypervisor is performed to shared memory using the GHCB. In order to use the GHCB, the guest must have been in long mode, otherwise writes by the guest to the GHCB would be encrypted and not be able to be comprehended by the hypervisor. Create a new helper function, is_64_bit_hypercall(), that assumes the guest is in 64-bit mode when the guest has protected state, and returns true, otherwise invoking is_64_bit_mode() to determine the mode. Update the hypercall related routines to use is_64_bit_hypercall() instead of is_64_bit_mode(). Add a WARN_ON_ONCE() to is_64_bit_mode() to catch occurences of calls to this helper function for a guest running with protected state. Fixes: f1c6366e3043 ("KVM: SVM: Add required changes to support intercepts under SEV-ES") Reported-by: Sean Christopherson Signed-off-by: Tom Lendacky Message-Id: Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 8823ea27fff6084bbb4bc71d15378fae0220b1d8 Author: Sean Christopherson Date: Thu Nov 4 18:22:38 2021 +0000 x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails commit daf972118c517b91f74ff1731417feb4270625a4 upstream. Check for a valid hv_vp_index array prior to derefencing hv_vp_index when setting Hyper-V's TSC change callback. If Hyper-V setup failed in hyperv_init(), the kernel will still report that it's running under Hyper-V, but will have silently disabled nearly all functionality. BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:set_hv_tscchange_cb+0x15/0xa0 Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08 ... Call Trace: kvm_arch_init+0x17c/0x280 kvm_init+0x31/0x330 vmx_init+0xba/0x13a do_one_initcall+0x41/0x1c0 kernel_init_freeable+0x1f2/0x23b kernel_init+0x16/0x120 ret_from_fork+0x22/0x30 Fixes: 93286261de1b ("x86/hyperv: Reenlightenment notifications support") Cc: stable@vger.kernel.org Cc: Vitaly Kuznetsov Signed-off-by: Sean Christopherson Reviewed-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/20211104182239.1302956-2-seanjc@google.com Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit 60eec41ddb923468a530aa6ab7411b7c4765f501 Author: Reinette Chatre Date: Mon Nov 15 11:29:04 2021 -0800 x86/sgx: Fix free page accounting commit ac5d272a0ad0419f52e08c91953356e32b075af7 upstream. The SGX driver maintains a single global free page counter, sgx_nr_free_pages, that reflects the number of free pages available across all NUMA nodes. Correspondingly, a list of free pages is associated with each NUMA node and sgx_nr_free_pages is updated every time a page is added or removed from any of the free page lists. The main usage of sgx_nr_free_pages is by the reclaimer that runs when it (sgx_nr_free_pages) goes below a watermark to ensure that there are always some free pages available to, for example, support efficient page faults. With sgx_nr_free_pages accessed and modified from a few places it is essential to ensure that these accesses are done safely but this is not the case. sgx_nr_free_pages is read without any protection and updated with inconsistent protection by any one of the spin locks associated with the individual NUMA nodes. For example: CPU_A CPU_B ----- ----- spin_lock(&nodeA->lock); spin_lock(&nodeB->lock); ... ... sgx_nr_free_pages--; /* NOT SAFE */ sgx_nr_free_pages--; spin_unlock(&nodeA->lock); spin_unlock(&nodeB->lock); Since sgx_nr_free_pages may be protected by different spin locks while being modified from different CPUs, the following scenario is possible: CPU_A CPU_B ----- ----- {sgx_nr_free_pages = 100} spin_lock(&nodeA->lock); spin_lock(&nodeB->lock); sgx_nr_free_pages--; sgx_nr_free_pages--; /* LOAD sgx_nr_free_pages = 100 */ /* LOAD sgx_nr_free_pages = 100 */ /* sgx_nr_free_pages-- */ /* sgx_nr_free_pages-- */ /* STORE sgx_nr_free_pages = 99 */ /* STORE sgx_nr_free_pages = 99 */ spin_unlock(&nodeA->lock); spin_unlock(&nodeB->lock); In the above scenario, sgx_nr_free_pages is decremented from two CPUs but instead of sgx_nr_free_pages ending with a value that is two less than it started with, it was only decremented by one while the number of free pages were actually reduced by two. The consequence of sgx_nr_free_pages not being protected is that its value may not accurately reflect the actual number of free pages on the system, impacting the availability of free pages in support of many flows. The problematic scenario is when the reclaimer does not run because it believes there to be sufficient free pages while any attempt to allocate a page fails because there are no free pages available. In the SGX driver the reclaimer's watermark is only 32 pages so after encountering the above example scenario 32 times a user space hang is possible when there are no more free pages because of repeated page faults caused by no free pages made available. The following flow was encountered: asm_exc_page_fault ... sgx_vma_fault() sgx_encl_load_page() sgx_encl_eldu() // Encrypted page needs to be loaded from backing // storage into newly allocated SGX memory page sgx_alloc_epc_page() // Allocate a page of SGX memory __sgx_alloc_epc_page() // Fails, no free SGX memory ... if (sgx_should_reclaim(SGX_NR_LOW_PAGES)) // Wake reclaimer wake_up(&ksgxd_waitq); return -EBUSY; // Return -EBUSY giving reclaimer time to run return -EBUSY; return -EBUSY; return VM_FAULT_NOPAGE; The reclaimer is triggered in above flow with the following code: static bool sgx_should_reclaim(unsigned long watermark) { return sgx_nr_free_pages < watermark && !list_empty(&sgx_active_page_list); } In the problematic scenario there were no free pages available yet the value of sgx_nr_free_pages was above the watermark. The allocation of SGX memory thus always failed because of a lack of free pages while no free pages were made available because the reclaimer is never started because of sgx_nr_free_pages' incorrect value. The consequence was that user space kept encountering VM_FAULT_NOPAGE that caused the same address to be accessed repeatedly with the same result. Change the global free page counter to an atomic type that ensures simultaneous updates are done safely. While doing so, move the updating of the variable outside of the spin lock critical section to which it does not belong. Cc: stable@vger.kernel.org Fixes: 901ddbb9ecf5 ("x86/sgx: Add a basic NUMA allocation scheme to sgx_alloc_epc_page()") Suggested-by: Dave Hansen Signed-off-by: Reinette Chatre Signed-off-by: Dave Hansen Reviewed-by: Tony Luck Acked-by: Jarkko Sakkinen Link: https://lkml.kernel.org/r/a95a40743bbd3f795b465f30922dde7f1ea9e0eb.1637004094.git.reinette.chatre@intel.com Signed-off-by: Greg Kroah-Hartman commit 2495decce774389f60d1942ba647f691f50f575e Author: Borislav Petkov Date: Fri Nov 5 10:41:51 2021 +0100 x86/boot: Pull up cmdline preparation and early param parsing commit 8d48bf8206f77aa8687f0e241e901e5197e52423 upstream. Dan reports that Anjaneya Chagam can no longer use the efi=nosoftreserve kernel command line parameter to suppress "soft reservation" behavior. This is due to the fact that the following call-chain happens at boot: early_reserve_memory |-> efi_memblock_x86_reserve_range |-> efi_fake_memmap_early which does if (!efi_soft_reserve_enabled()) return; and that would have set EFI_MEM_NO_SOFT_RESERVE after having parsed "nosoftreserve". However, parse_early_param() gets called *after* it, leading to the boot cmdline not being taken into account. Therefore, carve out the command line preparation into a separate function which does the early param parsing too. So that it all goes together. And then call that function before early_reserve_memory() so that the params would have been parsed by then. Fixes: 8aa83e6395ce ("x86/setup: Call early_reserve_memory() earlier") Reported-by: Dan Williams Reviewed-by: Dan Williams Signed-off-by: Borislav Petkov Tested-by: Anjaneya Chagam Cc: Link: https://lore.kernel.org/r/e8dd8993c38702ee6dd73b3c11f158617e665607.camel@intel.com Signed-off-by: Greg Kroah-Hartman commit 1e0d346be1cc1f987ce63ecfd1a27593408f6b61 Author: SeongJae Park Date: Fri Nov 19 16:43:52 2021 -0800 mm/damon/dbgfs: fix missed use of damon_dbgfs_lock commit d78f3853f831eee46c6dbe726debf3be9e9c0d05 upstream. DAMON debugfs is supposed to protect dbgfs_ctxs, dbgfs_nr_ctxs, and dbgfs_dirs using damon_dbgfs_lock. However, some of the code is accessing the variables without the protection. This fixes it by protecting all such accesses. Link: https://lkml.kernel.org/r/20211110145758.16558-3-sj@kernel.org Fixes: 75c1c2b53c78 ("mm/damon/dbgfs: support multiple contexts") Signed-off-by: SeongJae Park Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cda10b34ecfb27935f4a4dad0d0cb1f6405747b4 Author: SeongJae Park Date: Fri Nov 19 16:43:49 2021 -0800 mm/damon/dbgfs: use '__GFP_NOWARN' for user-specified size buffer allocation commit db7a347b26fe05d2e8c115bb24dfd908d0252bc3 upstream. Patch series "DAMON fixes". This patch (of 2): DAMON users can trigger below warning in '__alloc_pages()' by invoking write() to some DAMON debugfs files with arbitrarily high count argument, because DAMON debugfs interface allocates some buffers based on the user-specified 'count'. if (unlikely(order >= MAX_ORDER)) { WARN_ON_ONCE(!(gfp & __GFP_NOWARN)); return NULL; } Because the DAMON debugfs interface code checks failure of the 'kmalloc()', this commit simply suppresses the warnings by adding '__GFP_NOWARN' flag. Link: https://lkml.kernel.org/r/20211110145758.16558-1-sj@kernel.org Link: https://lkml.kernel.org/r/20211110145758.16558-2-sj@kernel.org Fixes: 4bc05954d007 ("mm/damon: implement a debugfs-based user space interface") Signed-off-by: SeongJae Park Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4dfddb52abc205fa86c9528ed5eadce7da5abcba Author: Ard Biesheuvel Date: Fri Nov 19 16:43:55 2021 -0800 kmap_local: don't assume kmap PTEs are linear arrays in memory commit 825c43f50e3aa811a291ffcb40e02fbf6d91ba86 upstream. The kmap_local conversion broke the ARM architecture, because the new code assumes that all PTEs used for creating kmaps form a linear array in memory, and uses array indexing to look up the kmap PTE belonging to a certain kmap index. On ARM, this cannot work, not only because the PTE pages may be non-adjacent in memory, but also because ARM/!LPAE interleaves hardware entries and extended entries (carrying software-only bits) in a way that is not compatible with array indexing. Fortunately, this only seems to affect configurations with more than 8 CPUs, due to the way the per-CPU kmap slots are organized in memory. Work around this by permitting an architecture to set a Kconfig symbol that signifies that the kmap PTEs do not form a lineary array in memory, and so the only way to locate the appropriate one is to walk the page tables. Link: https://lore.kernel.org/linux-arm-kernel/20211026131249.3731275-1-ardb@kernel.org/ Link: https://lkml.kernel.org/r/20211116094737.7391-1-ardb@kernel.org Fixes: 2a15ba82fa6c ("ARM: highmem: Switch to generic kmap atomic") Signed-off-by: Ard Biesheuvel Reported-by: Quanyang Wang Reviewed-by: Linus Walleij Acked-by: Russell King (Oracle) Cc: Thomas Gleixner Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b5069d44e2fbc4a9093d005b3ef0949add3dd27e Author: Mina Almasry Date: Fri Nov 19 16:43:43 2021 -0800 hugetlb, userfaultfd: fix reservation restore on userfaultfd error commit cc30042df6fcc82ea18acf0dace831503e60a0b7 upstream. Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we bail out using "goto out_release_unlock;" in the cases where idx >= size, or !huge_pte_none(), the code will detect that new_pagecache_page == false, and so call restore_reserve_on_error(). In this case I see restore_reserve_on_error() delete the reservation, and the following call to remove_inode_hugepages() will increment h->resv_hugepages causing a 100% reproducible leak. We should treat the is_continue case similar to adding a page into the pagecache and set new_pagecache_page to true, to indicate that there is no reservation to restore on the error path, and we need not call restore_reserve_on_error(). Rename new_pagecache_page to page_in_pagecache to make that clear. Link: https://lkml.kernel.org/r/20211117193825.378528-1-almasrymina@google.com Fixes: c7b1850dfb41 ("hugetlb: don't pass page cache pages to restore_reserve_on_error") Signed-off-by: Mina Almasry Reported-by: James Houghton Reviewed-by: Mike Kravetz Cc: Wei Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 11138d734963e089a3a2797f2d761ad25efdbb19 Author: Rustam Kovhaev Date: Fri Nov 19 16:43:37 2021 -0800 mm: kmemleak: slob: respect SLAB_NOLEAKTRACE flag commit 34dbc3aaf5d9e89ba6cc5e24add9458c21ab1950 upstream. When kmemleak is enabled for SLOB, system does not boot and does not print anything to the console. At the very early stage in the boot process we hit infinite recursion from kmemleak_init() and eventually kernel crashes. kmemleak_init() specifies SLAB_NOLEAKTRACE for KMEM_CACHE(), but kmem_cache_create_usercopy() removes it because CACHE_CREATE_MASK is not valid for SLOB. Let's fix CACHE_CREATE_MASK and make kmemleak work with SLOB Link: https://lkml.kernel.org/r/20211115020850.3154366-1-rkovhaev@gmail.com Fixes: d8843922fba4 ("slab: Ignore internal flags in cache creation") Signed-off-by: Rustam Kovhaev Acked-by: Vlastimil Babka Reviewed-by: Muchun Song Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Catalin Marinas Cc: Greg Kroah-Hartman Cc: Glauber Costa Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e73114d9334e83fa1fd0b30f624b784ef654c055 Author: Alexander Mikhalitsyn Date: Fri Nov 19 16:43:21 2021 -0800 shm: extend forced shm destroy to support objects from several IPC nses commit 85b6d24646e4125c591639841169baa98a2da503 upstream. Currently, the exit_shm() function not designed to work properly when task->sysvshm.shm_clist holds shm objects from different IPC namespaces. This is a real pain when sysctl kernel.shm_rmid_forced = 1, because it leads to use-after-free (reproducer exists). This is an attempt to fix the problem by extending exit_shm mechanism to handle shm's destroy from several IPC ns'es. To achieve that we do several things: 1. add a namespace (non-refcounted) pointer to the struct shmid_kernel 2. during new shm object creation (newseg()/shmget syscall) we initialize this pointer by current task IPC ns 3. exit_shm() fully reworked such that it traverses over all shp's in task->sysvshm.shm_clist and gets IPC namespace not from current task as it was before but from shp's object itself, then call shm_destroy(shp, ns). Note: We need to be really careful here, because as it was said before (1), our pointer to IPC ns non-refcnt'ed. To be on the safe side we using special helper get_ipc_ns_not_zero() which allows to get IPC ns refcounter only if IPC ns not in the "state of destruction". Q/A Q: Why can we access shp->ns memory using non-refcounted pointer? A: Because shp object lifetime is always shorther than IPC namespace lifetime, so, if we get shp object from the task->sysvshm.shm_clist while holding task_lock(task) nobody can steal our namespace. Q: Does this patch change semantics of unshare/setns/clone syscalls? A: No. It's just fixes non-covered case when process may leave IPC namespace without getting task->sysvshm.shm_clist list cleaned up. Link: https://lkml.kernel.org/r/67bb03e5-f79c-1815-e2bf-949c67047418@colorfullife.com Link: https://lkml.kernel.org/r/20211109151501.4921-1-manfred@colorfullife.com Fixes: ab602f79915 ("shm: make exit_shm work proportional to task activity") Co-developed-by: Manfred Spraul Signed-off-by: Manfred Spraul Signed-off-by: Alexander Mikhalitsyn Cc: "Eric W. Biederman" Cc: Davidlohr Bueso Cc: Greg KH Cc: Andrei Vagin Cc: Pavel Tikhomirov Cc: Vasily Averin Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 72bfd835ae7151d343f814a5c3359be5afc10a3e Author: Alexander Mikhalitsyn Date: Fri Nov 19 16:43:18 2021 -0800 ipc: WARN if trying to remove ipc object which is absent commit 126e8bee943e9926238c891e2df5b5573aee76bc upstream. Patch series "shm: shm_rmid_forced feature fixes". Some time ago I met kernel crash after CRIU restore procedure, fortunately, it was CRIU restore, so, I had dump files and could do restore many times and crash reproduced easily. After some investigation I've constructed the minimal reproducer. It was found that it's use-after-free and it happens only if sysctl kernel.shm_rmid_forced = 1. The key of the problem is that the exit_shm() function not handles shp's object destroy when task->sysvshm.shm_clist contains items from different IPC namespaces. In most cases this list will contain only items from one IPC namespace. How can this list contain object from different namespaces? The exit_shm() function is designed to clean up this list always when process leaves IPC namespace. But we made a mistake a long time ago and did not add a exit_shm() call into the setns() syscall procedures. The first idea was just to add this call to setns() syscall but it obviously changes semantics of setns() syscall and that's userspace-visible change. So, I gave up on this idea. The first real attempt to address the issue was just to omit forced destroy if we meet shp object not from current task IPC namespace [1]. But that was not the best idea because task->sysvshm.shm_clist was protected by rwsem which belongs to current task IPC namespace. It means that list corruption may occur. Second approach is just extend exit_shm() to properly handle shp's from different IPC namespaces [2]. This is really non-trivial thing, I've put a lot of effort into that but not believed that it's possible to make it fully safe, clean and clear. Thanks to the efforts of Manfred Spraul working an elegant solution was designed. Thanks a lot, Manfred! Eric also suggested the way to address the issue in ("[RFC][PATCH] shm: In shm_exit destroy all created and never attached segments") Eric's idea was to maintain a list of shm_clists one per IPC namespace, use lock-less lists. But there is some extra memory consumption-related concerns. An alternative solution which was suggested by me was implemented in ("shm: reset shm_clist on setns but omit forced shm destroy"). The idea is pretty simple, we add exit_shm() syscall to setns() but DO NOT destroy shm segments even if sysctl kernel.shm_rmid_forced = 1, we just clean up the task->sysvshm.shm_clist list. This chages semantics of setns() syscall a little bit but in comparision to the "naive" solution when we just add exit_shm() without any special exclusions this looks like a safer option. [1] https://lkml.org/lkml/2021/7/6/1108 [2] https://lkml.org/lkml/2021/7/14/736 This patch (of 2): Let's produce a warning if we trying to remove non-existing IPC object from IPC namespace kht/idr structures. This allows us to catch possible bugs when the ipc_rmid() function was called with inconsistent struct ipc_ids*, struct kern_ipc_perm* arguments. Link: https://lkml.kernel.org/r/20211027224348.611025-1-alexander.mikhalitsyn@virtuozzo.com Link: https://lkml.kernel.org/r/20211027224348.611025-2-alexander.mikhalitsyn@virtuozzo.com Co-developed-by: Manfred Spraul Signed-off-by: Manfred Spraul Signed-off-by: Alexander Mikhalitsyn Cc: "Eric W. Biederman" Cc: Davidlohr Bueso Cc: Greg KH Cc: Andrei Vagin Cc: Pavel Tikhomirov Cc: Vasily Averin Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9404c4145542c23019a80ab1bb2ecf73cd057b10 Author: Tadeusz Struk Date: Mon Nov 15 08:01:43 2021 -0800 tipc: check for null after calling kmemdup commit 3e6db079751afd527bf3db32314ae938dc571916 upstream. kmemdup can return a null pointer so need to check for it, otherwise the null key will be dereferenced later in tipc_crypto_key_xmit as can be seen in the trace [1]. Cc: tipc-discussion@lists.sourceforge.net Cc: stable@vger.kernel.org # 5.15, 5.14, 5.10 [1] https://syzkaller.appspot.com/bug?id=bca180abb29567b189efdbdb34cbf7ba851c2a58 Reported-by: Dmitry Vyukov Signed-off-by: Tadeusz Struk Acked-by: Ying Xue Acked-by: Jon Maloy Link: https://lore.kernel.org/r/20211115160143.5099-1-tadeusz.struk@linaro.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 660859f0158c55f9ad4d4d58ea230c2535b9c0fe Author: Nathan Chancellor Date: Fri Nov 19 16:43:31 2021 -0800 hexagon: clean up timer-regs.h commit 51f2ec593441d3d1ebc0d478fac3ea329c7c93ac upstream. When building allmodconfig, there is a warning about TIMER_ENABLE being redefined: drivers/clocksource/timer-oxnas-rps.c:39:9: error: 'TIMER_ENABLE' macro redefined [-Werror,-Wmacro-redefined] #define TIMER_ENABLE BIT(7) ^ arch/hexagon/include/asm/timer-regs.h:13:9: note: previous definition is here #define TIMER_ENABLE 0 ^ 1 error generated. The values in this header are only used in one file each, if they are used at all. Remove the header and sink all of the constants into their respective files. TCX0_CLK_RATE is only used in arch/hexagon/include/asm/timex.h TIMER_ENABLE, RTOS_TIMER_INT, RTOS_TIMER_REGS_ADDR are only used in arch/hexagon/kernel/time.c. SLEEP_CLK_RATE and TIMER_CLR_ON_MATCH have both been unused since the file's introduction in commit 71e4a47f32f4 ("Hexagon: Add time and timer functions"). TIMER_ENABLE is redefined as BIT(0) so the shift is moved into the definition, rather than its use. Link: https://lkml.kernel.org/r/20211115174250.1994179-3-nathan@kernel.org Signed-off-by: Nathan Chancellor Acked-by: Brian Cain Cc: Nick Desaulniers Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c0247013173ccc30119ee1dbdab87502bc2783b4 Author: Nathan Chancellor Date: Fri Nov 19 16:43:28 2021 -0800 hexagon: export raw I/O routines for modules commit ffb92ce826fd801acb0f4e15b75e4ddf0d189bde upstream. Patch series "Fixes for ARCH=hexagon allmodconfig", v2. This series fixes some issues noticed with ARCH=hexagon allmodconfig. This patch (of 3): When building ARCH=hexagon allmodconfig, the following errors occur: ERROR: modpost: "__raw_readsl" [drivers/i3c/master/svc-i3c-master.ko] undefined! ERROR: modpost: "__raw_writesl" [drivers/i3c/master/dw-i3c-master.ko] undefined! ERROR: modpost: "__raw_readsl" [drivers/i3c/master/dw-i3c-master.ko] undefined! ERROR: modpost: "__raw_writesl" [drivers/i3c/master/i3c-master-cdns.ko] undefined! ERROR: modpost: "__raw_readsl" [drivers/i3c/master/i3c-master-cdns.ko] undefined! Export these symbols so that modules can use them without any errors. Link: https://lkml.kernel.org/r/20211115174250.1994179-1-nathan@kernel.org Link: https://lkml.kernel.org/r/20211115174250.1994179-2-nathan@kernel.org Fixes: 013bf24c3829 ("Hexagon: Provide basic implementation and/or stubs for I/O routines.") Signed-off-by: Nathan Chancellor Acked-by: Brian Cain Cc: Nick Desaulniers Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 17071fdcd01d245e65742da09e45ed8bdb9fd4b4 Author: Geert Uytterhoeven Date: Thu Nov 18 10:26:21 2021 -0800 pstore/blk: Use "%lu" to format unsigned long commit 61eb495c83bf6ebde490992bf888ca15b9babc39 upstream. On 32-bit: fs/pstore/blk.c: In function ‘__best_effort_init’: include/linux/kern_levels.h:5:18: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 3 has type ‘long unsigned int’ [-Wformat=] 5 | #define KERN_SOH "\001" /* ASCII Start Of Header */ | ^~~~~~ include/linux/kern_levels.h:14:19: note: in expansion of macro ‘KERN_SOH’ 14 | #define KERN_INFO KERN_SOH "6" /* informational */ | ^~~~~~~~ include/linux/printk.h:373:9: note: in expansion of macro ‘KERN_INFO’ 373 | printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__) | ^~~~~~~~~ fs/pstore/blk.c:314:3: note: in expansion of macro ‘pr_info’ 314 | pr_info("attached %s (%zu) (no dedicated panic_write!)\n", | ^~~~~~~ Cc: stable@vger.kernel.org Fixes: 7bb9557b48fcabaa ("pstore/blk: Use the normal block device I/O path") Signed-off-by: Geert Uytterhoeven Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210629103700.1935012-1-geert@linux-m68k.org Cc: Jens Axboe Reviewed-by: Christoph Hellwig Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 007ebe2d61d4d3542ad8a0b4da47ee420a15bac6 Author: Kees Cook Date: Tue Nov 16 10:15:59 2021 -0800 Revert "mark pstore-blk as broken" commit d1faacbf67b1944f0e0c618dc581d929263f6fe9 upstream. This reverts commit d07f3b081ee632268786601f55e1334d1f68b997. pstore-blk was fixed to avoid the unwanted APIs in commit 7bb9557b48fc ("pstore/blk: Use the normal block device I/O path"), which landed in the same release as the commit adding BROKEN. Cc: Jens Axboe Cc: Christoph Hellwig Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20211116181559.3975566-1-keescook@chromium.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a705254c71fd35191659ab8c69a50b15894dad0d Author: Nicolas Dichtel Date: Fri Nov 12 08:56:03 2021 +0100 tun: fix bonding active backup with arp monitoring commit a31d27fbed5d518734cb60956303eb15089a7634 upstream. As stated in the bonding doc, trans_start must be set manually for drivers using NETIF_F_LLTX: Drivers that use NETIF_F_LLTX flag must also update netdev_queue->trans_start. If they do not, then the ARP monitor will immediately fail any slaves using that driver, and those slaves will stay down. Link: https://www.kernel.org/doc/html/v5.15/networking/bonding.html#arp-monitor-operation Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9e6b4c36e9ac59e604121d660d78e9bc7789f658 Author: Arnd Bergmann Date: Mon Sep 20 14:20:07 2021 +0200 dmaengine: remove debugfs #ifdef commit b3b180e735409ca0c76642014304b59482e0e653 upstream. The ptdma driver has added debugfs support, but this fails to build when debugfs is disabled: drivers/dma/ptdma/ptdma-debugfs.c: In function 'ptdma_debugfs_setup': drivers/dma/ptdma/ptdma-debugfs.c:93:54: error: 'struct dma_device' has no member named 'dbg_dev_root' 93 | debugfs_create_file("info", 0400, pt->dma_dev.dbg_dev_root, pt, | ^ drivers/dma/ptdma/ptdma-debugfs.c:96:55: error: 'struct dma_device' has no member named 'dbg_dev_root' 96 | debugfs_create_file("stats", 0400, pt->dma_dev.dbg_dev_root, pt, | ^ drivers/dma/ptdma/ptdma-debugfs.c:102:52: error: 'struct dma_device' has no member named 'dbg_dev_root' 102 | debugfs_create_dir("q", pt->dma_dev.dbg_dev_root); | ^ Remove the #ifdef in the header, as this only saves a few bytes, but would require ugly #ifdefs in each driver using it. Simplify the other user while we're at it. Fixes: e2fb2e2a33fa ("dmaengine: ptdma: Add debugfs entries for PTDMA") Fixes: 26cf132de6f7 ("dmaengine: Create debug directories for DMA devices") Signed-off-by: Arnd Bergmann Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20210920122017.205975-1-arnd@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 6ffad92d05b0702f349f0df7e52183a3c4a91b8d Author: Yu Kuai Date: Tue Nov 2 10:07:05 2021 +0800 blk-cgroup: fix missing put device in error path from blkg_conf_pref() [ Upstream commit 15c30104965101b8e76b24d27035569d6613a7d6 ] If blk_queue_enter() failed due to queue is dying, the blkdev_put_no_open() is needed because blkcg_conf_open_bdev() succeeded. Fixes: 0c9d338c8443 ("blk-cgroup: synchronize blkg creation against policy deactivation") Signed-off-by: Yu Kuai Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20211102020705.2321858-1-yukuai3@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4220cc6e113caa126ddca8eeb796c213cb492e0e Author: Heiko Carstens Date: Tue Nov 16 11:06:38 2021 +0100 s390/kexec: fix return code handling [ Upstream commit 20c76e242e7025bd355619ba67beb243ba1a1e95 ] kexec_file_add_ipl_report ignores that ipl_report_finish may fail and can return an error pointer instead of a valid pointer. Fix this and simplify by returning NULL in case of an error and let the only caller handle this case. Fixes: 99feaa717e55 ("s390/kexec_file: Create ipl report and pass to next kernel") Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 737143025c18b077271bd7bc3cfdabbc6adf1944 Author: Alexander Antonov Date: Mon Nov 15 12:03:34 2021 +0300 perf/x86/intel/uncore: Fix IIO event constraints for Snowridge [ Upstream commit bdc0feee05174418dec1fa68de2af19e1750b99f ] According to the latest uncore document, DATA_REQ_OF_CPU (0x83), DATA_REQ_BY_CPU (0xc0) and COMP_BUF_OCCUPANCY (0xd5) events have constraints. Add uncore IIO constraints for Snowridge. Fixes: 210cc5f9db7a ("perf/x86/intel/uncore: Add uncore support for Snow Ridge server") Signed-off-by: Alexander Antonov Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20211115090334.3789-4-alexander.antonov@linux.intel.com Signed-off-by: Sasha Levin commit d55aa2391d01f65eac6984199963ec9a297cda13 Author: Alexander Antonov Date: Mon Nov 15 12:03:33 2021 +0300 perf/x86/intel/uncore: Fix IIO event constraints for Skylake Server [ Upstream commit 3866ae319c846a612109c008f43cba80b8c15e86 ] According to the latest uncore document, COMP_BUF_OCCUPANCY (0xd5) event can be collected on 2-3 counters. Update uncore IIO event constraints for Skylake Server. Fixes: cd34cd97b7b4 ("perf/x86/intel/uncore: Add Skylake server uncore support") Signed-off-by: Alexander Antonov Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20211115090334.3789-3-alexander.antonov@linux.intel.com Signed-off-by: Sasha Levin commit 7955e4aca73f7b0f3c83c56114bd419e3d64e3d6 Author: Alexander Antonov Date: Mon Nov 15 12:03:32 2021 +0300 perf/x86/intel/uncore: Fix filter_tid mask for CHA events on Skylake Server [ Upstream commit e324234e0aa881b7841c7c713306403e12b069ff ] According Uncore Reference Manual: any of the CHA events may be filtered by Thread/Core-ID by using tid modifier in CHA Filter 0 Register. Update skx_cha_hw_config() to follow Uncore Guide. Fixes: cd34cd97b7b4 ("perf/x86/intel/uncore: Add Skylake server uncore support") Signed-off-by: Alexander Antonov Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20211115090334.3789-2-alexander.antonov@linux.intel.com Signed-off-by: Sasha Levin commit db66f2829caa82cebafba9d7b6b8d31db45bec7f Author: Bjorn Andersson Date: Thu Nov 4 10:08:35 2021 -0700 pinctrl: qcom: sm8350: Correct UFS and SDC offsets [ Upstream commit 62209e805b5c68577602a5803a71d8e2e11ee0d3 ] The downstream TLMM binding covers a group of TLMM-related hardware blocks, but the upstream binding only captures the particular block related to controlling the TLMM pins from an OS. In the translation of the driver from downstream, the offset of 0x100000 was lost for the UFS and SDC pingroups. Fixes: d5d348a3271f ("pinctrl: qcom: Add SM8350 pinctrl driver") Signed-off-by: Bjorn Andersson Reviewed-by: Vinod Koul Reviewed-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20211104170835.1993686-1-bjorn.andersson@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 13d31d416cb30daebd47d61e42ef4a99312e06ff Author: Bjorn Andersson Date: Mon Nov 1 22:41:15 2021 -0500 pinctrl: qcom: sdm845: Enable dual edge errata [ Upstream commit 3a3a100473d2f6ebf9bdfe6efedd7e18de724388 ] It has been observed that dual edge triggered wakeirq GPIOs on SDM845 doesn't trigger interrupts on the falling edge. Enabling wakeirq_dual_edge_errata for SDM845 indicates that the PDC in SDM845 suffers from the same problem described, and worked around, by Doug in 'c3c0c2e18d94 ("pinctrl: qcom: Handle broken/missing PDC dual edge IRQs on sc7180")', so enable the workaround for SDM845 as well. The specific problem seen without this is that gpio-keys does not detect the falling edge of the LID gpio on the Lenovo Yoga C630 and as such consistently reports the LID as closed. Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy") Signed-off-by: Bjorn Andersson Tested-By: Steev Klimaszewski Reviewed-by: Douglas Anderson Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20211102034115.1946036-1-bjorn.andersson@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ad03b901d03be6927938d99c55b2d2d3db0e3bba Author: Nicholas Piggin Date: Tue Nov 9 16:49:00 2021 +1000 powerpc/pseries: Fix numa FORM2 parsing fallback code [ Upstream commit 302039466f6a3b9421ecb9a6a2c528801dc24a86 ] In case the FORM2 distance table from firmware is not the expected size, there is fallback code that just populates the lookup table as local vs remote. However it then continues on to use the distance table. Fix. Fixes: 1c6b5a7e7405 ("powerpc/pseries: Add support for FORM2 associativity") Signed-off-by: Nicholas Piggin Reviewed-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211109064900.2041386-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit ad9ade6c946ee484589081c2b324935caf1ea8b1 Author: Nicholas Piggin Date: Tue Nov 9 16:48:59 2021 +1000 powerpc/pseries: rename numa_dist_table to form2_distances [ Upstream commit 0bd81274e3f1195ee7c820ef02d62f31077c42c3 ] The name of the local variable holding the "form2" property address conflicts with the numa_distance_table global. This patch does 's/numa_dist_table/form2_distances/g' over the function, which also renames numa_dist_table_length to form2_distances_length. Suggested-by: Michael Ellerman Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211109064900.2041386-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit a0995ebe4e1f2aaa3219af076d6e9ed1c2ca9eb3 Author: Masahiro Yamada Date: Wed Nov 10 03:50:15 2021 +0900 powerpc: clean vdso32 and vdso64 directories [ Upstream commit 964c33cd0be621b291b5d253d8731eb2680082cb ] Since commit bce74491c300 ("powerpc/vdso: fix unnecessary rebuilds of vgettimeofday.o"), "make ARCH=powerpc clean" does not clean up the arch/powerpc/kernel/{vdso32,vdso64} directories. Use the subdir- trick to let "make clean" descend into them. Fixes: bce74491c300 ("powerpc/vdso: fix unnecessary rebuilds of vgettimeofday.o") Signed-off-by: Masahiro Yamada Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211109185015.615517-1-masahiroy@kernel.org Signed-off-by: Sasha Levin commit a7e7002571358f5e646b56dd4106b99e4d688d4e Author: Michael Ellerman Date: Fri Sep 24 01:10:31 2021 +1000 KVM: PPC: Book3S HV: Use GLOBAL_TOC for kvmppc_h_set_dabr/xdabr() [ Upstream commit dae581864609d36fb58855fd59880b4941ce9d14 ] kvmppc_h_set_dabr(), and kvmppc_h_set_xdabr() which jumps into it, need to use _GLOBAL_TOC to setup the kernel TOC pointer, because kvmppc_h_set_dabr() uses LOAD_REG_ADDR() to load dawr_force_enable. When called from hcall_try_real_mode() we have the kernel TOC in r2, established near the start of kvmppc_interrupt_hv(), so there is no issue. But they can also be called from kvmppc_pseries_do_hcall() which is module code, so the access ends up happening with the kvm-hv module's r2, which will not point at dawr_force_enable and could even cause a fault. With the current code layout and compilers we haven't observed a fault in practice, the load hits somewhere in kvm-hv.ko and silently returns some bogus value. Note that we we expect p8/p9 guests to use the DAWR, but SLOF uses h_set_dabr() to test if sc1 works correctly, see SLOF's lib/libhvcall/brokensc1.c. Fixes: c1fe190c0672 ("powerpc: Add force enable of DAWR on P9 option") Signed-off-by: Michael Ellerman Reviewed-by: Daniel Axtens Link: https://lore.kernel.org/r/20210923151031.72408-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 9c2ff78cf833eaf3a9fbfdab3ddf0058f048bc34 Author: Andreas Schwab Date: Tue Nov 2 16:51:43 2021 +0100 riscv: fix building external modules [ Upstream commit 5a19c7e06236a9c55dfc001bb4d1a8f1950d23e7 ] When building external modules, vdso_prepare should not be run. If the kernel sources are read-only, it will fail. Fixes: fde9c59aebaf ("riscv: explicitly use symbol offsets for VDSO") Signed-off-by: Andreas Schwab Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 35d97fd89c127f0deadcb41fe64f013b9b4abeda Author: Arnaldo Carvalho de Melo Date: Wed Nov 17 14:29:31 2021 -0300 tools build: Fix removal of feature-sync-compare-and-swap feature detection [ Upstream commit e8c04ea0fef5731dbcaabac86d65254c227aedf4 ] The patch removing the feature-sync-compare-and-swap feature detection didn't remove the call to main_test_sync_compare_and_swap(), making the 'test-all' case fail an all the feature tests to be performed individually: $ cat /tmp/build/perf/feature/test-all.make.output In file included from test-all.c:18: test-libpython-version.c:5:10: error: #error 5 | #error | ^~~~~ test-all.c: In function ‘main’: test-all.c:203:9: error: implicit declaration of function ‘main_test_sync_compare_and_swap’ [-Werror=implicit-function-declaration] 203 | main_test_sync_compare_and_swap(argc, argv); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors $ Fix it, now to figure out what is that test-libpython-version.c problem... Fixes: 60fa754b2a5a4e0c ("tools: Remove feature-sync-compare-and-swap feature detection") Cc: Jiri Olsa Cc: Leo Yan Cc: Mark Rutland Cc: Mathieu Poirier Cc: Mike Leach Cc: Namhyung Kim Link: https://lore.kernel.org/lkml/YZU9Fe0sgkHSXeC2@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 20540cb666a6f0d218d29bc0c6fb371cd64fad8c Author: Dan Carpenter Date: Thu Nov 18 14:22:11 2021 +0300 ptp: ocp: Fix a couple NULL vs IS_ERR() checks [ Upstream commit c7521d3aa2fa7fc785682758c99b5bcae503f6be ] The ptp_ocp_get_mem() function does not return NULL, it returns error pointers. Fixes: 773bda964921 ("ptp: ocp: Expose various resources on the timecard.") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4d42da0c86b87de11da775b7994fbc1cea4d63b1 Author: Jesse Brandeburg Date: Wed Nov 17 12:59:52 2021 -0800 e100: fix device suspend/resume [ Upstream commit 5d2ca2e12dfb2aff3388ca57b06f570fa6206ced ] As reported in [1], e100 was no longer working for suspend/resume cycles. The previous commit mentioned in the fixes appears to have broken things and this attempts to practice best known methods for device power management and keep wake-up working while allowing suspend/resume to work. To do this, I reorder a little bit of code and fix the resume path to make sure the device is enabled. [1] https://bugzilla.kernel.org/show_bug.cgi?id=214933 Fixes: 69a74aef8a18 ("e100: use generic power management") Cc: Vaibhav Gupta Reported-by: Alexey Kuznetsov Signed-off-by: Jesse Brandeburg Tested-by: Alexey Kuznetsov Signed-off-by: Tony Nguyen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ed35e950d8e5658db5b45526be2c4e3778746909 Author: Lin Ma Date: Tue Nov 16 23:27:32 2021 +0800 NFC: add NCI_UNREG flag to eliminate the race [ Upstream commit 48b71a9e66c2eab60564b1b1c85f4928ed04e406 ] There are two sites that calls queue_work() after the destroy_workqueue() and lead to possible UAF. The first site is nci_send_cmd(), which can happen after the nci_close_device as below nfcmrvl_nci_unregister_dev | nfc_genl_dev_up nci_close_device | flush_workqueue | del_timer_sync | nci_unregister_device | nfc_get_device destroy_workqueue | nfc_dev_up nfc_unregister_device | nci_dev_up device_del | nci_open_device | __nci_request | nci_send_cmd | queue_work !!! Another site is nci_cmd_timer, awaked by the nci_cmd_work from the nci_send_cmd. ... | ... nci_unregister_device | queue_work destroy_workqueue | nfc_unregister_device | ... device_del | nci_cmd_work | mod_timer | ... | nci_cmd_timer | queue_work !!! For the above two UAF, the root cause is that the nfc_dev_up can race between the nci_unregister_device routine. Therefore, this patch introduce NCI_UNREG flag to easily eliminate the possible race. In addition, the mutex_lock in nci_close_device can act as a barrier. Signed-off-by: Lin Ma Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") Reviewed-by: Jakub Kicinski Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20211116152732.19238-1-linma@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8a9c61c3ef187d8891225f9b932390670a43a0d3 Author: Lin Ma Date: Tue Nov 16 23:26:52 2021 +0800 NFC: reorder the logic in nfc_{un,}register_device [ Upstream commit 3e3b5dfcd16a3e254aab61bd1e8c417dd4503102 ] There is a potential UAF between the unregistration routine and the NFC netlink operations. The race that cause that UAF can be shown as below: (FREE) | (USE) nfcmrvl_nci_unregister_dev | nfc_genl_dev_up nci_close_device | nci_unregister_device | nfc_get_device nfc_unregister_device | nfc_dev_up rfkill_destory | device_del | rfkill_blocked ... | ... The root cause for this race is concluded below: 1. The rfkill_blocked (USE) in nfc_dev_up is supposed to be placed after the device_is_registered check. 2. Since the netlink operations are possible just after the device_add in nfc_register_device, the nfc_dev_up() can happen anywhere during the rfkill creation process, which leads to data race. This patch reorder these actions to permit 1. Once device_del is finished, the nfc_dev_up cannot dereference the rfkill object. 2. The rfkill_register need to be placed after the device_add of nfc_dev because the parent device need to be created first. So this patch keeps the order but inject device_lock to prevent the data race. Signed-off-by: Lin Ma Fixes: be055b2f89b5 ("NFC: RFKILL support") Reviewed-by: Jakub Kicinski Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20211116152652.19217-1-linma@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 96a209038a99a379444ea3ef9ae823e685ba60e7 Author: Lin Ma Date: Mon Nov 15 22:56:00 2021 +0800 NFC: reorganize the functions in nci_request [ Upstream commit 86cdf8e38792545161dbe3350a7eced558ba4d15 ] There is a possible data race as shown below: thread-A in nci_request() | thread-B in nci_close_device() | mutex_lock(&ndev->req_lock); test_bit(NCI_UP, &ndev->flags); | ... | test_and_clear_bit(NCI_UP, &ndev->flags) mutex_lock(&ndev->req_lock); | | This race will allow __nci_request() to be awaked while the device is getting removed. Similar to commit e2cb6b891ad2 ("bluetooth: eliminate the potential race condition when removing the HCI controller"). this patch alters the function sequence in nci_request() to prevent the data races between the nci_close_device(). Signed-off-by: Lin Ma Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") Link: https://lore.kernel.org/r/20211115145600.8320-1-linma@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7a5c8a68f38fce8e6f6a8ca8d01f64a2c9cbc2fc Author: Grzegorz Szczurek Date: Fri Oct 29 11:26:01 2021 +0200 i40e: Fix display error code in dmesg [ Upstream commit 5aff430d4e33a0b48a6b3d5beb06f79da23f9916 ] Fix misleading display error in dmesg if tc filter return fail. Only i40e status error code should be converted to string, not linux error code. Otherwise, we return false information about the error. Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower") Signed-off-by: Grzegorz Szczurek Signed-off-by: Mateusz Palczewski Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 6c9c9f48b462f3fb473f58b6bd90219007558638 Author: Jedrzej Jagielski Date: Mon Jun 21 08:37:31 2021 +0000 i40e: Fix creation of first queue by omitting it if is not power of two [ Upstream commit 2e6d218c1ec6fb9cd70693b78134cbc35ae0b5a9 ] Reject TCs creation with proper message if the first queue assignment is not equal to the power of two. The first queue number was checked too late in the second queue iteration, if second queue was configured at all. Now if first queue value is not a power of two, then trying to create qdisc will be rejected. Fixes: 8f88b3034db3 ("i40e: Add infrastructure for queue channel support") Signed-off-by: Grzegorz Szczurek Signed-off-by: Jedrzej Jagielski Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 593015973591a14c4f42b887ae0e9ec2dfb66ff4 Author: Karen Sornek Date: Wed Apr 28 10:19:41 2021 +0200 i40e: Fix warning message and call stack during rmmod i40e driver [ Upstream commit 3a3b311e3881172fc8e019b6508f04bc40c92d9d ] Restore part of reset functionality used when reset is called from the VF to reset itself. Without this fix warning message is displayed when VF is being removed via sysfs. Fix the crash of the VF during reset by ensuring that the PF receives the reset message successfully. Refactor code to use one function instead of two. Fixes: 5c3c48ac6bf5 ("i40e: implement virtual device interface") Signed-off-by: Grzegorz Szczurek Signed-off-by: Karen Sornek Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 0bccc44a54e8d68be5ed02b7985a869cc2df6444 Author: Jack Wang Date: Mon Nov 15 11:15:19 2021 +0100 RDMA/mlx4: Do not fail the registration on port stats [ Upstream commit 378c67413de18b69fb3bb78d8c4f0f1192cfa973 ] If the FW doesn't support MLX4_DEV_CAP_FLAG2_DIAG_PER_PORT, mlx4 driver will fail the ib_setup_port_attrs, which is called from ib_register_device()/enable_device_and_get(), in the end leads to device not detected[1][2] To fix it, add a new mlx4_ib_hw_stats_ops1, w/o alloc_hw_port_stats if FW does not support MLX4_DEV_CAP_FLAG2_DIAG_PER_PORT. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2014094 [2] https://lore.kernel.org/linux-rdma/CAMGffEn2wvEnmzc0xe=xYiCLqpphiHDBxCxqAELrBofbUAMQxw@mail.gmail.com Fixes: 4b5f4d3fb408 ("RDMA: Split the alloc_hw_stats() ops to port and device variants") Link: https://lore.kernel.org/r/20211115101519.27210-1-jinpu.wang@ionos.com Signed-off-by: Jack Wang Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 29148fffe93c52d10e03340da216382fb19a2178 Author: Eryk Rybak Date: Fri Apr 23 13:43:26 2021 +0200 i40e: Fix ping is lost after configuring ADq on VF [ Upstream commit 9e0a603cb7dce2a19d98116d42de84b6db26d716 ] Properly reconfigure VF VSIs after VF request ADQ. Created new function to update queue mapping and queue pairs per TC with AQ update VSI. This sets proper RSS size on NIC. VFs num_queue_pairs should not be changed during setup of queue maps. Previously, VF main VSI in ADQ had configured too many queues and had wrong RSS size, which lead to packets not being consumed and drops in connectivity. Fixes: bc6d33c8d93f ("i40e: Fix the number of queues available to be mapped for use") Co-developed-by: Przemyslaw Patynowski Signed-off-by: Przemyslaw Patynowski Signed-off-by: Eryk Rybak Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 7299cd74718e6d92aa9c2d16cf9f4468e1926c08 Author: Eryk Rybak Date: Fri Apr 23 13:43:25 2021 +0200 i40e: Fix changing previously set num_queue_pairs for PFs [ Upstream commit d2a69fefd75683004ffe87166de5635b3267ee07 ] Currently, the i40e_vsi_setup_queue_map is basing the count of queues in TCs on a VSI's alloc_queue_pairs member which is not changed throughout any user's action (for example via ethtool's set_channels callback). This implies that vsi->tc_config.tc_info[n].qcount value that is given to the kernel via netdev_set_tc_queue() that notifies about the count of queues per particular traffic class is constant even if user has changed the total count of queues. This in turn caused the kernel warning after setting the queue count to the lower value than the initial one: $ ethtool -l ens801f0 Channel parameters for ens801f0: Pre-set maximums: RX: 0 TX: 0 Other: 1 Combined: 64 Current hardware settings: RX: 0 TX: 0 Other: 1 Combined: 64 $ ethtool -L ens801f0 combined 40 [dmesg] Number of in use tx queues changed invalidating tc mappings. Priority traffic classification disabled! Reason was that vsi->alloc_queue_pairs stayed at 64 value which was used to set the qcount on TC0 (by default only TC0 exists so all of the existing queues are assigned to TC0). we update the offset/qcount via netdev_set_tc_queue() back to the old value but then the netif_set_real_num_tx_queues() is using the vsi->num_queue_pairs as a value which got set to 40. Fix it by using vsi->req_queue_pairs as a queue count that will be distributed across TCs. Do it only for non-zero values, which implies that user actually requested the new count of queues. For VSIs other than main, stay with the vsi->alloc_queue_pairs as we only allow manipulating the queue count on main VSI. Fixes: bc6d33c8d93f ("i40e: Fix the number of queues available to be mapped for use") Co-developed-by: Maciej Fijalkowski Signed-off-by: Maciej Fijalkowski Co-developed-by: Przemyslaw Patynowski Signed-off-by: Przemyslaw Patynowski Signed-off-by: Eryk Rybak Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e91e8427a1e1633a0261e3bb0201c836ac5b3890 Author: Michal Maloszewski Date: Wed Feb 24 12:07:48 2021 +0000 i40e: Fix NULL ptr dereference on VSI filter sync [ Upstream commit 37d9e304acd903a445df8208b8a13d707902dea6 ] Remove the reason of null pointer dereference in sync VSI filters. Added new I40E_VSI_RELEASING flag to signalize deleting and releasing of VSI resources to sync this thread with sync filters subtask. Without this patch it is possible to start update the VSI filter list after VSI is removed, that's causing a kernel oops. Fixes: 41c445ff0f48 ("i40e: main driver core") Signed-off-by: Grzegorz Szczurek Signed-off-by: Michal Maloszewski Reviewed-by: Przemyslaw Patynowski Reviewed-by: Witold Fijalkowski Reviewed-by: Jaroslaw Gawin Reviewed-by: Aleksandr Loktionov Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit fdd56291046ca2bab186e9c044aa90383b0a5a48 Author: Eryk Rybak Date: Thu Jan 21 16:17:22 2021 +0000 i40e: Fix correct max_pkt_size on VF RX queue [ Upstream commit 6afbd7b3c53cb7417189f476e99d431daccb85b0 ] Setting VLAN port increasing RX queue max_pkt_size by 4 bytes to take VLAN tag into account. Trigger the VF reset when setting port VLAN for VF to renegotiate its capabilities and reinitialize. Fixes: ba4e003d29c1 ("i40e: don't hold spinlock while resetting VF") Signed-off-by: Sylwester Dziedziuch Signed-off-by: Aleksandr Loktionov Signed-off-by: Eryk Rybak Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 0f810d06b507aa40fef8d1ac0a88e6d0590dbfc3 Author: Jonathan Davies Date: Tue Nov 16 17:42:42 2021 +0000 net: virtio_net_hdr_to_skb: count transport header in UFO [ Upstream commit cf9acc90c80ecbee00334aa85d92f4e74014bcff ] virtio_net_hdr_to_skb does not set the skb's gso_size and gso_type correctly for UFO packets received via virtio-net that are a little over the GSO size. This can lead to problems elsewhere in the networking stack, e.g. ovs_vport_send dropping over-sized packets if gso_size is not set. This is due to the comparison if (skb->len - p_off > gso_size) not properly accounting for the transport layer header. p_off includes the size of the transport layer header (thlen), so skb->len - p_off is the size of the TCP/UDP payload. gso_size is read from the virtio-net header. For UFO, fragmentation happens at the IP level so does not need to include the UDP header. Hence the calculation could be comparing a TCP/UDP payload length with an IP payload length, causing legitimate virtio-net packets to have lack gso_type/gso_size information. Example: a UDP packet with payload size 1473 has IP payload size 1481. If the guest used UFO, it is not fragmented and the virtio-net header's flags indicate that it is a GSO frame (VIRTIO_NET_HDR_GSO_UDP), with gso_size = 1480 for an MTU of 1500. skb->len will be 1515 and p_off will be 42, so skb->len - p_off = 1473. Hence the comparison fails, and shinfo->gso_size and gso_type are not set as they should be. Instead, add the UDP header length before comparing to gso_size when using UFO. In this way, it is the size of the IP payload that is compared to gso_size. Fixes: 6dd912f82680 ("net: check untrusted gso_size at kernel entry") Signed-off-by: Jonathan Davies Reviewed-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 32d4686224744819ddcae58b666c21d2a4ef4c88 Author: Pavel Skripkin Date: Tue Nov 16 18:17:12 2021 +0300 net: dpaa2-eth: fix use-after-free in dpaa2_eth_remove [ Upstream commit 9b5a333272a48c2f8b30add7a874e46e8b26129c ] Access to netdev after free_netdev() will cause use-after-free bug. Move debug log before free_netdev() call to avoid it. Fixes: 7472dd9f6499 ("staging: fsl-dpaa2/eth: Move print message") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7cc1c7da94eae9b35517a0a96b0dae2ca382700d Author: Xin Long Date: Fri Nov 12 11:33:11 2021 -0500 net: sched: act_mirred: drop dst for the direction from egress to ingress [ Upstream commit f799ada6bf2397c351220088b9b0980125c77280 ] Without dropping dst, the packets sent from local mirred/redirected to ingress will may still use the old dst. ip_rcv() will drop it as the old dst is for output and its .input is dst_discard. This patch is to fix by also dropping dst for those packets that are mirred or redirected from egress to ingress in act_mirred. Note that we don't drop it for the direction change from ingress to egress, as on which there might be a user case attaching a metadata dst by act_tunnel_key that would be used later. Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct") Signed-off-by: Xin Long Acked-by: Cong Wang Reviewed-by: Marcelo Ricardo Leitner Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d7d992cc3a7b3ad3470167dc27b8a6bbc1114c38 Author: Marcin Wojtas Date: Mon Nov 15 16:30:24 2021 +0100 net: mvmdio: fix compilation warning [ Upstream commit 2460386bef0b9b98b71728d3c173e15558b78d82 ] The kernel test robot reported a following issue: >> drivers/net/ethernet/marvell/mvmdio.c:426:36: warning: unused variable 'orion_mdio_acpi_match' [-Wunused-const-variable] static const struct acpi_device_id orion_mdio_acpi_match[] = { ^ 1 warning generated. Fix that by surrounding the variable by appropriate ifdef. Fixes: c54da4c1acb1 ("net: mvmdio: add ACPI support") Reported-by: kernel test robot Signed-off-by: Marcin Wojtas Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20211115153024.209083-1-mw@semihalf.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 39443eb70e29b08f99d8a53163a4179b7ae81c92 Author: Adrian Hunter Date: Mon Nov 8 08:48:15 2021 +0200 scsi: ufs: core: Fix another task management completion race [ Upstream commit 5cb37a26355d79ab290220677b1b57d28e99a895 ] hba->outstanding_tasks, which is read under host_lock spinlock, tells the interrupt handler what task management tags are in use by the driver. The doorbell register bits indicate which tags are in use by the hardware. A doorbell bit that is 0 is because the bit has yet to be set by the driver, or because the task is complete. It is only possible to disambiguate the 2 cases, if reading/writing the doorbell register is synchronized with reading/writing hba->outstanding_tasks. For that reason, reading REG_UTP_TASK_REQ_DOOR_BELL must be done under spinlock. Link: https://lore.kernel.org/r/20211108064815.569494-3-adrian.hunter@intel.com Fixes: f5ef336fd2e4 ("scsi: ufs: core: Fix task management completion") Reviewed-by: Bart Van Assche Signed-off-by: Adrian Hunter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bede57a71a680f96b2cecc08841605ae06be57c3 Author: Adrian Hunter Date: Mon Nov 8 08:48:14 2021 +0200 scsi: ufs: core: Fix task management completion timeout race [ Upstream commit 886fe2915cce6658b0fc19e64b82879325de61ea ] __ufshcd_issue_tm_cmd() clears req->end_io_data after timing out, which races with the completion function ufshcd_tmc_handler() which expects req->end_io_data to have a value. Note __ufshcd_issue_tm_cmd() and ufshcd_tmc_handler() are already synchronized using hba->tmf_rqs and hba->outstanding_tasks under the host_lock spinlock. It is also not necessary (nor typical) to clear req->end_io_data because the block layer does it before allocating out requests e.g. via blk_get_request(). So fix by not clearing it. Link: https://lore.kernel.org/r/20211108064815.569494-2-adrian.hunter@intel.com Fixes: f5ef336fd2e4 ("scsi: ufs: core: Fix task management completion") Reviewed-by: Bart Van Assche Signed-off-by: Adrian Hunter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bcc0e3175a976b7fa9a353960808adb0bb49ead8 Author: Mike Christie Date: Fri Nov 5 17:10:48 2021 -0500 scsi: core: sysfs: Fix hang when device state is set via sysfs [ Upstream commit 4edd8cd4e86dd3047e5294bbefcc0a08f66a430f ] This fixes a regression added with: commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after offlinining device") The problem is that after iSCSI recovery, iscsid will call into the kernel to set the dev's state to running, and with that patch we now call scsi_rescan_device() with the state_mutex held. If the SCSI error handler thread is just starting to test the device in scsi_send_eh_cmnd() then it's going to try to grab the state_mutex. We are then stuck, because when scsi_rescan_device() tries to send its I/O scsi_queue_rq() calls -> scsi_host_queue_ready() -> scsi_host_in_recovery() which will return true (the host state is still in recovery) and I/O will just be requeued. scsi_send_eh_cmnd() will then never be able to grab the state_mutex to finish error handling. To prevent the deadlock move the rescan-related code to after we drop the state_mutex. This also adds a check for if we are already in the running state. This prevents extra scans and helps the iscsid case where if the transport class has already onlined the device during its recovery process then we don't need userspace to do it again plus possibly block that daemon. Link: https://lore.kernel.org/r/20211105221048.6541-3-michael.christie@oracle.com Fixes: f0f82e2476f6 ("scsi: core: Fix capacity set to zero after offlinining device") Cc: Bart Van Assche Cc: lijinlin Cc: Wu Bo Reviewed-by: Lee Duncan Reviewed-by: Wu Bo Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c36baca06efa833adaefba61f45fefdc49b6d070 Author: Bart Van Assche Date: Thu Nov 4 11:10:53 2021 -0700 scsi: ufs: core: Improve SCSI abort handling [ Upstream commit 3ff1f6b6ba6f97f50862aa50e79959cc8ddc2566 ] The following has been observed on a test setup: WARNING: CPU: 4 PID: 250 at drivers/scsi/ufs/ufshcd.c:2737 ufshcd_queuecommand+0x468/0x65c Call trace: ufshcd_queuecommand+0x468/0x65c scsi_send_eh_cmnd+0x224/0x6a0 scsi_eh_test_devices+0x248/0x418 scsi_eh_ready_devs+0xc34/0xe58 scsi_error_handler+0x204/0x80c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 That warning is triggered by the following statement: WARN_ON(lrbp->cmd); Fix this warning by clearing lrbp->cmd from the abort handler. Link: https://lore.kernel.org/r/20211104181059.4129537-1-bvanassche@acm.org Fixes: 7a3e97b0dc4b ("[SCSI] ufshcd: UFS Host controller driver") Reviewed-by: Bean Huo Reviewed-by: Stanley Chu Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7fbdbd4fe35b682dbfd7851d10c2f71897b8a3a0 Author: Raed Salem Date: Mon Nov 1 16:18:53 2021 +0200 net/mlx5: E-Switch, return error if encap isn't supported [ Upstream commit c4c3176739dfa6efcc5b1d1de4b3fd2b51b048c7 ] On regular ConnectX HCAs getting encap mode isn't supported when the E-Switch is in NONE mode. Current code would return no error code when trying to get encap mode in such case which is wrong. Fix by returning error value to indicate failure to caller in such case. Fixes: 8e0aa4bc959c ("net/mlx5: E-switch, Protect eswitch mode changes") Signed-off-by: Raed Salem Reviewed-by: Mark Bloch Reviewed-by: Maor Dickman Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 2c3b6e820d674329ebe2e79728c73d75d2732075 Author: Maher Sanalla Date: Fri Nov 5 11:19:48 2021 +0200 net/mlx5: Lag, update tracker when state change event received [ Upstream commit ae396d85c01c7bdc9eeceecde1f493d03f793465 ] Currently, In NETDEV_CHANGELOWERSTATE/NETDEV_CHANGEUPPERSTATE events handling, tracking is not fully completed if the LAG device is not ready at the time the events occur. But, we must keep track of the upper and lower states after receiving the events because RoCE needs this info in mlx5_lag_get_roce_netdev() - in order to return the corresponding port that its running on. Returning the wrong (not most recent) port will lead to gids table being incorrect. For example: If during the attachment of a slave to the bond, the other non-attached port performs pci_reload, then the LAG device is not ready, but that should not result in dismissing attached slave tracker update automatically (which is performed in mlx5_handle_changelowerstate()), Since these events might not come later, which can lead to both bond ports having tx_enabled=0 - which is not a valid state of LAG bond. Fixes: 9b412cc35f00 ("net/mlx5e: Add LAG warning if bond slave is not lag master") Signed-off-by: Maher Sanalla Reviewed-by: Mark Bloch Reviewed-by: Jianbo Liu Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 486e8de6e233ff2999493533c6259d1cb538653b Author: Roi Dayan Date: Mon Nov 8 16:41:05 2021 +0200 net/mlx5e: CT, Fix multiple allocations and memleak of mod acts [ Upstream commit 806401c20a0f9c51b6c8fd7035671e6ca841f6c2 ] CT clear action offload adds additional mod hdr actions to the flow's original mod actions in order to clear the registers which hold ct_state. When such flow also includes encap action, a neigh update event can cause the driver to unoffload the flow and then reoffload it. Each time this happens, the ct clear handling adds that same set of mod hdr actions to reset ct_state until the max of mod hdr actions is reached. Also the driver never releases the allocated mod hdr actions and causing a memleak. Fix above two issues by moving CT clear mod acts allocation into the parsing actions phase and only use it when offloading the rule. The release of mod acts will be done in the normal flow_put(). backtrace: [<000000007316e2f3>] krealloc+0x83/0xd0 [<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core] [<00000000970ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core] [<0000000067c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core] [<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core] [<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core] [<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core] [<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core] [<00000000e92e49d7>] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core] [<00000000f60f5602>] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core] Fixes: 1ef3018f5af3 ("net/mlx5e: CT: Support clear action") Signed-off-by: Roi Dayan Reviewed-by: Paul Blakey Reviewed-by: Maor Dickman Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 8b45a377b582f101c2e404152549749bcfc1d6c6 Author: Mark Bloch Date: Wed Nov 10 15:19:12 2021 +0000 net/mlx5: E-Switch, rebuild lag only when needed [ Upstream commit 2eb0cb31bc4ce2ede5460cf3ef433b40cf5f040d ] A user can enable VFs without changing E-Switch mode, this can happen when a user moves straight to switchdev mode and only once in switchdev VFs are enabled via the sysfs interface. The cited commit assumed this isn't possible and exposed a single API function where the E-switch calls into the lag code, breaks the lag and prevents any other lag operations to take place until the E-switch update has ended. Breaking the hardware lag when it isn't needed can make it such that hardware lag can't be enabled again. In the sysfs call path check if the current E-Switch mode is NONE, in the context of the function it can only mean the E-Switch is moving out of NONE mode and the hardware lag should be disabled and enabled once the mode change has ended. If the mode isn't NONE it means VFs are about to be enabled and such operation doesn't require toggling the hardware lag. Fixes: cac1eb2cf2e3 ("net/mlx5: Lag, properly lock eswitch if needed") Signed-off-by: Mark Bloch Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit a51a6da375d82aed5c8f83abd13e7d060421bd48 Author: Neta Ostrovsky Date: Wed Oct 27 15:16:14 2021 +0300 net/mlx5: Update error handler for UCTX and UMEM [ Upstream commit ba50cd9451f6c49cf0841c0a4a146ff6a2822699 ] In the fast unload flow, the device state is set to internal error, which indicates that the driver started the destroy process. In this case, when a destroy command is being executed, it should return MLX5_CMD_STAT_OK. Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK instead of EIO. This fixes a call trace in the umem release process - [ 2633.536695] Call Trace: [ 2633.537518] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] [ 2633.538596] remove_client_context+0x8b/0xd0 [ib_core] [ 2633.539641] disable_device+0x8c/0x130 [ib_core] [ 2633.540615] __ib_unregister_device+0x35/0xa0 [ib_core] [ 2633.541640] ib_unregister_device+0x21/0x30 [ib_core] [ 2633.542663] __mlx5_ib_remove+0x38/0x90 [mlx5_ib] [ 2633.543640] auxiliary_bus_remove+0x1e/0x30 [auxiliary] [ 2633.544661] device_release_driver_internal+0x103/0x1f0 [ 2633.545679] bus_remove_device+0xf7/0x170 [ 2633.546640] device_del+0x181/0x410 [ 2633.547606] mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core] [ 2633.548777] mlx5_unregister_device+0x27/0x40 [mlx5_core] [ 2633.549841] mlx5_uninit_one+0x21/0xc0 [mlx5_core] [ 2633.550864] remove_one+0x69/0xe0 [mlx5_core] [ 2633.551819] pci_device_remove+0x3b/0xc0 [ 2633.552731] device_release_driver_internal+0x103/0x1f0 [ 2633.553746] unbind_store+0xf6/0x130 [ 2633.554657] kernfs_fop_write+0x116/0x190 [ 2633.555567] vfs_write+0xa5/0x1a0 [ 2633.556407] ksys_write+0x4f/0xb0 [ 2633.557233] do_syscall_64+0x5b/0x1a0 [ 2633.558071] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 2633.559018] RIP: 0033:0x7f9977132648 [ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55 [ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648 [ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001 [ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740 [ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0 [ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c [ 2633.568725] ---[ end trace 10b4fe52945e544d ]--- Fixes: 6a6fabbfa3e8 ("net/mlx5: Update pci error handler entries and command translation") Signed-off-by: Neta Ostrovsky Reviewed-by: Leon Romanovsky Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 2ae38157080616a13a9fe3f0b4b6ec0070aa408a Author: Valentine Fatiev Date: Tue Oct 26 11:42:41 2021 +0300 net/mlx5e: nullify cq->dbg pointer in mlx5_debug_cq_remove() [ Upstream commit 76ded29d3fcda4928da8849ffc446ea46871c1c2 ] Prior to this patch in case mlx5_core_destroy_cq() failed it proceeds to rest of destroy operations. mlx5_core_destroy_cq() could be called again by user and cause additional call of mlx5_debug_cq_remove(). cq->dbg was not nullify in previous call and cause the crash. Fix it by nullify cq->dbg pointer after removal. Also proceed to destroy operations only if FW return 0 for MLX5_CMD_OP_DESTROY_CQ command. general protection fault, probably for non-canonical address 0x2000300004058: 0000 [#1] SMP PTI CPU: 5 PID: 1228 Comm: python Not tainted 5.15.0-rc5_for_upstream_min_debug_2021_10_14_11_06 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:lockref_get+0x1/0x60 Code: 5d e9 53 ff ff ff 48 8d 7f 70 e8 0a 2e 48 00 c7 85 d0 00 00 00 02 00 00 00 c6 45 70 00 fb 5d c3 c3 cc cc cc cc cc cc cc cc 53 <48> 8b 17 48 89 fb 85 d2 75 3d 48 89 d0 bf 64 00 00 00 48 89 c1 48 RSP: 0018:ffff888137dd7a38 EFLAGS: 00010206 RAX: 0000000000000000 RBX: ffff888107d5f458 RCX: 00000000fffffffe RDX: 000000000002c2b0 RSI: ffffffff8155e2e0 RDI: 0002000300004058 RBP: ffff888137dd7a88 R08: 0002000300004058 R09: ffff8881144a9f88 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881141d4000 R13: ffff888137dd7c68 R14: ffff888137dd7d58 R15: ffff888137dd7cc0 FS: 00007f4644f2a4c0(0000) GS:ffff8887a2d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b4500f4380 CR3: 0000000114f7a003 CR4: 0000000000170ea0 Call Trace: simple_recursive_removal+0x33/0x2e0 ? debugfs_remove+0x60/0x60 debugfs_remove+0x40/0x60 mlx5_debug_cq_remove+0x32/0x70 [mlx5_core] mlx5_core_destroy_cq+0x41/0x1d0 [mlx5_core] devx_obj_cleanup+0x151/0x330 [mlx5_ib] ? __pollwait+0xd0/0xd0 ? xas_load+0x5/0x70 ? xa_load+0x62/0xa0 destroy_hw_idr_uobject+0x20/0x80 [ib_uverbs] uverbs_destroy_uobject+0x3b/0x360 [ib_uverbs] uobj_destroy+0x54/0xa0 [ib_uverbs] ib_uverbs_cmd_verbs+0xaf2/0x1160 [ib_uverbs] ? uverbs_finalize_object+0xd0/0xd0 [ib_uverbs] ib_uverbs_ioctl+0xc4/0x1b0 [ib_uverbs] __x64_sys_ioctl+0x3e4/0x8e0 Fixes: 94b960b9deff ("net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path") Signed-off-by: Valentine Fatiev Reviewed-by: Leon Romanovsky Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 158ec85d360e783c1610dc160c86a02133dc7620 Author: Paul Blakey Date: Thu May 20 17:09:58 2021 +0300 net/mlx5: E-Switch, Fix resetting of encap mode when entering switchdev [ Upstream commit d7751d6476185ff754b9dad2cba0c0a6e43ecadc ] E-Switch encap mode is relevant only when in switchdev mode. The RDMA driver can query the encap configuration via mlx5_eswitch_get_encap_mode(). Make sure it returns the currently used mode and not the set one. This reverts the cited commit which reset the encap mode on entering switchdev and fixes the original issue properly. Fixes: 9a64144d683a ("net/mlx5: E-Switch, Fix default encap mode") Signed-off-by: Paul Blakey Reviewed-by: Mark Bloch Reviewed-by: Maor Dickman Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit a49a9b92fcd2dac7463f741cb14aa9822e88d5c0 Author: Vlad Buslov Date: Thu Oct 21 18:15:10 2021 +0300 net/mlx5e: Wait for concurrent flow deletion during neigh/fib events [ Upstream commit 362980eada85b5ea691e5e0d9257a991aa7ade47 ] Function mlx5e_take_tmp_flow() skips flows with zero reference count. This can cause syndrome 0x179e84 when the called from neigh or route update code and the skipped flow is not removed from the hardware by the time underlying encap/decap resource is deleted. Add new completion 'del_hw_done' that is completed when flow is unoffloaded. This is safe to do because flow with reference count zero needs to be detached from encap/decap entry before its memory is deallocated, which requires taking the encap_tbl_lock mutex that is held by the event handlers code. Fixes: 8914add2c9e5 ("net/mlx5e: Handle FIB events to update tunnel endpoint device") Signed-off-by: Vlad Buslov Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit ebeda7a9528ae690e6bf12791a868f0cca8391f2 Author: Tariq Toukan Date: Wed Sep 15 13:25:31 2021 +0300 net/mlx5e: kTLS, Fix crash in RX resync flow [ Upstream commit cc4a9cc03faa6d8db1a6954bb536f2c1e63bdff6 ] For the TLS RX resync flow, we maintain a list of TLS contexts that require some attention, to communicate their resync information to the HW. Here we fix list corruptions, by protecting the entries against movements coming from resync_handle_seq_match(), until their resync handling in napi is fully completed. Fixes: e9ce991bce5b ("net/mlx5e: kTLS, Add resiliency to RX resync failures") Signed-off-by: Tariq Toukan Reviewed-by: Maxim Mikityanskiy Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit b70e072feffa0ba5c41a99b9524b9878dee7748e Author: Leon Romanovsky Date: Thu Nov 11 13:45:00 2021 +0200 RDMA/core: Set send and receive CQ before forwarding to the driver [ Upstream commit 6cd7397d01c4a3e09757840299e4f114f0aa5fa0 ] Preset both receive and send CQ pointers prior to call to the drivers and overwrite it later again till the mlx4 is going to be changed do not overwrite ibqp properties. This change is needed for mlx5, because in case of QP creation failure, it will go to the path of QP destroy which relies on proper CQ pointers. BUG: KASAN: use-after-free in create_qp.cold+0x164/0x16e [mlx5_ib] Write of size 8 at addr ffff8880064c55c0 by task a.out/246 CPU: 0 PID: 246 Comm: a.out Not tainted 5.15.0+ #291 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x83/0xdf create_qp.cold+0x164/0x16e [mlx5_ib] mlx5_ib_create_qp+0x358/0x28a0 [mlx5_ib] create_qp.part.0+0x45b/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Allocated by task 246: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0xa4/0xd0 create_qp.part.0+0x92/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 246: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x10c/0x150 slab_free_freelist_hook+0xb4/0x1b0 kfree+0xe7/0x2a0 create_qp.part.0+0x52b/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 514aee660df4 ("RDMA: Globally allocate and release QP memory") Link: https://lore.kernel.org/r/2dbb2e2cbb1efb188a500e5634be1d71956424ce.1636631035.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9fe0ba31271cec187b09cf868d6cf09551726b86 Author: Colin Ian King Date: Wed Nov 10 19:20:08 2021 +0000 btrfs: make 1-bit bit-fields of scrub_page unsigned int [ Upstream commit d08e38b62327961295be1c63b562cd46ec97cd07 ] The bitfields have_csum and io_error are currently signed which is not recommended as the representation is an implementation defined behaviour. Fix this by making the bit-fields unsigned ints. Fixes: 2c36395430b0 ("btrfs: scrub: remove the anonymous structure from scrub_page") Reviewed-by: Josef Bacik Reviewed-by: Qu Wenruo Signed-off-by: Colin Ian King Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 67fb5eac4063e884f029daa5bd94cbcf7bf3cebe Author: Cong Wang Date: Sun Nov 14 20:40:06 2021 -0800 udp: Validate checksum in udp_read_sock() [ Upstream commit 099f896f498a2b26d84f4ddae039b2c542c18b48 ] It turns out the skb's in sock receive queue could have bad checksums, as both ->poll() and ->recvmsg() validate checksums. We have to do the same for ->read_sock() path too before they are redirected in sockmap. Fixes: d7f571188ecf ("udp: Implement ->read_sock() for sockmap") Reported-by: Daniel Borkmann Signed-off-by: Cong Wang Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20211115044006.26068-1-xiyou.wangcong@gmail.com Signed-off-by: Sasha Levin commit b4a677ffb67e3c0319d471ad2d31f206ab470be6 Author: Alex Williamson Date: Mon Nov 8 11:03:57 2021 -0700 platform/x86: think-lmi: Abort probe on analyze failure [ Upstream commit 812fcc609502096e98cc3918a4b807722dba8fd9 ] A Lenovo ThinkStation S20 (4157CTO BIOS 60KT41AUS) fails to boot on recent kernels including the think-lmi driver, due to the fact that errors returned by the tlmi_analyze() function are ignored by tlmi_probe(), where tlmi_sysfs_init() is called unconditionally. This results in making use of an array of already freed, non-null pointers and other uninitialized globals, causing all sorts of nasty kobject and memory faults. Make use of the analyze function return value, free a couple leaked allocations, and remove the settings_count field, which is incremented but never consumed. Fixes: a40cd7ef22fb ("platform/x86: think-lmi: Add WMI interface support on Lenovo platforms") Signed-off-by: Alex Williamson Reviewed-by: Mark Gross Reviewed-by: Mark Pearson Link: https://lore.kernel.org/r/163639463588.1330483.15850167112490200219.stgit@omen Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 6e6e4fce53fa865db97c84682d7fcbb7d189d5ea Author: Christophe JAILLET Date: Sun Nov 7 20:57:07 2021 +0100 platform/x86: hp_accel: Fix an error handling path in 'lis3lv02d_probe()' [ Upstream commit c961a7d2aa23ae19e0099fbcdf1040fb760eea83 ] If 'led_classdev_register()' fails, some additional resources should be released. Add the missing 'i8042_remove_filter()' and 'lis3lv02d_remove_fs()' calls that are already in the remove function but are missing here. Fixes: a4c724d0723b ("platform: hp_accel: add a i8042 filter to remove HPQ6000 data from kb bus stream") Fixes: 9e0c79782143 ("lis3lv02d: merge with leds hp disk") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/5a4f218f8f16d2e3a7906b7ca3654ffa946895f8.1636314074.git.christophe.jaillet@wanadoo.fr Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 871ee7e815fb9f43899a479f74460bb254e8fcf8 Author: Randy Dunlap Date: Mon Nov 15 22:46:27 2021 -0800 gpio: rockchip: needs GENERIC_IRQ_CHIP to fix build errors [ Upstream commit d6912b1251b47e6b04ea8c8881dfb35a6e7a3e29 ] gpio-rockchip uses interfaces that are provided by the Kconfig symbol GENERIC_IRQ_CHIP, so the driver should select that symbol in order to prevent build errors. Fixes these build errors (and more): aarch64-linux-ld: drivers/gpio/gpio-rockchip.o: in function `rockchip_irq_disable': gpio-rockchip.c:(.text+0x454): undefined reference to `irq_gc_mask_set_bit' aarch64-linux-ld: drivers/gpio/gpio-rockchip.o: in function `rockchip_irq_enable': gpio-rockchip.c:(.text+0x478): undefined reference to `irq_gc_mask_clr_bit' aarch64-linux-ld: drivers/gpio/gpio-rockchip.o: in function `rockchip_interrupts_register': gpio-rockchip.c:(.text+0x518): undefined reference to `irq_generic_chip_ops' aarch64-linux-ld: gpio-rockchip.c:(.text+0x594): undefined reference to `__irq_alloc_domain_generic_chips' aarch64-linux-ld: gpio-rockchip.c:(.text+0x5cc): undefined reference to `irq_get_domain_generic_chip' aarch64-linux-ld: gpio-rockchip.c:(.text+0x5e0): undefined reference to `irq_gc_ack_set_bit' aarch64-linux-ld: gpio-rockchip.c:(.text+0x604): undefined reference to `irq_gc_set_wake' Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 3d0f4ae1ad757ab4ee6ac31a7fd49eea2835c787 Author: Randy Dunlap Date: Sun Nov 14 17:20:51 2021 -0800 mips: lantiq: add support for clk_get_parent() [ Upstream commit fc1aabb088860d6cf9dd03612b7a6f0de91ccac2 ] Provide a simple implementation of clk_get_parent() in the lantiq subarch so that callers of it will build without errors. Fixes this build error: ERROR: modpost: "clk_get_parent" [drivers/iio/adc/ingenic-adc.ko] undefined! Fixes: 171bb2f19ed6 ("MIPS: Lantiq: Add initial support for Lantiq SoCs") Signed-off-by: Randy Dunlap Suggested-by: Russell King (Oracle) Cc: linux-mips@vger.kernel.org Cc: John Crispin Cc: Thomas Bogendoerfer Cc: Jonathan Cameron Cc: linux-iio@vger.kernel.org Cc: Russell King Cc: Andy Shevchenko Acked-by: Jonathan Cameron Acked-by: John Crispin Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 114404d22ee0adaacaaa8eac756224178a9e344c Author: Randy Dunlap Date: Sun Nov 14 16:42:18 2021 -0800 mips: bcm63xx: add support for clk_get_parent() [ Upstream commit e8f67482e5a4bc8d0b65d606d08cb60ee123b468 ] BCM63XX selects HAVE_LEGACY_CLK but does not provide/support clk_get_parent(), so add a simple implementation of that function so that callers of it will build without errors. Fixes these build errors: mips-linux-ld: drivers/iio/adc/ingenic-adc.o: in function `jz4770_adc_init_clk_div': ingenic-adc.c:(.text+0xe4): undefined reference to `clk_get_parent' mips-linux-ld: drivers/iio/adc/ingenic-adc.o: in function `jz4725b_adc_init_clk_div': ingenic-adc.c:(.text+0x1b8): undefined reference to `clk_get_parent' Fixes: e7300d04bd08 ("MIPS: BCM63xx: Add support for the Broadcom BCM63xx family of SOCs." ) Signed-off-by: Randy Dunlap Reported-by: kernel test robot Suggested-by: Russell King (Oracle) Cc: Artur Rojek Cc: Paul Cercueil Cc: linux-mips@vger.kernel.org Cc: Jonathan Cameron Cc: Lars-Peter Clausen Cc: linux-iio@vger.kernel.org Cc: Florian Fainelli Cc: Andy Shevchenko Cc: Russell King Cc: bcm-kernel-feedback-list@broadcom.com Cc: Jonas Gorski Reviewed-by: Andy Shevchenko Acked-by: Jonathan Cameron Acked-by: Russell King (Oracle) Acked-by: Florian Fainelli Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 21e27ed8ce6bdac2c4da5f4b0f87993382fc8356 Author: Colin Ian King Date: Wed Nov 10 23:28:24 2021 +0000 MIPS: generic/yamon-dt: fix uninitialized variable error [ Upstream commit 255e51da15baed47531beefd02f222e4dc01f1c1 ] In the case where fw_getenv returns an error when fetching values for ememsizea and memsize then variable phys_memsize is not assigned a variable and will be uninitialized on a zero check of phys_memsize. Fix this by initializing phys_memsize to zero. Cleans up cppcheck error: arch/mips/generic/yamon-dt.c:100:7: error: Uninitialized variable: phys_memsize [uninitvar] Fixes: f41d2430bbd6 ("MIPS: generic/yamon-dt: Support > 256MB of RAM") Signed-off-by: Colin Ian King Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit a5d1d3522232b4af1f5dee02d381e6fa86be8e2d Author: Daniel Borkmann Date: Tue Nov 9 18:48:08 2021 +0000 bpf: Fix toctou on read-only map's constant scalar tracking [ Upstream commit 353050be4c19e102178ccc05988101887c25ae53 ] Commit a23740ec43ba ("bpf: Track contents of read-only maps as scalars") is checking whether maps are read-only both from BPF program side and user space side, and then, given their content is constant, reading out their data via map->ops->map_direct_value_addr() which is then subsequently used as known scalar value for the register, that is, it is marked as __mark_reg_known() with the read value at verification time. Before a23740ec43ba, the register content was marked as an unknown scalar so the verifier could not make any assumptions about the map content. The current implementation however is prone to a TOCTOU race, meaning, the value read as known scalar for the register is not guaranteed to be exactly the same at a later point when the program is executed, and as such, the prior made assumptions of the verifier with regards to the program will be invalid which can cause issues such as OOB access, etc. While the BPF_F_RDONLY_PROG map flag is always fixed and required to be specified at map creation time, the map->frozen property is initially set to false for the map given the map value needs to be populated, e.g. for global data sections. Once complete, the loader "freezes" the map from user space such that no subsequent updates/deletes are possible anymore. For the rest of the lifetime of the map, this freeze one-time trigger cannot be undone anymore after a successful BPF_MAP_FREEZE cmd return. Meaning, any new BPF_* cmd calls which would update/delete map entries will be rejected with -EPERM since map_get_sys_perms() removes the FMODE_CAN_WRITE permission. This also means that pending update/delete map entries must still complete before this guarantee is given. This corner case is not an issue for loaders since they create and prepare such program private map in successive steps. However, a malicious user is able to trigger this TOCTOU race in two different ways: i) via userfaultfd, and ii) via batched updates. For i) userfaultfd is used to expand the competition interval, so that map_update_elem() can modify the contents of the map after map_freeze() and bpf_prog_load() were executed. This works, because userfaultfd halts the parallel thread which triggered a map_update_elem() at the time where we copy key/value from the user buffer and this already passed the FMODE_CAN_WRITE capability test given at that time the map was not "frozen". Then, the main thread performs the map_freeze() and bpf_prog_load(), and once that had completed successfully, the other thread is woken up to complete the pending map_update_elem() which then changes the map content. For ii) the idea of the batched update is similar, meaning, when there are a large number of updates to be processed, it can increase the competition interval between the two. It is therefore possible in practice to modify the contents of the map after executing map_freeze() and bpf_prog_load(). One way to fix both i) and ii) at the same time is to expand the use of the map's map->writecnt. The latter was introduced in fc9702273e2e ("bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY") and further refined in 1f6cb19be2e2 ("bpf: Prevent re-mmap()'ing BPF map as writable for initially r/o mapping") with the rationale to make a writable mmap()'ing of a map mutually exclusive with read-only freezing. The counter indicates writable mmap() mappings and then prevents/fails the freeze operation. Its semantics can be expanded beyond just mmap() by generally indicating ongoing write phases. This would essentially span any parallel regular and batched flavor of update/delete operation and then also have map_freeze() fail with -EBUSY. For the check_mem_access() in the verifier we expand upon the bpf_map_is_rdonly() check ensuring that all last pending writes have completed via bpf_map_write_active() test. Once the map->frozen is set and bpf_map_write_active() indicates a map->writecnt of 0 only then we are really guaranteed to use the map's data as known constants. For map->frozen being set and pending writes in process of still being completed we fall back to marking that register as unknown scalar so we don't end up making assumptions about it. With this, both TOCTOU reproducers from i) and ii) are fixed. Note that the map->writecnt has been converted into a atomic64 in the fix in order to avoid a double freeze_mutex mutex_{un,}lock() pair when updating map->writecnt in the various map update/delete BPF_* cmd flavors. Spanning the freeze_mutex over entire map update/delete operations in syscall side would not be possible due to then causing everything to be serialized. Similarly, something like synchronize_rcu() after setting map->frozen to wait for update/deletes to complete is not possible either since it would also have to span the user copy which can sleep. On the libbpf side, this won't break d66562fba1ce ("libbpf: Add BPF object skeleton support") as the anonymous mmap()-ed "map initialization image" is remapped as a BPF map-backed mmap()-ed memory where for .rodata it's non-writable. Fixes: a23740ec43ba ("bpf: Track contents of read-only maps as scalars") Reported-by: w1tcher.bupt@gmail.com Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 4d1834f39252e477f288e10561abcbba5ce1c9c2 Author: Akeem G Abodunrin Date: Fri Jun 4 09:53:27 2021 -0700 iavf: Restore VLAN filters after link down [ Upstream commit 4293014230b887d94b68aa460ff00153454a3709 ] Restore VLAN filters after the link is brought down, and up - since all filters are deleted from HW during the netdev link down routine. Fixes: ed1f5b58ea01 ("i40evf: remove VLAN filters on close") Signed-off-by: Akeem G Abodunrin Tested-by: George Kuruvinakunnel Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit cbb81563f5d40a7e60b7593ad90d880e35986fd4 Author: Grzegorz Szczurek Date: Fri Jun 4 09:49:00 2021 -0700 iavf: Fix for setting queues to 0 [ Upstream commit 9a6e9e483a9684a34573fd9f9e30ecfb047cb8cb ] Now setting combine to 0 will be rejected with the appropriate error code. This has been implemented by adding a condition that checks the value of combine equal to zero. Without this patch, when the user requested it, no error was returned and combine was set to the default value for VF. Fixes: 5520deb15326 ("iavf: Enable support for up to 16 queues") Signed-off-by: Grzegorz Szczurek Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 366c1fd41689312e8722a0751068ae149c27981e Author: Surabhi Boob Date: Fri Jun 4 09:48:59 2021 -0700 iavf: Fix for the false positive ASQ/ARQ errors while issuing VF reset [ Upstream commit 321421b57a12e933f92b228e0e6d0b2c6541f41d ] While issuing VF Reset from the guest OS, the VF driver prints logs about critical / Overflow error detection. This is not an actual error since the VF_MBX_ARQLEN register is set to all FF's for a short period of time and the VF would catch the bits set if it was reading the register during that spike of time. This patch introduces an additional check to ignore this condition since the VF is in reset. Fixes: 19b73d8efaa4 ("i40evf: Add additional check for reset") Signed-off-by: Surabhi Boob Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 9200f8c8600ebeded680c64b45762b441a00504a Author: Mitch Williams Date: Fri Jun 4 09:48:58 2021 -0700 iavf: validate pointers [ Upstream commit 131b0edc4028bb88bb472456b1ddba526cfb7036 ] In some cases, the ethtool get_rxfh handler may be called with a null key or indir parameter. So check these pointers, or you will have a very bad day. Fixes: 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS") Signed-off-by: Mitch Williams Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 99744c938f96b1d8f0564a95ddd7dfe718bc0c2b Author: Jacob Keller Date: Fri Jun 4 09:48:57 2021 -0700 iavf: prevent accidental free of filter structure [ Upstream commit 4f0400803818f2642f066d3eacaf013f23554cc7 ] In iavf_config_clsflower, the filter structure could be accidentally released at the end, if iavf_parse_cls_flower or iavf_handle_tclass ever return a non-zero but positive value. In this case, the function continues through to the end, and will call kfree() on the filter structure even though it has been added to the linked list. This can actually happen because iavf_parse_cls_flower will return a positive IAVF_ERR_CONFIG value instead of the traditional negative error codes. Fix this by ensuring that the kfree() check and error checks are similar. Use the more idiomatic "if (err)" to catch all non-zero error codes. Fixes: 0075fa0fadd0 ("i40evf: Add support to apply cloud filters") Signed-off-by: Jacob Keller Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit f72da5a83a0d5bbcd8c25b040e6c142b7263bf2f Author: Piotr Marczak Date: Fri Jun 4 09:48:56 2021 -0700 iavf: Fix failure to exit out from last all-multicast mode [ Upstream commit 8905072a192fffe9389255489db250c73ecab008 ] The driver could only quit allmulti when allmulti and promisc modes are turn on at the same time. If promisc had been off there was no way to turn off allmulti mode. The patch corrects this behavior. Switching allmulti does not depends on promisc state mode anymore Fixes: f42a5c74da99 ("i40e: Add allmulti support for the VF") Signed-off-by: Piotr Marczak Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit c3db4fffb364ac7bf602de115afe69c32a46383c Author: Nicholas Nunley Date: Fri Jun 4 09:48:55 2021 -0700 iavf: don't clear a lock we don't hold [ Upstream commit 2135a8d5c8186bc92901dc00f179ffd50e54c2ac ] In iavf_configure_clsflower() the function will bail out if it is unable to obtain the crit_section lock in a reasonable time. However, it will clear the lock when exiting, so fix this. Fixes: 640a8af5841f ("i40evf: Reorder configure_clsflower to avoid deadlock on error") Signed-off-by: Nicholas Nunley Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 9ef6589cac9a8c47f5544ccdf4c498093733bb3f Author: Nicholas Nunley Date: Fri Jun 4 09:48:54 2021 -0700 iavf: free q_vectors before queues in iavf_disable_vf [ Upstream commit 89f22f129696ab53cfbc608e0a2184d0fea46ac1 ] iavf_free_queues() clears adapter->num_active_queues, which iavf_free_q_vectors() relies on, so swap the order of these two function calls in iavf_disable_vf(). This resolves a panic encountered when the interface is disabled and then later brought up again after PF communication is restored. Fixes: 65c7006f234c ("i40evf: assign num_active_queues inside i40evf_alloc_queues") Signed-off-by: Nicholas Nunley Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit fb2be87cc330096e22348c0576beb7fef4fc7b4b Author: Nicholas Nunley Date: Fri Jun 4 09:48:53 2021 -0700 iavf: check for null in iavf_fix_features [ Upstream commit 8a4a126f4be88eb8b5f00a165ab58c35edf4ef76 ] If the driver has lost contact with the PF then it enters a disabled state and frees adapter->vf_res. However, ndo_fix_features can still be called on the interface, so we need to check for this condition first. Since we have no information on the features at this time simply leave them unmodified and return. Fixes: c4445aedfe09 ("i40evf: Fix VLAN features") Signed-off-by: Nicholas Nunley Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 68d4274034e618b7f190dc9fbfc4f3436a7430f4 Author: Mateusz Palczewski Date: Tue Feb 9 11:59:38 2021 +0000 iavf: Fix return of set the new channel count [ Upstream commit 4e5e6b5d9d1334d3490326b6922a2daaf56a867f ] Fixed return correct code from set the new channel count. Implemented by check if reset is done in appropriate time. This solution give a extra time to pf for reset vf in case when user want set new channel count for all vfs. Without this patch it is possible to return misleading output code to user and vf reset not to be correctly performed by pf. Fixes: 5520deb15326 ("iavf: Enable support for up to 16 queues") Signed-off-by: Grzegorz Szczurek Signed-off-by: Mateusz Palczewski Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 10c22d9519f3f5939de61a1500aa3a926b778d3a Author: Chuck Lever Date: Sun Nov 14 15:16:04 2021 -0500 NFSD: Fix exposure in nfsd4_decode_bitmap() [ Upstream commit c0019b7db1d7ac62c711cda6b357a659d46428fe ] rtm@csail.mit.edu reports: > nfsd4_decode_bitmap4() will write beyond bmval[bmlen-1] if the RPC > directs it to do so. This can cause nfsd4_decode_state_protect4_a() > to write client-supplied data beyond the end of > nfsd4_exchange_id.spo_must_allow[] when called by > nfsd4_decode_exchange_id(). Rewrite the loops so nfsd4_decode_bitmap() cannot iterate beyond @bmlen. Reported by: rtm@csail.mit.edu Fixes: d1c263a031e8 ("NFSD: Replace READ* macros in nfsd4_decode_fattr()") Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit f6218db543517082b45f553b39f7731d6535126c Author: Wen Gu Date: Mon Nov 15 17:45:07 2021 +0800 net/smc: Make sure the link_id is unique [ Upstream commit cf4f5530bb55ef7d5a91036b26676643b80b1616 ] The link_id is supposed to be unique, but smcr_next_link_id() doesn't skip the used link_id as expected. So the patch fixes this. Fixes: 026c381fb477 ("net/smc: introduce link_idx for link group array") Signed-off-by: Wen Gu Reviewed-by: Tony Lu Acked-by: Karsten Graul Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 17b2c2e70d20da15d02140796f5dc28160137a2c Author: Tetsuo Handa Date: Mon Nov 15 19:16:56 2021 +0900 sock: fix /proc/net/sockstat underflow in sk_clone_lock() [ Upstream commit 938cca9e4109b30ee1d476904538225a825e54eb ] sk_clone_lock() needs to call sock_inuse_add(1) before entering the sk_free_unlock_clone() error path, for __sk_free() from sk_free() from sk_free_unlock_clone() calls sock_inuse_add(-1). Signed-off-by: Tetsuo Handa Fixes: 648845ab7e200993 ("sock: Move the socket inuse to namespace.") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 95fe8904bcd6f0dab210d3deb985a90bb4705069 Author: Xin Long Date: Mon Nov 15 07:45:24 2021 -0500 tipc: only accept encrypted MSG_CRYPTO msgs [ Upstream commit 271351d255b09e39c7f6437738cba595f9b235be ] The MSG_CRYPTO msgs are always encrypted and sent to other nodes for keys' deployment. But when receiving in peers, if those nodes do not validate it and make sure it's encrypted, one could craft a malicious MSG_CRYPTO msg to deploy its key with no need to know other nodes' keys. This patch is to do that by checking TIPC_SKB_CB(skb)->decrypted and discard it if this packet never got decrypted. Note that this is also a supplementary fix to CVE-2021-43267 that can be triggered by an unencrypted malicious MSG_CRYPTO msg. Fixes: 1ef6f7c9390f ("tipc: add automatic session key exchange") Acked-by: Ying Xue Acked-by: Jon Maloy Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit aff97b89a38e458f5ad088f4f58a99ea7a785cfd Author: Sriharsha Basavapatna Date: Mon Nov 15 02:38:01 2021 -0500 bnxt_en: reject indirect blk offload when hw-tc-offload is off [ Upstream commit b0757491a118ae5727cf9f1c3a11544397d46596 ] The driver does not check if hw-tc-offload is enabled for the device before offloading a flow in the context of indirect block callback. Fix this by checking NETIF_F_HW_TC in the features flag and rejecting the offload request. This will avoid unnecessary dmesg error logs when hw-tc-offload is disabled, such as these: bnxt_en 0000:19:00.1 eno2np1: dev(ifindex=294) not on same switch bnxt_en 0000:19:00.1 eno2np1: Error: bnxt_tc_add_flow: cookie=0xffff8dace1c88000 error=-22 bnxt_en 0000:19:00.0 eno1np0: dev(ifindex=294) not on same switch bnxt_en 0000:19:00.0 eno1np0: Error: bnxt_tc_add_flow: cookie=0xffff8dace1c88000 error=-22 Reported-by: Marcelo Ricardo Leitner Fixes: 627c89d00fb9 ("bnxt_en: flow_offload: offload tunnel decap rules via indirect callbacks") Signed-off-by: Sriharsha Basavapatna Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 61566668ef3f2775a7c29a44707a6617509d9229 Author: Pavel Skripkin Date: Sun Nov 14 01:36:36 2021 +0300 net: bnx2x: fix variable dereferenced before check [ Upstream commit f8885ac89ce310570e5391fe0bf0ec9c7c9b4fdc ] Smatch says: bnx2x_init_ops.h:640 bnx2x_ilt_client_mem_op() warn: variable dereferenced before check 'ilt' (see line 638) Move ilt_cli variable initialization _after_ ilt validation, because it's unsafe to deref the pointer before validation check. Fixes: 523224a3b3cd ("bnx2x, cnic, bnx2i: use new FW/HSI") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit aa67407ebb6d4aa034fd89572e28d503e5b6edcf Author: Li Zhijian Date: Mon Nov 8 09:28:49 2021 +0800 selftests: gpio: fix gpio compiling error [ Upstream commit 92a59d7f381d2caf69385bfa00590028e32eea26 ] The gpio selftests build against the system includes rather than the headers from the linux tree. This results in the compile failing if the system includes are outdated. Prefer the headers from the linux tree, as per other selftests. Fixes: 8bc395a6a2e2 ("selftests: gpio: rework and simplify test implementation") Reported-by: kernel test robot Signed-off-by: Li Zhijian [Kent: reworded commit comment and added Fixes:] Signed-off-by: Kent Gibson Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 05a48cba24593c683e2514914f36bbd14df410b5 Author: Alex Elder Date: Fri Nov 12 16:22:10 2021 -0600 net: ipa: disable HOLB drop when updating timer [ Upstream commit 816316cacad2b5abd5b41423cf04e4845239abd4 ] The head-of-line blocking timer should only be modified when head-of-line drop is disabled. One of the steps in recovering from a modem crash is to enable dropping of packets with timeout of 0 (immediate). We don't know how the modem configured its endpoints, so before we program the timer, we need to ensure HOL_BLOCK is disabled. Fixes: 84f9bd12d46db ("soc: qcom: ipa: IPA endpoints") Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0f3de700c6951e710b1122b6f338c6f8966cee34 Author: Alex Elder Date: Fri Nov 12 16:22:09 2021 -0600 net: ipa: HOLB register sometimes must be written twice [ Upstream commit 6e228d8cbb1cc6ba78022d406340e901e08d26e0 ] Starting with IPA v4.5, the HOL_BLOCK_EN register must be written twice when enabling head-of-line blocking avoidance. Fixes: 84f9bd12d46db ("soc: qcom: ipa: IPA endpoints") Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e10e13319025503805cdb730317b0613df32499a Author: Johannes Berg Date: Fri Nov 12 13:51:44 2021 +0100 mac80211: fix monitor_sdata RCU/locking assertions [ Upstream commit 6dd2360334f3cb3b45fc1b8194c670090474b87c ] Since commit a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver") we've not only been protecting the pointer to monitor_sdata with the RTNL, but also with the wiphy->mtx. This is relevant in a number of lockdep assertions, e.g. the one we hit in ieee80211_set_monitor_channel(). However, we're now protecting all the assignments/dereferences, even the one in interface iter, with the wiphy->mtx, so switch over the lockdep assertions to that lock. Fixes: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver") Signed-off-by: Johannes Berg Link: https://lore.kernel.org/r/20211112135143.cb8e8ceffef3.Iaa210f16f6904c8a7a24954fb3396da0ef86ec08@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1d17f6179182bda790717520186d2fd475c73c73 Author: Johannes Berg Date: Fri Oct 29 09:25:39 2021 +0200 nl80211: fix radio statistics in survey dump [ Upstream commit ce6b69749961426c6d822215ded9e67154e1ad4f ] Even if userspace specifies the NL80211_ATTR_SURVEY_RADIO_STATS attribute, we cannot get the statistics because we're not really parsing the incoming attributes properly any more. Fix this by passing the attrbuf to nl80211_prepare_wdev_dump() and filling it there, if given, and using a local version only if no output is desired. Since I'm touching it anyway, make nl80211_prepare_wdev_dump() static. Fixes: 50508d941c18 ("cfg80211: use parallel_ops for genl") Reported-by: Jan Fuchs Signed-off-by: Johannes Berg Tested-by: Sven Eckelmann Link: https://lore.kernel.org/r/20211029092539.2851b4799386.If9736d4575ee79420cbec1bd930181e1d53c7317@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 85f4a563c9e4a2dd7d4e48da224c64232caef1ee Author: Steven Rostedt (VMware) Date: Sun Nov 14 13:28:34 2021 -0500 tracing: Add length protection to histogram string copies [ Upstream commit 938aa33f14657c9ed9deea348b7d6f14b6d69cb7 ] The string copies to the histogram storage has a max size of 256 bytes (defined by MAX_FILTER_STR_VAL). Only the string size of the event field needs to be copied to the event storage, but no more than what is in the event storage. Although nothing should be bigger than 256 bytes, there's no protection against overwriting of the storage if one day there is. Copy no more than the destination size, and enforce it. Also had to turn MAX_FILTER_STR_VAL into an unsigned int, to keep the min() comparison of the string sizes of comparable types. Link: https://lore.kernel.org/all/CAHk-=wjREUihCGrtRBwfX47y_KrLCGjiq3t6QtoNJpmVrAEb1w@mail.gmail.com/ Link: https://lkml.kernel.org/r/20211114132834.183429a4@rorschach.local.home Cc: Ingo Molnar Cc: Andrew Morton Cc: Tom Zanussi Reported-by: Linus Torvalds Reviewed-by: Masami Hiramatsu Fixes: 63f84ae6b82b ("tracing/histogram: Do not copy the fixed-size char array field over the field size") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 0efd57d82ece871da6a783f96235da6ba8c771f5 Author: Arjun Roy Date: Thu Nov 11 15:52:15 2021 -0800 tcp: Fix uninitialized access in skb frags array for Rx 0cp. [ Upstream commit 70701b83e208767f2720d8cd3e6a62cddafb3a30 ] TCP Receive zerocopy iterates through the SKB queue via tcp_recv_skb(), acquiring a pointer to an SKB and an offset within that SKB to read from. From there, it iterates the SKB frags array to determine which offset to start remapping pages from. However, this is built on the assumption that the offset read so far within the SKB is smaller than the SKB length. If this assumption is violated, we can attempt to read an invalid frags array element, which would cause a fault. tcp_recv_skb() can cause such an SKB to be returned when the TCP FIN flag is set. Therefore, we must guard against this occurrence inside skb_advance_frag(). One way that we can reproduce this error follows: 1) In a receiver program, call getsockopt(TCP_ZEROCOPY_RECEIVE) with: char some_array[32 * 1024]; struct tcp_zerocopy_receive zc = { .copybuf_address = (__u64) &some_array[0], .copybuf_len = 32 * 1024, }; 2) In a sender program, after a TCP handshake, send the following sequence of packets: i) Seq = [X, X+4000] ii) Seq = [X+4000, X+5000] iii) Seq = [X+4000, X+5000], Flags = FIN | URG, urgptr=1000 (This can happen without URG, if we have a signal pending, but URG is a convenient way to reproduce the behaviour). In this case, the following event sequence will occur on the receiver: tcp_zerocopy_receive(): -> receive_fallback_to_copy() // copybuf_len >= inq -> tcp_recvmsg_locked() // reads 5000 bytes, then breaks due to URG -> tcp_recv_skb() // yields skb with skb->len == offset -> tcp_zerocopy_set_hint_for_skb() -> skb_advance_to_frag() // will returns a frags ptr. >= nr_frags -> find_next_mappable_frag() // will dereference this bad frags ptr. With this patch, skb_advance_to_frag() will no longer return an invalid frags pointer, and will return NULL instead, fixing the issue. Signed-off-by: Arjun Roy Signed-off-by: Eric Dumazet Fixes: 05255b823a61 ("tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive") Link: https://lore.kernel.org/r/20211111235215.2605384-1-arjunroy.kdev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f4d1328e6e304c81db81419d92b9d90b7b3cf9ab Author: Konrad Dybcio Date: Thu Nov 11 19:37:24 2021 +0100 net/ipa: ipa_resource: Fix wrong for loop range [ Upstream commit 27df68d579c67ef6c39a5047559b6a7c08c96219 ] The source group count was mistakenly assigned to both dst and src loops. Fix it to make IPA probe and work again. Fixes: 4fd704b3608a ("net: ipa: record number of groups in data") Acked-by: AngeloGioacchino Del Regno Reviewed-by: Marijn Suijten Signed-off-by: Konrad Dybcio Reviewed-by: Alex Elder Link: https://lore.kernel.org/r/20211111183724.593478-1-konrad.dybcio@somainline.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e9fd8938118ab44fb40ea2bb8052392c5d42a30c Author: Jakub Kicinski Date: Thu Nov 11 08:29:29 2021 -0800 selftests: net: switch to socat in the GSO GRE test [ Upstream commit 0cda7d4bac5fd29dceb13df26083333fa99d6bb4 ] Commit a985442fdecb ("selftests: net: properly support IPv6 in GSO GRE test") is not compatible with: Ncat: Version 7.80 ( https://nmap.org/ncat ) (which is distributed with Fedora/Red Hat), tests fail with: nc: invalid option -- 'N' Let's switch to socat which is far more dependable. Fixes: 025efa0a82df ("selftests: add simple GSO GRE test") Fixes: a985442fdecb ("selftests: net: properly support IPv6 in GSO GRE test") Tested-by: Andrea Righi Link: https://lore.kernel.org/r/20211111162929.530470-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f49175809074c292706d2fcb403177beed5afd49 Author: Kumar Kartikeya Dwivedi Date: Fri Nov 12 07:33:01 2021 +0530 samples/bpf: Fix incorrect use of strlen in xdp_redirect_cpu [ Upstream commit 2453afe3845523d9dfe89dbfb3d71abfa095e260 ] Commit b599015f044d ("samples/bpf: Fix application of sizeof to pointer") tried to fix a bug where sizeof was incorrectly applied to a pointer instead of the array string was being copied to, to find the destination buffer size, but ended up using strlen, which is still incorrect. However, on closer look ifname_buf has no other use, hence directly use optarg. Fixes: b599015f044d ("samples/bpf: Fix application of sizeof to pointer") Fixes: e531a220cc59 ("samples: bpf: Convert xdp_redirect_cpu to XDP samples helper") Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Daniel Borkmann Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Link: https://lore.kernel.org/bpf/20211112020301.528357-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ff12332ec614c40e1d16f274852f5c67a0328cd6 Author: Alexander Lobakin Date: Thu Nov 11 22:57:03 2021 +0100 samples/bpf: Fix summary per-sec stats in xdp_sample_user [ Upstream commit dc14ca4644f48b1cfa93631e35c28bdc011ad109 ] sample_summary_print() uses accumulated period to calculate and display per-sec averages. This period gets incremented by sampling interval each time a new sample is formed, and thus equals to the number of samples collected multiplied by this interval. However, the totals are being calculated differently, they receive current sample statistics already divided by the interval gotten as a difference between sample timestamps for better precision -- in other words, they are being incremented by the per-sec values each sample. This leads to the excessive division of summary per-secs when interval != 1 sec. It is obvious pps couldn't become two times lower just from picking a different sampling interval value: $ samples/bpf/xdp_redirect_cpu -p xdp_prognum_n1_inverse_qnum -c all -s -d 6 -i 1 < snip > Packets received : 2,197,230,321 Average packets/s : 22,887,816 Packets redirected : 2,197,230,472 Average redir/s : 22,887,817 $ samples/bpf/xdp_redirect_cpu -p xdp_prognum_n1_inverse_qnum -c all -s -d 6 -i 2 < snip > Packets received : 159,566,498 Average packets/s : 11,397,607 Packets redirected : 159,566,995 Average redir/s : 11,397,642 This can be easily fixed by treating the divisor not as a period, but rather as a total number of samples, and thus incrementing it by 1 instead of interval. As a nice side effect, we can now remove so-named argument from a couple of functions. Let us also create an "alias" for sample_output::rx_cnt::pps named 'num' using a union since this field is used to store this number (period previously) as well, and the resulting counter-intuitive code might've been a reason for this bug. Fixes: 156f886cf697 ("samples: bpf: Add basic infrastructure for XDP samples") Signed-off-by: Alexander Lobakin Signed-off-by: Daniel Borkmann Reviewed-by: Jesse Brandeburg Reviewed-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/bpf/20211111215703.690-1-alexandr.lobakin@intel.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit bd454200664173ace6867edc55b14dd45bb00b26 Author: Alexei Starovoitov Date: Wed Nov 10 09:25:56 2021 -0800 bpf: Fix inner map state pruning regression. [ Upstream commit 34d11a440c6167133201b7374065b59f259730d7 ] Introduction of map_uid made two lookups from outer map to be distinct. That distinction is only necessary when inner map has an embedded timer. Otherwise it will make the verifier state pruning to be conservative which will cause complex programs to hit 1M insn_processed limit. Tighten map_uid logic to apply to inner maps with timers only. Fixes: 3e8ce29850f1 ("bpf: Prevent pointer mismatch in bpf_timer_init.") Reported-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Tested-by: Lorenz Bauer Link: https://lore.kernel.org/bpf/CACAyw99hVEJFoiBH_ZGyy=+oO-jyydoz6v1DeKPKs2HVsUH28w@mail.gmail.com Link: https://lore.kernel.org/bpf/20211110172556.20754-1-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin commit 8369b01aa5a6eedcc32ca06d3a5057811c0d8889 Author: Hans Verkuil Date: Wed Nov 10 16:36:04 2021 +0100 drm/nouveau: hdmigv100.c: fix corrupted HDMI Vendor InfoFrame [ Upstream commit 3cc1ae1fa70ab369e4645e38ce335a19438093ad ] gv100_hdmi_ctrl() writes vendor_infoframe.subpack0_high to 0x6f0110, and then overwrites it with 0. Just drop the overwrite with 0, that's clearly a mistake. Because of this issue the HDMI VIC is 0 instead of 1 in the HDMI Vendor InfoFrame when transmitting 4kp30. Signed-off-by: Hans Verkuil Fixes: 290ffeafcc1a ("drm/nouveau/disp/gv100: initial support") Reviewed-by: Ben Skeggs Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/3d3bd0f7-c150-2479-9350-35d394ee772d@xs4all.nl Signed-off-by: Sasha Levin commit 07b486f1a8febd2980a529f032dda3b5d3e09125 Author: James Clark Date: Thu Oct 28 14:48:26 2021 +0100 perf tests: Remove bash construct from record+zstd_comp_decomp.sh [ Upstream commit a9cdc1c5e3700a5200e5ca1f90b6958b6483845b ] Commit 463538a383a2 ("perf tests: Fix test 68 zstd compression for s390") inadvertently removed the -g flag from all platforms rather than just s390, because the [[ ]] construct fails in sh. Changing to single brackets restores testing of call graphs and removes the following error from the output: $ ./perf test -v 85 85: Zstd perf.data compression/decompression : --- start --- test child forked, pid 50643 Collecting compressed record file: ./tests/shell/record+zstd_comp_decomp.sh: 15: [[: not found Fixes: 463538a383a2 ("perf tests: Fix test 68 zstd compression for s390") Signed-off-by: James Clark Cc: Alexander Shishkin Cc: Florian Fainelli Cc: Ian Rogers Cc: Jiri Olsa Cc: John Fastabend Cc: KP Singh Cc: Mark Rutland Cc: Martin KaFai Lau Cc: Namhyung Kim Cc: Song Liu Cc: Sumanth Korikkar Cc: Thomas Richter Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/20211028134828.65774-3-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 99643bdc6ff1c75ccd2871368fbcd20e8231d77e Author: Sohaib Mohamed Date: Fri Nov 12 22:11:33 2021 +0200 perf bench futex: Fix memory leak of perf_cpu_map__new() [ Upstream commit 88e48238d53682281c9de2a0b65d24d3b64542a0 ] ASan reports memory leaks while running: $ sudo ./perf bench futex all The leaks are caused by perf_cpu_map__new not being freed. This patch adds the missing perf_cpu_map__put since it calls cpu_map_delete implicitly. Fixes: 9c3516d1b850ea93 ("libperf: Add perf_cpu_map__new()/perf_cpu_map__read() functions") Signed-off-by: Sohaib Mohamed Cc: Alexander Shishkin Cc: André Almeida Cc: Darren Hart Cc: Davidlohr Bueso Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Sohaib Mohamed Cc: Thomas Gleixner Link: http://lore.kernel.org/lkml/20211112201134.77892-1-sohaib.amhmd@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ab7c3d8d81c511ddfb27823fb07081c96422b56e Author: Ian Rogers Date: Thu Nov 11 23:45:25 2021 -0800 perf bpf: Avoid memory leak from perf_env__insert_btf() [ Upstream commit 4924b1f7c46711762fd0e65c135ccfbcfd6ded1f ] perf_env__insert_btf() doesn't insert if a duplicate BTF id is encountered and this causes a memory leak. Modify the function to return a success/error value and then free the memory if insertion didn't happen. v2. Adds a return -1 when the insertion error occurs in perf_env__fetch_btf. This doesn't affect anything as the result is never checked. Fixes: 3792cb2ff43b1b19 ("perf bpf: Save BTF in a rbtree in perf_env") Signed-off-by: Ian Rogers Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Jiri Olsa Cc: John Fastabend Cc: KP Singh Cc: Mark Rutland Cc: Martin KaFai Lau Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Stephane Eranian Cc: Tiezhu Yang Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20211112074525.121633-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 05e13b4a53b5d9885096eb00cd3fd60a25cd66a4 Author: Masami Hiramatsu Date: Sat Nov 13 01:02:08 2021 +0900 tracing/histogram: Do not copy the fixed-size char array field over the field size [ Upstream commit 63f84ae6b82bb4dff672f76f30c6fd7b9d3766bc ] Do not copy the fixed-size char array field of the events over the field size. The histogram treats char array as a string and there are 2 types of char array in the event, fixed-size and dynamic string. The dynamic string (__data_loc) field must be null terminated, but the fixed-size char array field may not be null terminated (not a string, but just a data). In that case, histogram can copy the data after the field. This uses the original field size for fixed-size char array field to restrict the histogram not to access over the original field size. Link: https://lkml.kernel.org/r/163673292822.195747.3696966210526410250.stgit@devnote2 Fixes: 02205a6752f2 (tracing: Add support for 'field variables') Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 04096d1b66cfece1e01b5a9c7d74833fce5c2f07 Author: Laibin Qiu Date: Fri Nov 12 17:33:54 2021 +0800 blkcg: Remove extra blkcg_bio_issue_init [ Upstream commit b781d8db580c058ecd54ed7d5dde7f8270b25f5b ] KASAN reports a use-after-free report when doing block test: ================================================================== [10050.967049] BUG: KASAN: use-after-free in submit_bio_checks+0x1539/0x1550 [10050.977638] Call Trace: [10050.978190] dump_stack+0x9b/0xce [10050.979674] print_address_description.constprop.6+0x3e/0x60 [10050.983510] kasan_report.cold.9+0x22/0x3a [10050.986089] submit_bio_checks+0x1539/0x1550 [10050.989576] submit_bio_noacct+0x83/0xc80 [10050.993714] submit_bio+0xa7/0x330 [10050.994435] mpage_readahead+0x380/0x500 [10050.998009] read_pages+0x1c1/0xbf0 [10051.002057] page_cache_ra_unbounded+0x4c2/0x6f0 [10051.007413] do_page_cache_ra+0xda/0x110 [10051.008207] force_page_cache_ra+0x23d/0x3d0 [10051.009087] page_cache_sync_ra+0xca/0x300 [10051.009970] generic_file_buffered_read+0xbea/0x2130 [10051.012685] generic_file_read_iter+0x315/0x490 [10051.014472] blkdev_read_iter+0x113/0x1b0 [10051.015300] aio_read+0x2ad/0x450 [10051.023786] io_submit_one+0xc8e/0x1d60 [10051.029855] __se_sys_io_submit+0x125/0x350 [10051.033442] do_syscall_64+0x2d/0x40 [10051.034156] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [10051.048733] Allocated by task 18598: [10051.049482] kasan_save_stack+0x19/0x40 [10051.050263] __kasan_kmalloc.constprop.1+0xc1/0xd0 [10051.051230] kmem_cache_alloc+0x146/0x440 [10051.052060] mempool_alloc+0x125/0x2f0 [10051.052818] bio_alloc_bioset+0x353/0x590 [10051.053658] mpage_alloc+0x3b/0x240 [10051.054382] do_mpage_readpage+0xddf/0x1ef0 [10051.055250] mpage_readahead+0x264/0x500 [10051.056060] read_pages+0x1c1/0xbf0 [10051.056758] page_cache_ra_unbounded+0x4c2/0x6f0 [10051.057702] do_page_cache_ra+0xda/0x110 [10051.058511] force_page_cache_ra+0x23d/0x3d0 [10051.059373] page_cache_sync_ra+0xca/0x300 [10051.060198] generic_file_buffered_read+0xbea/0x2130 [10051.061195] generic_file_read_iter+0x315/0x490 [10051.062189] blkdev_read_iter+0x113/0x1b0 [10051.063015] aio_read+0x2ad/0x450 [10051.063686] io_submit_one+0xc8e/0x1d60 [10051.064467] __se_sys_io_submit+0x125/0x350 [10051.065318] do_syscall_64+0x2d/0x40 [10051.066082] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [10051.067455] Freed by task 13307: [10051.068136] kasan_save_stack+0x19/0x40 [10051.068931] kasan_set_track+0x1c/0x30 [10051.069726] kasan_set_free_info+0x1b/0x30 [10051.070621] __kasan_slab_free+0x111/0x160 [10051.071480] kmem_cache_free+0x94/0x460 [10051.072256] mempool_free+0xd6/0x320 [10051.072985] bio_free+0xe0/0x130 [10051.073630] bio_put+0xab/0xe0 [10051.074252] bio_endio+0x3a6/0x5d0 [10051.074984] blk_update_request+0x590/0x1370 [10051.075870] scsi_end_request+0x7d/0x400 [10051.076667] scsi_io_completion+0x1aa/0xe50 [10051.077503] scsi_softirq_done+0x11b/0x240 [10051.078344] blk_mq_complete_request+0xd4/0x120 [10051.079275] scsi_mq_done+0xf0/0x200 [10051.080036] virtscsi_vq_done+0xbc/0x150 [10051.080850] vring_interrupt+0x179/0x390 [10051.081650] __handle_irq_event_percpu+0xf7/0x490 [10051.082626] handle_irq_event_percpu+0x7b/0x160 [10051.083527] handle_irq_event+0xcc/0x170 [10051.084297] handle_edge_irq+0x215/0xb20 [10051.085122] asm_call_irq_on_stack+0xf/0x20 [10051.085986] common_interrupt+0xae/0x120 [10051.086830] asm_common_interrupt+0x1e/0x40 ================================================================== Bio will be checked at beginning of submit_bio_noacct(). If bio needs to be throttled, it will start the timer and stop submit bio directly. Bio will submit in blk_throtl_dispatch_work_fn() when the timer expires. But in the current process, if bio is throttled, it will still set bio issue->value by blkcg_bio_issue_init(). This is redundant and may cause the above use-after-free. CPU0 CPU1 submit_bio submit_bio_noacct submit_bio_checks blk_throtl_bio() <=mod_timer(&sq->pending_timer blk_throtl_dispatch_work_fn submit_bio_noacct() <= bio have throttle tag, will throw directly and bio issue->value will be set here bio_endio() bio_put() bio_free() <= free this bio blkcg_bio_issue_init(bio) <= bio has been freed and will lead to UAF return BLK_QC_T_NONE Fix this by remove extra blkcg_bio_issue_init. Fixes: e439bedf6b24 (blkcg: consolidate bio_issue_init() to be a part of core) Signed-off-by: Laibin Qiu Link: https://lore.kernel.org/r/20211112093354.3581504-1-qiulaibin@huawei.com Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit eda355db53c4c67808aa30484bf2f94b94fdf32c Author: Like Xu Date: Wed Nov 3 17:17:16 2021 +0800 perf/x86/vlbr: Add c->flags to vlbr event constraints [ Upstream commit 5863702561e625903ec678551cb056a4b19e0b8a ] Just like what we do in the x86_get_event_constraints(), the PERF_X86_EVENT_LBR_SELECT flag should also be propagated to event->hw.flags so that the host lbr driver can save/restore MSR_LBR_SELECT for the special vlbr event created by KVM or BPF. Fixes: 097e4311cda9 ("perf/x86: Add constraint to create guest LBR event without hw counter") Reported-by: Wanpeng Li Signed-off-by: Like Xu Signed-off-by: Peter Zijlstra (Intel) Tested-by: Wanpeng Li Link: https://lore.kernel.org/r/20211103091716.59906-1-likexu@tencent.com Signed-off-by: Sasha Levin commit 512e21c150c1c3ee298852660f3a796e267e62ec Author: Mathias Krause Date: Wed Nov 3 20:06:13 2021 +0100 sched/fair: Prevent dead task groups from regaining cfs_rq's [ Upstream commit b027789e5e50494c2325cc70c8642e7fd6059479 ] Kevin is reporting crashes which point to a use-after-free of a cfs_rq in update_blocked_averages(). Initial debugging revealed that we've live cfs_rq's (on_list=1) in an about to be kfree()'d task group in free_fair_sched_group(). However, it was unclear how that can happen. His kernel config happened to lead to a layout of struct sched_entity that put the 'my_q' member directly into the middle of the object which makes it incidentally overlap with SLUB's freelist pointer. That, in combination with SLAB_FREELIST_HARDENED's freelist pointer mangling, leads to a reliable access violation in form of a #GP which made the UAF fail fast. Michal seems to have run into the same issue[1]. He already correctly diagnosed that commit a7b359fc6a37 ("sched/fair: Correctly insert cfs_rq's to list on unthrottle") is causing the preconditions for the UAF to happen by re-adding cfs_rq's also to task groups that have no more running tasks, i.e. also to dead ones. His analysis, however, misses the real root cause and it cannot be seen from the crash backtrace only, as the real offender is tg_unthrottle_up() getting called via sched_cfs_period_timer() via the timer interrupt at an inconvenient time. When unregister_fair_sched_group() unlinks all cfs_rq's from the dying task group, it doesn't protect itself from getting interrupted. If the timer interrupt triggers while we iterate over all CPUs or after unregister_fair_sched_group() has finished but prior to unlinking the task group, sched_cfs_period_timer() will execute and walk the list of task groups, trying to unthrottle cfs_rq's, i.e. re-add them to the dying task group. These will later -- in free_fair_sched_group() -- be kfree()'ed while still being linked, leading to the fireworks Kevin and Michal are seeing. To fix this race, ensure the dying task group gets unlinked first. However, simply switching the order of unregistering and unlinking the task group isn't sufficient, as concurrent RCU walkers might still see it, as can be seen below: CPU1: CPU2: : timer IRQ: : do_sched_cfs_period_timer(): : : : distribute_cfs_runtime(): : rcu_read_lock(); : : : unthrottle_cfs_rq(): sched_offline_group(): : : walk_tg_tree_from(…,tg_unthrottle_up,…): list_del_rcu(&tg->list); : (1) : list_for_each_entry_rcu(child, &parent->children, siblings) : : (2) list_del_rcu(&tg->siblings); : : tg_unthrottle_up(): unregister_fair_sched_group(): struct cfs_rq *cfs_rq = tg->cfs_rq[cpu_of(rq)]; : : list_del_leaf_cfs_rq(tg->cfs_rq[cpu]); : : : : if (!cfs_rq_is_decayed(cfs_rq) || cfs_rq->nr_running) (3) : list_add_leaf_cfs_rq(cfs_rq); : : : : : : : : : : (4) : rcu_read_unlock(); CPU 2 walks the task group list in parallel to sched_offline_group(), specifically, it'll read the soon to be unlinked task group entry at (1). Unlinking it on CPU 1 at (2) therefore won't prevent CPU 2 from still passing it on to tg_unthrottle_up(). CPU 1 now tries to unlink all cfs_rq's via list_del_leaf_cfs_rq() in unregister_fair_sched_group(). Meanwhile CPU 2 will re-add some of these at (3), which is the cause of the UAF later on. To prevent this additional race from happening, we need to wait until walk_tg_tree_from() has finished traversing the task groups, i.e. after the RCU read critical section ends in (4). Afterwards we're safe to call unregister_fair_sched_group(), as each new walk won't see the dying task group any more. On top of that, we need to wait yet another RCU grace period after unregister_fair_sched_group() to ensure print_cfs_stats(), which might run concurrently, always sees valid objects, i.e. not already free'd ones. This patch survives Michal's reproducer[2] for 8h+ now, which used to trigger within minutes before. [1] https://lore.kernel.org/lkml/20211011172236.11223-1-mkoutny@suse.com/ [2] https://lore.kernel.org/lkml/20211102160228.GA57072@blackbody.suse.cz/ Fixes: a7b359fc6a37 ("sched/fair: Correctly insert cfs_rq's to list on unthrottle") [peterz: shuffle code around a bit] Reported-by: Kevin Tanguy Signed-off-by: Mathias Krause Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Sasha Levin commit e4511d8dc2560945385a9a137bb54e408c4d51b9 Author: Vincent Donnefort Date: Thu Nov 4 17:51:20 2021 +0000 sched/core: Mitigate race cpus_share_cache()/update_top_cache_domain() [ Upstream commit 42dc938a590c96eeb429e1830123fef2366d9c80 ] Nothing protects the access to the per_cpu variable sd_llc_id. When testing the same CPU (i.e. this_cpu == that_cpu), a race condition exists with update_top_cache_domain(). One scenario being: CPU1 CPU2 ================================================================== per_cpu(sd_llc_id, CPUX) => 0 partition_sched_domains_locked() detach_destroy_domains() cpus_share_cache(CPUX, CPUX) update_top_cache_domain(CPUX) per_cpu(sd_llc_id, CPUX) => 0 per_cpu(sd_llc_id, CPUX) = CPUX per_cpu(sd_llc_id, CPUX) => CPUX return false ttwu_queue_cond() wouldn't catch smp_processor_id() == cpu and the result is a warning triggered from ttwu_queue_wakelist(). Avoid a such race in cpus_share_cache() by always returning true when this_cpu == that_cpu. Fixes: 518cd6234178 ("sched: Only queue remote wakeups when crossing cache boundaries") Reported-by: Jing-Ting Wu Signed-off-by: Vincent Donnefort Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Reviewed-by: Vincent Guittot Link: https://lore.kernel.org/r/20211104175120.857087-1-vincent.donnefort@arm.com Signed-off-by: Sasha Levin commit 725b5c9984ccdd4b95eab8446835bb233682ab4f Author: Randy Dunlap Date: Tue Nov 9 19:09:44 2021 -0800 MIPS: boot/compressed/: add __bswapdi2() to target for ZSTD decompression [ Upstream commit e2f4b3be1d3c73176db734565b160250cc1300dd ] For MIPS pre-boot, when CONFIG_KERNEL_ZSTD=y, the decompressor function uses __bswapdi2(), so this object file should be added to the target object file. Fixes these build errors: mips-linux-ld: arch/mips/boot/compressed/decompress.o: in function `xxh64': decompress.c:(.text+0x8be0): undefined reference to `__bswapdi2' mips-linux-ld: decompress.c:(.text+0x8c78): undefined reference to `__bswapdi2' mips-linux-ld: decompress.c:(.text+0x8d04): undefined reference to `__bswapdi2' mips-linux-ld: arch/mips/boot/compressed/decompress.o:decompress.c:(.text+0xa010): more undefined references to `__bswapdi2' follow Fixes: 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers") Fixes: cddc40f5617e ("mips: always link byteswap helpers into decompressor") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Arnd Bergmann Cc: Thomas Bogendoerfer Cc: linux-mips@vger.kernel.org Acked-by: Arnd Bergmann Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 1e3220ec23d9f5d808e56b16802e370587c1b96f Author: Randy Dunlap Date: Sat Nov 6 08:49:11 2021 -0700 mips: BCM63XX: ensure that CPU_SUPPORTS_32BIT_KERNEL is set [ Upstream commit 5eeaafc8d69373c095e461bdb39e5c9b62228ac5 ] Several header files need info on CONFIG_32BIT or CONFIG_64BIT, but kconfig symbol BCM63XX does not provide that info. This leads to many build errors, e.g.: arch/mips/include/asm/page.h:196:13: error: use of undeclared identifier 'CAC_BASE' return x - PAGE_OFFSET + PHYS_OFFSET; arch/mips/include/asm/mach-generic/spaces.h:91:23: note: expanded from macro 'PAGE_OFFSET' #define PAGE_OFFSET (CAC_BASE + PHYS_OFFSET) arch/mips/include/asm/io.h:134:28: error: use of undeclared identifier 'CAC_BASE' return (void *)(address + PAGE_OFFSET - PHYS_OFFSET); arch/mips/include/asm/mach-generic/spaces.h:91:23: note: expanded from macro 'PAGE_OFFSET' #define PAGE_OFFSET (CAC_BASE + PHYS_OFFSET) arch/mips/include/asm/uaccess.h:82:10: error: use of undeclared identifier '__UA_LIMIT' return (__UA_LIMIT & (addr | (addr + size) | __ua_size(size))) == 0; Selecting the SYS_HAS_CPU_BMIPS* symbols causes SYS_HAS_CPU_BMIPS to be set, which then selects CPU_SUPPORT_32BIT_KERNEL, which causes CONFIG_32BIT to be set. (a bit more indirect than v1 [RFC].) Fixes: e7300d04bd08 ("MIPS: BCM63xx: Add support for the Broadcom BCM63xx family of SOCs.") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Thomas Bogendoerfer Cc: Florian Fainelli Cc: bcm-kernel-feedback-list@broadcom.com Cc: linux-mips@vger.kernel.org Cc: Paul Burton Cc: Maxime Bizon Cc: Ralf Baechle Suggested-by: Florian Fainelli Acked-by: Florian Fainelli Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit c0c51afb2e8cc8bc617c58dff6e562b5fe719f51 Author: Quentin Perret Date: Mon Nov 8 15:46:32 2021 +0000 KVM: arm64: Fix host stage-2 finalization [ Upstream commit 50a8d3315960c74095c59e204db44abd937d4b5d ] We currently walk the hypervisor stage-1 page-table towards the end of hyp init in nVHE protected mode and adjust the host page ownership attributes in its stage-2 in order to get a consistent state from both point of views. The walk is done on the entire hyp VA space, and expects to only ever find page-level mappings. While this expectation is reasonable in the half of hyp VA space that maps memory with a fixed offset (see the loop in pkvm_create_mappings_locked()), it can be incorrect in the other half where nothing prevents the usage of block mappings. For instance, on systems where memory is physically aligned at an address that happens to maps to a PMD aligned VA in the hyp_vmemmap, kvm_pgtable_hyp_map() will install block mappings when backing the hyp_vmemmap, which will later cause finalize_host_mappings() to fail. Furthermore, it should be noted that all pages backing the hyp_vmemmap are also mapped in the 'fixed offset range' of the hypervisor, which implies that finalize_host_mappings() will walk both aliases and update the host stage-2 attributes twice. The order in which this happens is unpredictable, though, since the hyp VA layout is highly dependent on the position of the idmap page, hence resulting in a fragile mess at best. In order to fix all of this, let's restrict the finalization walk to only cover memory regions in the 'fixed-offset range' of the hyp VA space and nothing else. This not only fixes a correctness issue, but will also result in a slighlty faster hyp initialization overall. Fixes: 2c50166c62ba ("KVM: arm64: Mark host bss and rodata section as shared") Signed-off-by: Quentin Perret Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20211108154636.393384-1-qperret@google.com Signed-off-by: Sasha Levin commit 595e359751d66775ec6ea3f0aee8bc2a5ad83d68 Author: Dmitry Baryshkov Date: Thu Nov 4 04:11:55 2021 +0300 clk: qcom: gcc-msm8996: Drop (again) gcc_aggre1_pnoc_ahb_clk [ Upstream commit 05cf3ec00d460b50088d421fb878a0f83f57e262 ] The gcc_aggre1_pnoc_ahb_clk is crucial for the proper MSM8996/APQ8096 functioning. If it gets disabled, several subsytems will stop working (including eMMC/SDCC and USB). There are no in-kernel users of this clock, so it is much simpler to remove from the kernel. The clock was first removed in the commit 9e60de1cf270 ("clk: qcom: Remove gcc_aggre1_pnoc_ahb_clk from msm8996") by Stephen Boyd, but got added back in the commit b567752144e3 ("clk: qcom: Add some missing gcc clks for msm8996") by Rajendra Nayak. Let's remove it again in hope that nobody adds it back. Reported-by: Vladimir Zapolskiy Cc: Rajendra Nayak Cc: Konrad Dybcio Fixes: b567752144e3 ("clk: qcom: Add some missing gcc clks for msm8996") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20211104011155.2209654-1-dmitry.baryshkov@linaro.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit c4584223f5de309c0dae2df1ac412ac9a99a6e07 Author: Joel Stanley Date: Thu Sep 23 09:24:49 2021 +0930 clk/ast2600: Fix soc revision for AHB [ Upstream commit f45c5b1c27293f834682e89003f88b3512329ab4 ] Move the soc revision parsing to the initial probe, saving the driver from parsing the register multiple times. Use this variable to select the correct divisor table for the AHB clock. Before this fix the A2 would have used the A0 table. Fixes: 2d491066ccd4 ("clk: ast2600: Fix AHB clock divider for A1") Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20210922235449.213631-1-joel@jms.id.au Reviewed-by: Andrew Jeffery Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 3024018bb2df1c709b8b959e7f7719e30b49092e Author: Paul Cercueil Date: Fri Oct 1 18:20:33 2021 +0100 clk: ingenic: Fix bugs with divided dividers [ Upstream commit ed84ef1cd7eddf933d4ffce2caa8161d6f947245 ] Two fixes in one: - In the "impose hardware constraints" block, the "logical" divider value (aka. not translated to the hardware) was clamped to fit in the register area, but this totally ignored the fact that the divider value can itself have a fixed divider. - The code that made sure that the divider value returned by the function was a multiple of its own fixed divider could result in a wrong value being calculated, because it was rounded down instead of rounded up. Fixes: 4afe2d1a6ed5 ("clk: ingenic: Allow divider value to be divided") Co-developed-by: Artur Rojek Signed-off-by: Artur Rojek Signed-off-by: Paul Cercueil Link: https://lore.kernel.org/r/20211001172033.122329-1-paul@crapouillou.net Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 680a0c6332c48df1b900b3c535e920e7cc453b7e Author: Chao Yu Date: Thu Oct 28 20:45:08 2021 +0800 f2fs: fix incorrect return value in f2fs_sanity_check_ckpt() [ Upstream commit ca98d72141dd81f42893a9a43d7ededab3355fba ] As Pavel Machek reported in [1] This code looks quite confused: part of function returns 1 on corruption, part returns -errno. The problem is not stable-specific. [1] https://lkml.org/lkml/2021/9/19/207 Let's fix to make 'insane cp_payload case' to return 1 rater than EFSCORRUPTED, so that return value can be kept consistent for all error cases, it can avoid confusion of code logic. Fixes: 65ddf6564843 ("f2fs: fix to do sanity check for sb/cp fields correctly") Reported-by: Pavel Machek Reviewed-by: Pavel Machek Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 9c9afedf3ac58aa8a88964068e9ad6ec6cafdb2f Author: Hyeong-Jun Kim Date: Wed Oct 27 13:16:00 2021 +0900 f2fs: compress: disallow disabling compress on non-empty compressed file [ Upstream commit 02d58cd253d7536c412993573fc6b3b4454960eb ] Compresse file and normal file has differ in i_addr addressing, specifically addrs per inode/block. So, we will face data loss, if we disable the compression flag on non-empty files. Therefore we should disallow not only enabling but disabling the compression flag on non-empty files. Fixes: 4c8ff7095bef ("f2fs: support data compression") Signed-off-by: Sungjong Seo Signed-off-by: Hyeong-Jun Kim Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 3d937f901cea25765a3dea5f54c4a04322790f6e Author: Randy Dunlap Date: Mon Oct 4 17:19:13 2021 -0700 sh: define __BIG_ENDIAN for math-emu [ Upstream commit b929926f01f2d14635345d22eafcf60feed1085e ] Fix this by defining both ENDIAN macros in so that they can be utilized in according to the latter's comment: /* Allow sfp-machine to have its own byte order definitions. */ (This is what is done in arch/nds32/include/asm/sfp-machine.h.) This placates these build warnings: In file included from ../arch/sh/math-emu/math.c:23: .../include/math-emu/single.h:50:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef] 50 | #if __BYTE_ORDER == __BIG_ENDIAN In file included from ../arch/sh/math-emu/math.c:24: .../include/math-emu/double.h:59:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef] 59 | #if __BYTE_ORDER == __BIG_ENDIAN Fixes: 4b565680d163 ("sh: math-emu support") Signed-off-by: Randy Dunlap Cc: Yoshinori Sato Cc: John Paul Adrian Glaubitz Reviewed-by: Geert Uytterhoeven Tested-by: John Paul Adrian Glaubitz Signed-off-by: Rich Felker Signed-off-by: Sasha Levin commit d21ad7abba7564338e1ee92ce47119881c298626 Author: Randy Dunlap Date: Mon Oct 4 17:19:12 2021 -0700 sh: math-emu: drop unused functions [ Upstream commit e25c252a9b033523c626f039d4b9a304f12f6775 ] Delete ieee_fpe_handler() since it is not used. After that is done, delete denormal_to_double() since it is not used: .../arch/sh/math-emu/math.c:505:12: error: 'ieee_fpe_handler' defined but not used [-Werror=unused-function] 505 | static int ieee_fpe_handler(struct pt_regs *regs) .../arch/sh/math-emu/math.c:477:13: error: 'denormal_to_double' defined but not used [-Werror=unused-function] 477 | static void denormal_to_double(struct sh_fpu_soft_struct *fpu, int n) Fixes: 7caf62de25554da3 ("sh: remove unused do_fpu_error") Signed-off-by: Randy Dunlap Cc: Takashi YOSHII Cc: Yoshinori Sato Cc: John Paul Adrian Glaubitz Reviewed-by: Geert Uytterhoeven Signed-off-by: Rich Felker Signed-off-by: Sasha Levin commit c29506bfcf8b9eaed155b245cbed77d8fec48369 Author: Randy Dunlap Date: Mon Oct 4 17:19:10 2021 -0700 sh: fix kconfig unmet dependency warning for FRAME_POINTER [ Upstream commit fda1bc533094a7db68b11e7503d2c6c73993d12a ] FRAME_POINTER depends on DEBUG_KERNEL so DWARF_UNWINDER should depend on DEBUG_KERNEL before selecting FRAME_POINTER. WARNING: unmet direct dependencies detected for FRAME_POINTER Depends on [n]: DEBUG_KERNEL [=n] && (M68K || UML || SUPERH [=y]) || ARCH_WANT_FRAME_POINTERS [=n] Selected by [y]: - DWARF_UNWINDER [=y] Fixes: bd353861c735 ("sh: dwarf unwinder support.") Signed-off-by: Randy Dunlap Cc: Matt Fleming Cc: Matt Fleming Cc: Yoshinori Sato Cc: John Paul Adrian Glaubitz Cc: Geert Uytterhoeven Reviewed-by: Geert Uytterhoeven Tested-by: John Paul Adrian Glaubitz Signed-off-by: Rich Felker Signed-off-by: Sasha Levin commit 7228ed3293e0fbe5beb2c8c71a470f62ebc8db7d Author: Chao Yu Date: Wed Sep 29 03:19:14 2021 +0800 f2fs: fix wrong condition to trigger background checkpoint correctly [ Upstream commit cd6d697a6e2013a0a85f8b261b16c8cfd50c1f5f ] In f2fs_balance_fs_bg(), it needs to check both NAT_ENTRIES and INO_ENTRIES memory usage to decide whether we should skip background checkpoint, otherwise we may always skip checking INO_ENTRIES memory usage, so that INO_ENTRIES may potentially cause high memory footprint. Fixes: 493720a48543 ("f2fs: fix to avoid REQ_TIME and CP_TIME collision") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 9ad4e63e3cca9f41bdc8850a19a207a0b009344c Author: Keoseong Park Date: Mon Sep 27 15:06:48 2021 +0900 f2fs: fix to use WHINT_MODE [ Upstream commit 011e0868e0cf1237675b22e36fffa958fb08f46e ] Since active_logs can be set to 2 or 4 or NR_CURSEG_PERSIST_TYPE(6), it cannot be set to NR_CURSEG_TYPE(8). That is, whint_mode is always off. Therefore, the condition is changed from NR_CURSEG_TYPE to NR_CURSEG_PERSIST_TYPE. Cc: Chao Yu Fixes: d0b9e42ab615 (f2fs: introduce inmem curseg) Reported-by: tanghuan Signed-off-by: Keoseong Park Signed-off-by: Fengnan Chang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 0dfaa04f0161a4a48eaa03911f2fa1c1ee1f8a4c Author: Gao Xiang Date: Tue Sep 21 22:37:30 2021 +0800 f2fs: fix up f2fs_lookup tracepoints [ Upstream commit 70a9ac36ffd807ac506ed0b849f3e8ce3c6623f2 ] Fix up a misuse that the filename pointer isn't always valid in the ring buffer, and we should copy the content instead. Fixes: 0c5e36db17f5 ("f2fs: trace f2fs_lookup") Signed-off-by: Gao Xiang Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 6d28f6ba633dcd7653ecf84b299a2fbb947f86df Author: Lu Wei Date: Thu Nov 26 10:43:11 2020 +0800 maple: fix wrong return value of maple_bus_init(). [ Upstream commit bde82ee391fa6d3ad054313c4aa7b726d32515ce ] If KMEM_CACHE or maple_alloc_dev failed, the maple_bus_init() will return 0 rather than error, because the retval is not changed after KMEM_CACHE or maple_alloc_dev failed. Fixes: 17be2d2b1c33 ("sh: Add maple bus support for the SEGA Dreamcast.") Reported-by: Hulk Robot Signed-off-by: Lu Wei Acked-by: John Paul Adrian Glaubitz Signed-off-by: Rich Felker Signed-off-by: Sasha Levin commit b80a7977299ac35206102c4e11cc98663c66df22 Author: Nick Desaulniers Date: Tue Dec 22 12:54:01 2020 -0800 sh: check return code of request_irq [ Upstream commit 0e38225c92c7964482a8bb6b3e37fde4319e965c ] request_irq is marked __must_check, but the call in shx3_prepare_cpus has a void return type, so it can't propagate failure to the caller. Follow cues from hexagon and just print an error. Fixes: c7936b9abcf5 ("sh: smp: Hook in to the generic IPI handler for SH-X3 SMP.") Cc: Miguel Ojeda Cc: Paul Mundt Reported-by: Guenter Roeck Signed-off-by: Nick Desaulniers Tested-by: John Paul Adrian Glaubitz Reviewed-by: Miguel Ojeda Signed-off-by: Rich Felker Signed-off-by: Sasha Levin commit 23274bd8d7ad28f721e21faa0df24d3e335eb749 Author: Christophe Leroy Date: Fri Oct 29 17:10:45 2021 +0200 powerpc/8xx: Fix Oops with STRICT_KERNEL_RWX without DEBUG_RODATA_TEST [ Upstream commit c12ab8dbc492b992e1ea717db933cee568780c47 ] Until now, all tests involving CONFIG_STRICT_KERNEL_RWX were done with DEBUG_RODATA_TEST to check the result. But now that CONFIG_STRICT_KERNEL_RWX is selected by default, it came without CONFIG_DEBUG_RODATA_TEST and led to the following Oops [ 6.830908] Freeing unused kernel image (initmem) memory: 352K [ 6.840077] BUG: Unable to handle kernel data access on write at 0xc1285200 [ 6.846836] Faulting instruction address: 0xc0004b6c [ 6.851745] Oops: Kernel access of bad area, sig: 11 [#1] [ 6.857075] BE PAGE_SIZE=16K PREEMPT CMPC885 [ 6.861348] SAF3000 DIE NOTIFICATION [ 6.864830] CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0-rc5-s3k-dev-02255-g2747d7b7916f #451 [ 6.873429] NIP: c0004b6c LR: c0004b60 CTR: 00000000 [ 6.878419] REGS: c902be60 TRAP: 0300 Not tainted (5.15.0-rc5-s3k-dev-02255-g2747d7b7916f) [ 6.886852] MSR: 00009032 CR: 53000335 XER: 8000ff40 [ 6.893564] DAR: c1285200 DSISR: 82000000 [ 6.893564] GPR00: 0c000000 c902bf20 c20f4000 08000000 00000001 04001f00 c1800000 00000035 [ 6.893564] GPR08: ff0001ff c1280000 00000002 c0004b60 00001000 00000000 c0004b1c 00000000 [ 6.893564] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 6.893564] GPR24: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c1060000 [ 6.932034] NIP [c0004b6c] kernel_init+0x50/0x138 [ 6.936682] LR [c0004b60] kernel_init+0x44/0x138 [ 6.941245] Call Trace: [ 6.943653] [c902bf20] [c0004b60] kernel_init+0x44/0x138 (unreliable) [ 6.950022] [c902bf30] [c001122c] ret_from_kernel_thread+0x5c/0x64 [ 6.956135] Instruction dump: [ 6.959060] 48ffc521 48045469 4800d8cd 3d20c086 89295fa0 2c090000 41820058 480796c9 [ 6.966890] 4800e48d 3d20c128 39400002 3fe0c106 <91495200> 3bff8000 4806fa1d 481f7d75 [ 6.974902] ---[ end trace 1e397bacba4aa610 ]--- 0xc1285200 corresponds to 'system_state' global var that the kernel is trying to set to SYSTEM_RUNNING. This var is above the RO/RW limit so it shouldn't Oops. It oopses because the dirty bit is missing. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/3d5800b0bbcd7b19761b98f50421358667b45331.1635520232.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 2f4dede20cdffc69182cde199d397f5a7f184177 Author: Michael Ellerman Date: Thu Oct 14 13:44:24 2021 +1100 powerpc/dcr: Use cmplwi instead of 3-argument cmpli [ Upstream commit fef071be57dc43679a32d5b0e6ee176d6f12e9f2 ] In dcr-low.S we use cmpli with three arguments, instead of four arguments as defined in the ISA: cmpli cr0,r3,1024 This appears to be a PPC440-ism, looking at the "PPC440x5 CPU Core User’s Manual" it shows cmpli having no L field, but implied to be 0 due to the core being 32-bit. It mentions that the ISA defines four arguments and recommends using cmplwi. It also corresponds to the old POWER instruction set, which had no L field there, a reserved bit instead. dcr-low.S is only built 32-bit, because it is only built when DCR_NATIVE=y, which is only selected by 40x and 44x. Looking at the generated code (with gcc/gas) we see cmplwi as expected. Although gas is happy with the 3-argument version when building for 32-bit, the LLVM assembler is not and errors out with: arch/powerpc/sysdev/dcr-low.S:27:10: error: invalid operand for instruction cmpli 0,%r3,1024; ... ^ Switch to the cmplwi extended opcode, which avoids any confusion when reading the ISA, fixes the issue with the LLVM assembler, and also means the code could be built 64-bit in future (though that's very unlikely). Reported-by: Nick Desaulniers Reviewed-by: Nick Desaulniers Signed-off-by: Michael Ellerman BugLink: https://github.com/ClangBuiltLinux/linux/issues/1419 Link: https://lore.kernel.org/r/20211014024424.528848-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 3c0c79d1261e7f6dc871e22740ce6b0b430b90f5 Author: Sven Peter Date: Tue Oct 19 18:22:53 2021 +0200 iommu/dart: Initialize DART_STREAMS_ENABLE [ Upstream commit 5a009fc1364170b240a4d351b345e69bb3728b3e ] DART has an additional global register to control which streams are isolated. This register is a bit redundant since DART_TCR can already be used to control isolation and is usually initialized to DART_STREAM_ALL by the time we get control. Some DARTs (namely the one used for the audio controller) however have some streams disabled initially. Make sure those work by initializing DART_STREAMS_ENABLE during reset. Reported-by: Martin Povišer Signed-off-by: Sven Peter Reviewed-by: Hector Martin Link: https://lore.kernel.org/r/20211019162253.45919-1-sven@svenpeter.dev Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit c4ea7b0c6180b84a22a72087972ef1fc8ca3ce97 Author: Claudiu Beznea Date: Mon Oct 11 14:27:17 2021 +0300 clk: at91: sama7g5: remove prescaler part of master clock [ Upstream commit facb87ad75603813bc3b1314f5a87377f020fcb8 ] On SAMA7G5 the prescaler part of master clock has been implemented as a changeable one. Everytime the prescaler is changed the PMC_SR.MCKRDY bit must be polled. Value 1 for PMC_SR.MCKRDY means the prescaler update is done. Driver polls for this bit until it becomes 1. On SAMA7G5 it has been discovered that in some conditions the PMC_SR.MCKRDY is not rising but the rate it provides it's stable. The workaround is to add a timeout when polling for PMC_SR.MCKRDY. At the moment, for SAMA7G5, the prescaler will be removed from Linux clock tree as all the frequencies for CPU could be obtained from PLL and also there will be less overhead when changing frequency via DVFS. Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20211011112719.3951784-14-claudiu.beznea@microchip.com Acked-by: Nicolas Ferre Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 58fa50de595f152900594c28ec9915c169643739 Author: Chengfeng Ye Date: Sun Oct 24 04:17:36 2021 -0700 ALSA: usb-audio: fix null pointer dereference on pointer cs_desc [ Upstream commit b97053df0f04747c3c1e021ecbe99db675342954 ] The pointer cs_desc return from snd_usb_find_clock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference. Signed-off-by: Chengfeng Ye Link: https://lore.kernel.org/r/20211024111736.11342-1-cyeaa@connect.ust.hk Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 16721797dcef2c7c030ffe73a07f39a65f9323c3 Author: Chengfeng Ye Date: Sun Oct 24 03:46:11 2021 -0700 ALSA: gus: fix null pointer dereference on pointer block [ Upstream commit a0d21bb3279476c777434c40d969ea88ca64f9aa ] The pointer block return from snd_gf1_dma_next_block could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference. Signed-off-by: Chengfeng Ye Link: https://lore.kernel.org/r/20211024104611.9919-1-cyeaa@connect.ust.hk Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3f8da4b87f13e029e4169a48992f4b7e4b719df1 Author: Stephan Gerhold Date: Mon Oct 18 13:00:08 2021 +0200 arm64: dts: qcom: Fix node name of rpm-msg-ram device nodes [ Upstream commit 179811bebc7b91e0f9d0adee9bfa3d2af9c43869 ] According to the new DT schema for qcom,rpm-msg-ram the node name should be sram@. memory@ is reserved for definition of physical RAM (usable by Linux). This fixes the following dtbs_check error on various device trees: memory@60000: 'device_type' is a required property From schema: dtschema/schemas/memory.yaml Signed-off-by: Stephan Gerhold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211018110009.30837-1-stephan@gerhold.net Signed-off-by: Sasha Levin commit 93d0049268cdda2c8e1c1bc3a31f114b7c338280 Author: David Heidelberg Date: Wed Oct 20 23:47:41 2021 +0200 ARM: dts: qcom: fix memory and mdio nodes naming for RB3011 [ Upstream commit 14a1f6c9d8017ffbf388e82e1a1f023196d98612 ] Fixes warnings regarding to memory and mdio nodes and apply new naming following dt-schema. Signed-off-by: David Heidelberg Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211020214741.261509-1-david@ixit.cz Signed-off-by: Sasha Levin commit 72b4e7b7beba6812fbb16c1a62946d1bb0f538ee Author: Anatolij Gustschin Date: Thu Oct 14 00:05:31 2021 +0200 powerpc/5200: dts: fix memory node unit name [ Upstream commit aed2886a5e9ffc8269a4220bff1e9e030d3d2eb1 ] Fixes build warnings: Warning (unit_address_vs_reg): /memory: node has a reg or ranges property, but no unit name Signed-off-by: Anatolij Gustschin Reviewed-by: Rob Herring Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211013220532.24759-4-agust@denx.de Signed-off-by: Sasha Levin commit 619ce4646397deb33c12932044c5431937b3ac6c Author: Dmitry Osipenko Date: Wed Oct 20 02:15:24 2021 +0300 memory: tegra20-emc: Add runtime dependency on devfreq governor module [ Upstream commit 14b43c20c283de36131da0cb44f3170b9ffa7630 ] Tegra20 EMC driver uses simple devfreq governor. Add simple devfreq governor to the list of the Tegra20 EMC driver module softdeps to allow userspace initramfs tools like dracut to automatically pull the devfreq module into ramfs image together with the EMC module. Reported-by: Nicolas Chauvet Suggested-by: Nicolas Chauvet Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20211019231524.888-1-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit bf76f56a7fc751e6265c1b6ef85d138291f775ac Author: James Smart Date: Wed Oct 20 14:14:16 2021 -0700 scsi: lpfc: Allow fabric node recovery if recovery is in progress before devloss [ Upstream commit af984c87293b19dccbd0b16afc57c5c9a4a279c7 ] A link bounce to a slow fabric may observe FDISC response delays lasting longer than devloss tmo. Current logic decrements the final fabric node kref during a devloss tmo event. This results in a NULL ptr dereference crash if the FDISC completes for that fabric node after devloss tmo. Fix by adding the NLP_IN_RECOV_POST_DEV_LOSS flag, which is set when devloss tmo triggers and we've noticed that fabric node recovery has already started or finished in between the time lpfc_dev_loss_tmo_callbk queues lpfc_dev_loss_tmo_handler. If fabric node recovery succeeds, then the driver reverses the devloss tmo marked kref put with a kref get. If fabric node recovery fails, then the final kref put relies on the ELS timing out or the REG_LOGIN cmpl routine. Link: https://lore.kernel.org/r/20211020211417.88754-8-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 28de48a7cea495ab48082d9ff4ef63f7cb4e563a Author: James Smart Date: Wed Oct 20 14:14:15 2021 -0700 scsi: lpfc: Fix link down processing to address NULL pointer dereference [ Upstream commit 1854f53ccd88ad4e7568ddfafafffe71f1ceb0a6 ] If an FC link down transition while PLOGIs are outstanding to fabric well known addresses, outstanding ABTS requests may result in a NULL pointer dereference. Driver unload requests may hang with repeated "2878" log messages. The Link down processing results in ABTS requests for outstanding ELS requests. The Abort WQEs are sent for the ELSs before the driver had set the link state to down. Thus the driver is sending the Abort with the expectation that an ABTS will be sent on the wire. The Abort request is stalled waiting for the link to come up. In some conditions the driver may auto-complete the ELSs thus if the link does come up, the Abort completions may reference an invalid structure. Fix by ensuring that Abort set the flag to avoid link traffic if issued due to conditions where the link failed. Link: https://lore.kernel.org/r/20211020211417.88754-7-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dbebf865b3239595c1d4dba063b122862583b52a Author: James Smart Date: Wed Oct 20 14:14:13 2021 -0700 scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine [ Upstream commit 79b20beccea3a3938a8500acef4e6b9d7c66142f ] An error is detected with the following report when unloading the driver: "KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b" The NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but the flag is not cleared upon completion of the login. This allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi set to LPFC_RPI_ALLOW_ERROR. This results in a use after free access when used as an rpi_ids array index. Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in lpfc_mbx_cmpl_fc_reg_login(). Link: https://lore.kernel.org/r/20211020211417.88754-5-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 21903226c724c4465d82dba5b677a831e71c82db Author: wangyugui Date: Tue Oct 19 08:26:56 2021 +0800 RDMA/core: Use kvzalloc when allocating the struct ib_port [ Upstream commit 911a81c9c7092bfd75432ce79b2ef879127ea065 ] The 'struct attribute' flex array contains some struct lock_class_key's which become big when lockdep is turned on. Big enough that some drivers will not load when CONFIG_PROVE_LOCKING=y because they cannot allocate enough memory: WARNING: CPU: 36 PID: 8 at mm/page_alloc.c:5350 __alloc_pages+0x27e/0x3e0 Call Trace: kmalloc_order+0x2a/0xb0 kmalloc_order_trace+0x19/0xf0 __kmalloc+0x231/0x270 ib_setup_port_attrs+0xd8/0x870 [ib_core] ib_register_device+0x419/0x4e0 [ib_core] bnxt_re_task+0x208/0x2d0 [bnxt_re] Link: https://lore.kernel.org/r/20211019002656.17745-1-wangyugui@e16-tech.com Signed-off-by: wangyugui Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a9d2d23b5032ec0476d2724fa9c6dca3a1338b09 Author: Teng Qi Date: Mon Oct 11 19:40:03 2021 +0800 iio: imu: st_lsm6dsx: Avoid potential array overflow in st_lsm6dsx_set_odr() [ Upstream commit 94be878c882d8d784ff44c639bf55f3b029f85af ] The length of hw->settings->odr_table is 2 and ref_sensor->id is an enum variable whose value is between 0 and 5. However, the value ST_LSM6DSX_ID_MAX (i.e. 5) is not caught properly in switch (sensor->id) { If ref_sensor->id is ST_LSM6DSX_ID_MAX, an array overflow will ocurrs in function st_lsm6dsx_check_odr(): odr_table = &sensor->hw->settings->odr_table[sensor->id]; and in function st_lsm6dsx_set_odr(): reg = &hw->settings->odr_table[ref_sensor->id].reg; To avoid this array overflow, handle ST_LSM6DSX_ID_GYRO explicitly and return -EINVAL for the default case. The enum value ST_LSM6DSX_ID_MAX is only present as an easy way to check the limit and as such is never used, however this is not locally obvious. Reported-by: TOTE Robot Signed-off-by: Teng Qi Acked-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/20211011114003.976221-1-starmiku1207184332@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 26af3ab9325ef2436cbd7be003a26b154f6207a4 Author: Mike Christie Date: Wed Sep 29 21:04:20 2021 -0500 scsi: target: Fix alua_tg_pt_gps_count tracking [ Upstream commit 1283c0d1a32bb924324481586b5d6e8e76f676ba ] We can't free the tg_pt_gp in core_alua_set_tg_pt_gp_id() because it's still accessed via configfs. Its release must go through the normal configfs/refcount process. The max alua_tg_pt_gps_count check should probably have been done in core_alua_allocate_tg_pt_gp(), but with the current code userspace could have created 0x0000ffff + 1 groups, but only set the id for 0x0000ffff. Then it could have deleted a group with an ID set, and then set the ID for that extra group and it would work ok. It's unlikely, but just in case this patch continues to allow that type of behavior, and just fixes the kfree() while in use bug. Link: https://lore.kernel.org/r/20210930020422.92578-4-michael.christie@oracle.com Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a2489880354d56be70889edc533b9842bf945dc0 Author: Mike Christie Date: Wed Sep 29 21:04:19 2021 -0500 scsi: target: Fix ordered tag handling [ Upstream commit ed1227e080990ffec5bf39006ec8a57358e6689a ] This patch fixes the following bugs: 1. If there are multiple ordered cmds queued and multiple simple cmds completing, target_restart_delayed_cmds() could be called on different CPUs and each instance could start a ordered cmd. They could then run in different orders than they were queued. 2. target_restart_delayed_cmds() and target_handle_task_attr() can race where: 1. target_handle_task_attr() has passed the simple_cmds == 0 check. 2. transport_complete_task_attr() then decrements simple_cmds to 0. 3. transport_complete_task_attr() runs target_restart_delayed_cmds() and it does not see any cmds on the delayed_cmd_list. 4. target_handle_task_attr() adds the cmd to the delayed_cmd_list. The cmd will then end up timing out. 3. If we are sent > 1 ordered cmds and simple_cmds == 0, we can execute them out of order, because target_handle_task_attr() will hit that simple_cmds check first and return false for all ordered cmds sent. 4. We run target_restart_delayed_cmds() after every cmd completion, so if there is more than 1 simple cmd running, we start executing ordered cmds after that first cmd instead of waiting for all of them to complete. 5. Ordered cmds are not supposed to start until HEAD OF QUEUE and all older cmds have completed, and not just simple. 6. It's not a bug but it doesn't make sense to take the delayed_cmd_lock for every cmd completion when ordered cmds are almost never used. Just replacing that lock with an atomic increases IOPs by up to 10% when completions are spread over multiple CPUs and there are multiple sessions/ mqs/thread accessing the same device. This patch moves the queued delayed handling to a per device work to serialze the cmd executions for each device and adds a new counter to track HEAD_OF_QUEUE and SIMPLE cmds. We can then check the new counter to determine when to run the work on the completion path. Link: https://lore.kernel.org/r/20210930020422.92578-3-michael.christie@oracle.com Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 66523553fa62c7878fc5441dc4e82be71934eb77 Author: Ye Bin Date: Wed Oct 13 11:39:13 2021 +0800 scsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs() [ Upstream commit f347c26836c270199de1599c3cd466bb7747caa9 ] The following issue was observed running syzkaller: BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline] BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 Read of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815 CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe4/0x14a lib/dump_stack.c:118 print_address_description+0x73/0x280 mm/kasan/report.c:253 kasan_report_error mm/kasan/report.c:352 [inline] kasan_report+0x272/0x370 mm/kasan/report.c:410 memcpy+0x1f/0x50 mm/kasan/kasan.c:302 memcpy include/linux/string.h:377 [inline] sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021 resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772 schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429 scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835 scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896 scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034 __blk_run_queue_uncond block/blk-core.c:464 [inline] __blk_run_queue+0x1a4/0x380 block/blk-core.c:484 blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78 sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847 sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716 sg_write+0x64/0xa0 drivers/scsi/sg.c:622 __vfs_write+0xed/0x690 fs/read_write.c:485 kill_bdev:block_device:00000000e138492c vfs_write+0x184/0x4c0 fs/read_write.c:549 ksys_write+0x107/0x240 fs/read_write.c:599 do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe We get 'alen' from command its type is int. If userspace passes a large length we will get a negative 'alen'. Switch n, alen, and rlen to u32. Link: https://lore.kernel.org/r/20211013033913.2551004-3-yebin10@huawei.com Acked-by: Douglas Gilbert Signed-off-by: Ye Bin Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5b8bed6464ad6653586e30df046185fd816ad999 Author: Ye Bin Date: Wed Oct 13 11:39:12 2021 +0800 scsi: scsi_debug: Fix out-of-bound read in resp_readcap16() [ Upstream commit 4e3ace0051e7e504b55d239daab8789dd89b863c ] The following warning was observed running syzkaller: [ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in; [ 3813.830724] program syz-executor not setting count and/or reply_len properly [ 3813.836956] ================================================================== [ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0 [ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549 [ 3813.846612] Call Trace: [ 3813.846995] dump_stack+0x108/0x15f [ 3813.847524] print_address_description+0xa5/0x372 [ 3813.848243] kasan_report.cold+0x236/0x2a8 [ 3813.849439] check_memory_region+0x240/0x270 [ 3813.850094] memcpy+0x30/0x80 [ 3813.850553] sg_copy_buffer+0x157/0x1e0 [ 3813.853032] sg_copy_from_buffer+0x13/0x20 [ 3813.853660] fill_from_dev_buffer+0x135/0x370 [ 3813.854329] resp_readcap16+0x1ac/0x280 [ 3813.856917] schedule_resp+0x41f/0x1630 [ 3813.858203] scsi_debug_queuecommand+0xb32/0x17e0 [ 3813.862699] scsi_dispatch_cmd+0x330/0x950 [ 3813.863329] scsi_request_fn+0xd8e/0x1710 [ 3813.863946] __blk_run_queue+0x10b/0x230 [ 3813.864544] blk_execute_rq_nowait+0x1d8/0x400 [ 3813.865220] sg_common_write.isra.0+0xe61/0x2420 [ 3813.871637] sg_write+0x6c8/0xef0 [ 3813.878853] __vfs_write+0xe4/0x800 [ 3813.883487] vfs_write+0x17b/0x530 [ 3813.884008] ksys_write+0x103/0x270 [ 3813.886268] __x64_sys_write+0x77/0xc0 [ 3813.886841] do_syscall_64+0x106/0x360 [ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9 This issue can be reproduced with the following syzkaller log: r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0) r1 = syz_open_procfs(0xffffffffffffffff, &(0x7f0000000000)='fd/3\x00') open_by_handle_at(r1, &(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000) r2 = syz_open_dev$sg(&(0x7f0000000000), 0x0, 0x40782) write$binfmt_aout(r2, &(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126) In resp_readcap16() we get "int alloc_len" value -1104926854, and then pass the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This leads to OOB in sg_copy_buffer(). To solve this issue, define alloc_len as u32. Link: https://lore.kernel.org/r/20211013033913.2551004-2-yebin10@huawei.com Acked-by: Douglas Gilbert Signed-off-by: Ye Bin Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5777ab62b21ddcff50c9212a96cdc84ce97dd5e5 Author: Bart Van Assche Date: Tue Oct 12 15:23:12 2021 -0700 MIPS: sni: Fix the build [ Upstream commit c91cf42f61dc77b289784ea7b15a8531defa41c0 ] This patch fixes the following gcc 10 build error: arch/mips/sni/time.c: In function ‘a20r_set_periodic’: arch/mips/sni/time.c:15:26: error: unsigned conversion from ‘int’ to ‘u8’ {aka ‘volatile unsigned char’} changes value from ‘576’ to ‘64’ [-Werror=overflow] 15 | #define SNI_COUNTER0_DIV ((SNI_CLOCK_TICK_RATE / SNI_COUNTER2_DIV) / HZ) | ^ arch/mips/sni/time.c:21:45: note: in expansion of macro ‘SNI_COUNTER0_DIV’ 21 | *(volatile u8 *)(A20R_PT_CLOCK_BASE + 0) = SNI_COUNTER0_DIV; | ^~~~~~~~~~~~~~~~ Cc: linux-mips@vger.kernel.org Signed-off-by: Bart Van Assche Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 5c34486f04700f1ba04907231dce0cc2705c2d7d Author: Guanghui Feng Date: Mon Oct 11 22:08:24 2021 +0800 tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc [ Upstream commit 3968ddcf05fb4b9409cd1859feb06a5b0550a1c1 ] When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup, which look like this one: Workqueue: events_unbound flush_to_ldisc Call trace: dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220 __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120 In the testcase pty04, The first process call the write syscall to send data to the pty master. At the same time, the workqueue will do the flush_to_ldisc to pop data in a loop until there is no more data left. When the sender and workqueue running in different core, the sender sends data fastly in full time which will result in workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to avoid it. Signed-off-by: Guanghui Feng Link: https://lore.kernel.org/r/1633961304-24759-1-git-send-email-guanghuifeng@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0a85b47cd449e7e421cd941ad3a03beaa7fa0c85 Author: Tvrtko Ursulin Date: Thu Oct 14 13:38:31 2021 +0800 iommu/vt-d: Do not falsely log intel_iommu is unsupported kernel option [ Upstream commit 5240aed2cd2594fb392239f11b9681e5e1591619 ] Handling of intel_iommu kernel command line option should return "true" to indicate option is valid and so avoid logging it as unknown by the core parsing code. Also log unknown sub-options at the notice level to let user know of potential typos or similar. Reported-by: Eero Tamminen Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20210831112947.310080-1-tvrtko.ursulin@linux.intel.com Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20211014053839.727419-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 0a2ddbfd65b3fefece66a49fc7d7498aaabf1d2d Author: Randy Dunlap Date: Fri Oct 15 23:26:02 2021 -0700 ALSA: ISA: not for M68K [ Upstream commit 3c05f1477e62ea5a0a8797ba6a545b1dc751fb31 ] On m68k, compiling drivers under SND_ISA causes build errors: ../sound/core/isadma.c: In function 'snd_dma_program': ../sound/core/isadma.c:33:17: error: implicit declaration of function 'claim_dma_lock' [-Werror=implicit-function-declaration] 33 | flags = claim_dma_lock(); | ^~~~~~~~~~~~~~ ../sound/core/isadma.c:41:9: error: implicit declaration of function 'release_dma_lock' [-Werror=implicit-function-declaration] 41 | release_dma_lock(flags); | ^~~~~~~~~~~~~~~~ ../sound/isa/sb/sb16_main.c: In function 'snd_sb16_playback_prepare': ../sound/isa/sb/sb16_main.c:253:72: error: 'DMA_AUTOINIT' undeclared (first use in this function) 253 | snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_WRITE | DMA_AUTOINIT); | ^~~~~~~~~~~~ ../sound/isa/sb/sb16_main.c:253:72: note: each undeclared identifier is reported only once for each function it appears in ../sound/isa/sb/sb16_main.c: In function 'snd_sb16_capture_prepare': ../sound/isa/sb/sb16_main.c:322:71: error: 'DMA_AUTOINIT' undeclared (first use in this function) 322 | snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_READ | DMA_AUTOINIT); | ^~~~~~~~~~~~ and more... Signed-off-by: Randy Dunlap Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: alsa-devel@alsa-project.org Cc: linux-m68k@lists.linux-m68k.org Cc: Geert Uytterhoeven Link: https://lore.kernel.org/r/20211016062602.3588-1-rdunlap@infradead.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit eadee7f95b5d438f887d0a25474211e3307d4a36 Author: Li Yang Date: Tue Oct 12 18:58:23 2021 -0500 ARM: dts: ls1021a-tsn: use generic "jedec,spi-nor" compatible for flash [ Upstream commit 05e63b48b20fa70726be505a7660d1a07bc1cffb ] We cannot list all the possible chips used in different board revisions, just use the generic "jedec,spi-nor" compatible instead. This also fixes dtbs_check error: ['jedec,spi-nor', 's25fl256s1', 's25fl512s'] is too long Signed-off-by: Li Yang Reviewed-by: Kuldeep Singh Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 8e6920f7ac96609b1abe7d14f2bb798689b4ebb7 Author: Li Yang Date: Tue Oct 12 18:58:22 2021 -0500 ARM: dts: ls1021a: move thermal-zones node out of soc/ [ Upstream commit 1ee1500ef717eefb5d9bdaf97905cb81b4e69aa4 ] This fixes dtbs-check error from simple-bus schema: soc: thermal-zones: {'type': 'object'} is not allowed for {'cpu-thermal': ..... } From schema: /home/leo/.local/lib/python3.8/site-packages/dtschema/schemas/simple-bus.yaml Signed-off-by: Li Yang Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 8eab383460c4f29c8e6dc2e8a24e696334d3bee7 Author: Derek Fang Date: Thu Oct 14 17:40:54 2021 +0800 ASoC: rt5682: fix a little pop while playback [ Upstream commit 4b19e4a77cc6baa0f840e8bae62ab974667f6207 ] A little pop can be heard obviously from HP while playing a silent. This patch fixes it by using two functions: 1. Enable HP 1bit output mode. 2. Change the charge pump switch size during playback on and off. Signed-off-by: Derek Fang Link: https://lore.kernel.org/r/20211014094054.811-1-derek.fang@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 065334f6640d074a1caec2f8b0091467a22f9483 Author: Yang Yingliang Date: Mon Oct 11 21:49:20 2021 +0800 usb: host: ohci-tmio: check return value after calling platform_get_resource() [ Upstream commit 9eff2b2e59fda25051ab36cd1cb5014661df657b ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Acked-by: Alan Stern Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20211011134920.118477-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 31340f0135827f1083e1ae672d765731c72b4c5c Author: Roger Quadros Date: Thu Oct 7 15:08:30 2021 +0300 ARM: dts: omap: fix gpmc,mux-add-data type [ Upstream commit 51b9e22ffd3c4c56cbb7caae9750f70e55ffa603 ] gpmc,mux-add-data is not boolean. Fixes the below errors flagged by dtbs_check. "ethernet@4,0:gpmc,mux-add-data: True is not of type 'array'" Signed-off-by: Roger Quadros Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 1f45b73679b9f44ca29314a2bec2197676e37e74 Author: William Overton Date: Sun Oct 10 15:58:41 2021 +0100 ALSA: usb-audio: Add support for the Pioneer DJM 750MK2 Mixer/Soundcard [ Upstream commit 6d27788160362a7ee6c0d317636fe4b1ddbe59a7 ] The kernel already has support for very similar Pioneer djm products and this work is based on that. Added device to quirks-table.h and added control info to mixer_quirks.c. Tested on my hardware and all working. Signed-off-by: William Overton Link: https://lore.kernel.org/r/20211010145841.11907-1-willovertonuk@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 98b134cc4417c5b48788c65aa096bce07fe0bcd8 Author: José Expósito Date: Fri Oct 1 19:25:14 2021 +0200 HID: multitouch: disable sticky fingers for UPERFECT Y [ Upstream commit 08b9a61a87bc339a73c584d8924c86ab36d204a7 ] When a finger is on the screen, the UPERFECT Y portable touchscreen monitor reports a contact in the first place. However, after this initial report, contacts are not reported at the refresh rate of the screen as required by the Windows 8 specs. This behaviour triggers the release_timer, removing the fingers even though they are still present. To avoid it, add a new class, similar to MT_CLS_WIN_8 but without the MT_QUIRK_STICKY_FINGERS quirk for this device. Suggested-by: Benjamin Tissoires Signed-off-by: José Expósito Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c37f9ee2bb9fa1a474ddfa6b1e7e545b6c9d4fbf Author: Luis Chamberlain Date: Fri Sep 17 11:22:13 2021 -0700 firmware_loader: fix pre-allocated buf built-in firmware use [ Upstream commit f7a07f7b96033df7709042ff38e998720a3f7119 ] The firmware_loader can be used with a pre-allocated buffer through the use of the API calls: o request_firmware_into_buf() o request_partial_firmware_into_buf() If the firmware was built-in and present, our current check for if the built-in firmware fits into the pre-allocated buffer does not return any errors, and we proceed to tell the caller that everything worked fine. It's a lie and no firmware would end up being copied into the pre-allocated buffer. So if the caller trust the result it may end up writing a bunch of 0's to a device! Fix this by making the function that checks for the pre-allocated buffer return non-void. Since the typical use case is when no pre-allocated buffer is provided make this return successfully for that case. If the built-in firmware does *not* fit into the pre-allocated buffer size return a failure as we should have been doing before. I'm not aware of users of the built-in firmware using the API calls with a pre-allocated buffer, as such I doubt this fixes any real life issue. But you never know... perhaps some oddball private tree might use it. In so far as upstream is concerned this just fixes our code for correctness. Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20210917182226.3532898-2-mcgrof@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 966e4def900156c074e064381d70c546234a4061 Author: Pierre-Louis Bossart Date: Mon Oct 4 16:35:12 2021 -0500 ASoC: Intel: sof_sdw: add missing quirk for Dell SKU 0A45 [ Upstream commit 64ba6d2ce72ffde70dc5a1794917bf1573203716 ] This device is based on SDCA codecs but with a single amplifier instead of two. BugLink: https://github.com/thesofproject/linux/issues/3161 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20211004213512.220836-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1c6bd253dc9ccbe70a737911c7ea0e05ae650166 Author: Pierre-Louis Bossart Date: Mon Oct 4 16:35:11 2021 -0500 ASoC: Intel: soc-acpi: add missing quirk for TGL SDCA single amp [ Upstream commit f2470679b070a77ea22f8b791fae7084c2340c7d ] We don't have a configuration for a single amp on link1. BugLink: https://github.com/thesofproject/linux/issues/3161 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20211004213512.220836-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2e46a58adfc68dfaf73a930b5ef17db4a86ef8c7 Author: Pierre-Louis Bossart Date: Mon Oct 4 16:35:09 2021 -0500 ALSA: intel-dsp-config: add quirk for APL/GLK/TGL devices based on ES8336 codec [ Upstream commit 9d36ceab94151f07cf3fcb067213ac87937adf12 ] These devices are based on an I2C/I2S device, we need to force the use of the SOF driver otherwise the legacy HDaudio driver will be loaded - only HDMI will be supported. Co-developed-by: Huajun Li Signed-off-by: Huajun Li Signed-off-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Link: https://lore.kernel.org/r/20211004213512.220836-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fed89b5a4c18120138e797f51271b7571cbd075e Author: Frieder Schrempf Date: Thu Sep 30 17:56:30 2021 +0200 arm64: dts: imx8mm-kontron: Fix reset delays for ethernet PHY [ Upstream commit 315e7b884190a6c9c28e95ad3b724dde9e922b99 ] According to the datasheet the VSC8531 PHY expects a reset pulse of 100 ns and a delay of 15 ms after the reset has been deasserted. Set the matching values in the devicetree. Reported-by: Heiko Thiery Signed-off-by: Frieder Schrempf Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit d29faaf8168584e278131fe32e96a31ca9bc57e3 Author: Mahesh Rajashekhara Date: Tue Sep 28 18:54:33 2021 -0500 scsi: smartpqi: Add controller handshake during kdump [ Upstream commit 9ee5d6e9ac52a3c8625697535f8e35864d9fd38c ] Correct kdump hangs when controller is locked up. There are occasions when a controller reboot (controller soft reset) is issued when a controller firmware crash dump is in progress. This leads to incomplete controller firmware crash dump: - When the controller crash dump is in progress, and a kdump is initiated, the driver issues inbound doorbell reset to bring back the controller in SIS mode. - If the controller is in locked up state, the inbound doorbell reset does not work causing controller initialization failures. This results in the driver hanging waiting for SIS mode. To avoid an incomplete controller crash dump, add in a controller crash dump handshake: - Controller will indicate start and end of the controller crash dump by setting some register bits. - Driver will look these bits when a kdump is initiated. If a controller crash dump is in progress, the driver will wait for the controller crash dump to complete before issuing the controller soft reset then complete driver initialization. Link: https://lore.kernel.org/r/20210928235442.201875-3-don.brace@microchip.com Reviewed-by: Scott Benesh Reviewed-by: Scott Teel Reviewed-by: Mike McGowen Acked-by: John Donnelly Signed-off-by: Mahesh Rajashekhara Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 27490ae6a85a70242d80615ca74d0362a820d6a7 Author: Guo Zhi Date: Wed Sep 29 20:25:37 2021 +0800 scsi: advansys: Fix kernel pointer leak [ Upstream commit d4996c6eac4c81b8872043e9391563f67f13e406 ] Pointers should be printed with %p or %px rather than cast to 'unsigned long' and printed with %lx. Change %lx to %p to print the hashed pointer. Link: https://lore.kernel.org/r/20210929122538.1158235-1-qtxuning1999@sjtu.edu.cn Signed-off-by: Guo Zhi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7f37066e0d13070285c7de81f09353a94a91c9b2 Author: Hans de Goede Date: Sat Oct 2 23:14:57 2021 +0200 ASoC: nau8824: Add DMI quirk mechanism for active-high jack-detect [ Upstream commit 92d3360108f1839ca40451bad20ff67dd24a1964 ] Add a quirk mechanism to allow specifying that active-high jack-detection should be used on platforms where this info is not available in devicetree. And add an entry for the Cyberbook T116 tablet to the DMI table, so that jack-detection will work properly on this tablet. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20211002211459.110124-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 94ca62033dfbf87d314e6c8a7f13046b56275cb8 Author: Hans de Goede Date: Sun Oct 3 15:22:55 2021 +0200 ASoC: rt5651: Use IRQF_NO_AUTOEN when requesting the IRQ [ Upstream commit 6e037b72cf4ea6c28a131ea021d63ee4e7e6fa64 ] Use the new IRQF_NO_AUTOEN flag when requesting the IRQ, rather then disabling it immediately after requesting it. This fixes a possible race where the IRQ might trigger between requesting and disabling it; and this also leads to a small code cleanup. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20211003132255.31743-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0864d7f686f90823a32b528de200672840165419 Author: Hans de Goede Date: Sun Oct 3 15:22:54 2021 +0200 ASoC: es8316: Use IRQF_NO_AUTOEN when requesting the IRQ [ Upstream commit 1cf2aa665901054b140eb71748661ceae99b6b5a ] Use the new IRQF_NO_AUTOEN flag when requesting the IRQ, rather then disabling it immediately after requesting it. This fixes a possible race where the IRQ might trigger between requesting and disabling it; and this also leads to a small code cleanup. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20211003132255.31743-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 735939e2c8a7b60bf4df80eace262bd8ea93718f Author: Stefan Riedmueller Date: Mon Sep 27 09:28:56 2021 +0200 clk: imx: imx6ul: Move csi_sel mux to correct base register [ Upstream commit 2f9d61869640f732599ec36b984c2b5c46067519 ] The csi_sel mux register is located in the CCM register base and not the CCM_ANALOG register base. So move it to the correct position in code. Otherwise changing the parent of the csi clock can lead to a complete system failure due to the CCM_ANALOG_PLL_SYS_TOG register being falsely modified. Also remove the SET_RATE_PARENT flag since one possible supply for the csi_sel mux is the system PLL which we don't want to modify. Signed-off-by: Stefan Riedmueller Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20210927072857.3940880-1-s.riedmueller@phytec.de Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit daf932eae1fa6dec39b385d3990aed4c6bc0de17 Author: Geraldo Nascimento Date: Thu Sep 30 16:40:14 2021 -0300 ALSA: usb-audio: disable implicit feedback sync for Behringer UFX1204 and UFX1604 [ Upstream commit 28c369e60827f706cef4604a3e2848198f25bd26 ] Behringer UFX1204 and UFX1604 have Synchronous endpoints to which current ALSA code applies implicit feedback sync as if they were Asynchronous endpoints. This breaks UAC compliance and is unneeded. The commit 5e35dc0338d85ccebacf3f77eca1e5dea73155e8 and subsequent 1a15718b41df026cffd0e42cfdc38a1384ce19f9 were meant to clear up noise. Unfortunately, noise persisted for those using higher sample rates and this was only solved by commit d2e8f641257d0d3af6e45d6ac2d6f9d56b8ea964 Since there are no more reports of noise, let's get rid of the implicit-fb quirks breaking UAC compliance. Signed-off-by: Geraldo Nascimento Link: https://lore.kernel.org/r/YVYSnoQ7nxLXT0Dq@geday Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e15de347faf4a9f494cbd4e9a623d343dc1b5851 Author: Damien Le Moal Date: Fri Aug 20 16:02:53 2021 +0900 scsi: core: Fix scsi_mode_sense() buffer length handling [ Upstream commit 17b49bcbf8351d3dbe57204468ac34f033ed60bc ] Several problems exist with scsi_mode_sense() buffer length handling: 1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255. 2) If scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer. Fix these 2 problems by using put_unaligned_be16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error when len is too small. Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if the device driver did not set sdev->use_10_for_ms. In case of invalid opcode error for MODE SENSE(10), access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length overflows for the MODE_SENSE(10) case, check that len is smaller than 65535 bytes. While at it, also fix the folowing: * Use get_unaligned_be16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation. * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was. Link: https://lore.kernel.org/r/20210820070255.682775-2-damien.lemoal@wdc.com Signed-off-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ae893767385a310abdf29939dd60946988186ba2 Author: Pierre-Louis Bossart Date: Fri Sep 24 14:24:17 2021 -0500 ASoC: SOF: Intel: hda-dai: fix potential locking issue [ Upstream commit a20f3b10de61add5e14b6ce4df982f4df2a4cbbc ] The initial hdac_stream code was adapted a third time with the same locking issues. Move the spin_lock outside the loops and make sure the fields are protected on read/write. Signed-off-by: Pierre-Louis Bossart Acked-by: Mark Brown Link: https://lore.kernel.org/r/20210924192417.169243-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3cff8b789ea555053cd1c2fb9d7a80516e78f77b Author: Bob Pearson Date: Tue Sep 14 11:42:05 2021 -0500 RDMA/rxe: Separate HW and SW l/rkeys [ Upstream commit 001345339f4ca85790a1644a74e33ae77ac116be ] Separate software and simulated hardware lkeys and rkeys for MRs and MWs. This makes struct ib_mr and struct ib_mw isolated from hardware changes triggered by executing work requests. This change fixes a bug seen in blktest. Link: https://lore.kernel.org/r/20210914164206.19768-4-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b6f64bd4cf9fd7eb45278310cb9f14377cf1ff77 Author: Kuldeep Singh Date: Thu Sep 9 16:42:29 2021 +0530 arm64: dts: ls1012a: Add serial alias for ls1012a-rdb [ Upstream commit 7f31ae6e01da140e34d6513815253e811019f016 ] U-boot atempts to read serial alias value for ls1012a-rdb but couldn't do so as it is not initialised and thus, FDT_ERR_NOTFOUND error is reported while booting linux. Loading fdt from FIT Image at a0000000 ... Description: ls1012ardb-dtb Type: Flat Device Tree Data Start: 0xab111474 Data Size: 11285 Bytes = 11 KiB Architecture: AArch64 Load Address: 0x90000000 Loading fdt from 0xab111474 to 0x90000000 Booting using the fdt blob at 0x90000000 Uncompressing Kernel Image Loading Device Tree to 000000008fffa000, end 000000008ffffc14 ... OK WARNING: fdt_fixup_stdout: could not read serial0 alias: FDT_ERR_NOTFOUND NOTICE: RNG: INSTANTIATED Starting kernel ... Fix the above error by specifying serial value to duart. Signed-off-by: Kuldeep Singh Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 0479e598c773117e75f38741ac4a6a8debd47fac Author: Michael Walle Date: Thu Aug 26 14:35:28 2021 +0200 arm64: dts: freescale: fix arm,sp805 compatible string [ Upstream commit 99a7cacc66cae92db40139b57689be2af75fc6b8 ] According to Documentation/devicetree/bindings/watchdog/arm,sp805.yaml the compatible is: compatible = "arm,sp805", "arm,primecell"; The current compatible string doesn't exist at all. Fix it. Signed-off-by: Michael Walle Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 3f6946cfa798cf5b28586e08f9b51322b9e614ca Author: Shawn Guo Date: Sun Aug 29 19:16:28 2021 +0800 arm64: dts: qcom: sdm845: Fix qcom,controlled-remotely property [ Upstream commit 1c8bf398b6b51eb085a49036ad8f9c000171cce1 ] Property qcom,controlled-remotely should be boolean. Fix it. Signed-off-by: Shawn Guo Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210829111628.5543-4-shawn.guo@linaro.org Signed-off-by: Sasha Levin commit e608d43f7603a990081a0748fbaaba9c31599b37 Author: Shawn Guo Date: Sun Aug 29 19:16:27 2021 +0800 arm64: dts: qcom: ipq8074: Fix qcom,controlled-remotely property [ Upstream commit 8c97f0ac4dc8f1743eb8e8a49f66189e13ae45e9 ] Property qcom,controlled-remotely should be boolean. Fix it. Signed-off-by: Shawn Guo Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210829111628.5543-3-shawn.guo@linaro.org Signed-off-by: Sasha Levin commit 9bfe717293c06526420ad3586b451b3646488771 Author: Shawn Guo Date: Sun Aug 29 19:16:26 2021 +0800 arm64: dts: qcom: ipq6018: Fix qcom,controlled-remotely property [ Upstream commit 3509de752ea14c7e5781b3a56a4a0bf832f5723a ] Property qcom,controlled-remotely should be boolean. Fix it. Signed-off-by: Shawn Guo Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210829111628.5543-2-shawn.guo@linaro.org Signed-off-by: Sasha Levin commit 118c826ef8b43efe0fda8faf419673707ee8c5e5 Author: AngeloGioacchino Del Regno Date: Wed Sep 1 20:31:21 2021 +0200 arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency [ Upstream commit 3f1dcaff642e75c1d2ad03f783fa8a3b1f56dd50 ] The entry/exit latency and minimum residency in state for the idle states of MSM8998 were ..bad: first of all, for all of them the timings were written for CPU sleep but the min-residency-us param was miscalculated (supposedly, while porting this from downstream); Then, the power collapse states are setting PC on both the CPU cluster *and* the L2 cache, which have different timings: in the specific case of L2 the times are higher so these ones should be taken into account instead of the CPU ones. This parameter misconfiguration was not giving particular issues because on MSM8998 there was no CPU scaling at all, so cluster/L2 power collapse was rarely (if ever) hit. When CPU scaling is enabled, though, the wrong timings will produce SoC unstability shown to the user as random, apparently error-less, sudden reboots and/or lockups. This set of parameters are stabilizing the SoC when CPU scaling is ON and when power collapse is frequently hit. Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210901183123.1087392-3-angelogioacchino.delregno@somainline.org Signed-off-by: Sasha Levin commit 30a3826f7fa9035bfac6cc3b741758b2111e5936 Author: Christian Lamparter Date: Sat Sep 18 19:29:30 2021 +0200 ARM: BCM53016: Specify switch ports for Meraki MR32 [ Upstream commit 6abc4ca5a28070945e0d68cb4160b309bfbf4b8b ] the switch identifies itself as a BCM53012 (rev 5)... This patch has been tested & verified on OpenWrt's snapshot with Linux 5.10 (didn't test any older kernels). The MR32 is able to "talk to the network" as before with OpenWrt's SWITCHDEV b53 driver. | b53-srab-switch 18007000.ethernet-switch: found switch: BCM53012, rev 5 | libphy: dsa slave smi: probed | b53-srab-switch 18007000.ethernet-switch poe (uninitialized): | PHY [dsa-0.0:00] driver [Generic PHY] (irq=POLL) | b53-srab-switch 18007000.ethernet-switch: Using legacy PHYLIB callbacks. | Please migrate to PHYLINK! | DSA: tree 0 setup Reported-by: Rafał Miłecki Signed-off-by: Christian Lamparter Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit d330f1d4f797b05c85eaa76ad1db114f7214bd61 Author: Hans de Goede Date: Mon Sep 20 16:55:02 2021 +0200 staging: rtl8723bs: remove a third possible deadlock [ Upstream commit bdc1bbdbaa92df19a14d4c1902088c8432b46c6f ] The assoc_timer takes the pmlmepriv->lock and various functions which take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock, this means that we cannot have code which waits for the timer (timer_del_sync) while holding the pmlmepriv->scanned_queue.lock to avoid a triangle deadlock: [ 363.139361] ====================================================== [ 363.139377] WARNING: possible circular locking dependency detected [ 363.139396] 5.15.0-rc1+ #470 Tainted: G C E [ 363.139413] ------------------------------------------------------ [ 363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock: [ 363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs] [ 363.139598] but task is already holding lock: [ 363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260 [ 363.139673] which lock already depends on the new lock. [ 363.139684] the existing dependency chain (in reverse order) is: [ 363.139696] -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}: [ 363.139734] del_timer_sync+0x59/0x100 [ 363.139762] rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs] [ 363.139870] report_join_res+0xdf/0x110 [r8723bs] [ 363.139980] OnAssocRsp+0x17a/0x200 [r8723bs] [ 363.140092] rtw_recv_entry+0x190/0x1120 [r8723bs] [ 363.140209] rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs] [ 363.140318] tasklet_action_common.constprop.0+0xe8/0x110 [ 363.140345] __do_softirq+0xde/0x485 [ 363.140372] __irq_exit_rcu+0xd0/0x100 [ 363.140393] irq_exit_rcu+0xa/0x20 [ 363.140413] common_interrupt+0x83/0xa0 [ 363.140440] asm_common_interrupt+0x1e/0x40 [ 363.140463] finish_task_switch.isra.0+0x157/0x3d0 [ 363.140492] __schedule+0x447/0x1880 [ 363.140516] schedule+0x59/0xc0 [ 363.140537] smpboot_thread_fn+0x161/0x1c0 [ 363.140565] kthread+0x143/0x160 [ 363.140585] ret_from_fork+0x22/0x30 [ 363.140614] -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}: [ 363.140653] _raw_spin_lock_bh+0x34/0x40 [ 363.140675] rtw_free_network_queue+0x31/0x80 [r8723bs] [ 363.140776] rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs] [ 363.140869] rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs] [ 363.140973] rdev_scan+0x42/0x1a0 [cfg80211] [ 363.141307] nl80211_trigger_scan+0x566/0x660 [cfg80211] [ 363.141635] genl_family_rcv_msg_doit+0xcd/0x110 [ 363.141661] genl_rcv_msg+0xce/0x1c0 [ 363.141680] netlink_rcv_skb+0x50/0xf0 [ 363.141699] genl_rcv+0x24/0x40 [ 363.141717] netlink_unicast+0x16d/0x230 [ 363.141736] netlink_sendmsg+0x22b/0x450 [ 363.141755] sock_sendmsg+0x5e/0x60 [ 363.141781] ____sys_sendmsg+0x22f/0x270 [ 363.141803] ___sys_sendmsg+0x81/0xc0 [ 363.141828] __sys_sendmsg+0x49/0x80 [ 363.141851] do_syscall_64+0x3b/0x90 [ 363.141873] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 363.141895] -> #0 (&pmlmepriv->lock){+.-.}-{2:2}: [ 363.141930] __lock_acquire+0x1158/0x1de0 [ 363.141954] lock_acquire+0xb5/0x2b0 [ 363.141974] _raw_spin_lock_bh+0x34/0x40 [ 363.141993] _rtw_join_timeout_handler+0x3c/0x160 [r8723bs] [ 363.142097] call_timer_fn+0x94/0x260 [ 363.142122] __run_timers.part.0+0x1bf/0x290 [ 363.142147] run_timer_softirq+0x26/0x50 [ 363.142171] __do_softirq+0xde/0x485 [ 363.142193] __irq_exit_rcu+0xd0/0x100 [ 363.142215] irq_exit_rcu+0xa/0x20 [ 363.142235] sysvec_apic_timer_interrupt+0x72/0x90 [ 363.142260] asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 363.142283] __module_address.part.0+0x0/0xd0 [ 363.142309] is_module_address+0x25/0x40 [ 363.142334] static_obj+0x4f/0x60 [ 363.142361] lockdep_init_map_type+0x47/0x220 [ 363.142382] __init_swait_queue_head+0x45/0x60 [ 363.142408] mmc_wait_for_req+0x4a/0xc0 [mmc_core] [ 363.142504] mmc_wait_for_cmd+0x55/0x70 [mmc_core] [ 363.142592] mmc_io_rw_direct+0x75/0xe0 [mmc_core] [ 363.142691] sdio_writeb+0x2e/0x50 [mmc_core] [ 363.142788] _sd_cmd52_write+0x62/0x80 [r8723bs] [ 363.142885] sd_cmd52_write+0x6c/0xb0 [r8723bs] [ 363.142981] rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs] [ 363.143089] rtw_write16+0x1e/0x30 [r8723bs] [ 363.143184] SetHwReg8723B+0xcc9/0xd30 [r8723bs] [ 363.143294] mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs] [ 363.143405] rtw_joinbss_event_callback+0x11/0x20 [r8723bs] [ 363.143507] mlme_evt_hdl+0x4d/0x70 [r8723bs] [ 363.143620] rtw_cmd_thread+0x168/0x3c0 [r8723bs] [ 363.143712] kthread+0x143/0x160 [ 363.143732] ret_from_fork+0x22/0x30 [ 363.143757] other info that might help us debug this: [ 363.143768] Chain exists of: &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer) [ 363.143809] Possible unsafe locking scenario: [ 363.143819] CPU0 CPU1 [ 363.143831] ---- ---- [ 363.143841] lock((&pmlmepriv->assoc_timer)); [ 363.143862] lock(&pmlmepriv->scanned_queue.lock); [ 363.143882] lock((&pmlmepriv->assoc_timer)); [ 363.143902] lock(&pmlmepriv->lock); [ 363.143921] *** DEADLOCK *** Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before it deletes the timer to avoid this (it is still holding pmlmepriv->lock protecting against racing the timer). Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 12cfdef56c3b809c3e25dba5366f01856b734c0b Author: Hans de Goede Date: Mon Sep 20 16:55:01 2021 +0200 staging: rtl8723bs: remove a second possible deadlock [ Upstream commit a7ac783c338bafc04d3259600646350dba989043 ] Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock followed by it calling rtw_free_stainfo() which takes xmitpriv->lock. While the rtl8723bs_xmit_thread takes the sta_hash_lock while already holding the xmitpriv->lock: [ 103.849756] ====================================================== [ 103.849761] WARNING: possible circular locking dependency detected [ 103.849767] 5.15.0-rc1+ #470 Tainted: G C E [ 103.849773] ------------------------------------------------------ [ 103.849776] wpa_supplicant/695 is trying to acquire lock: [ 103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs] [ 103.849840] but task is already holding lock: [ 103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs] [ 103.849881] which lock already depends on the new lock. [ 103.849884] the existing dependency chain (in reverse order) is: [ 103.849887] -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}: [ 103.849898] _raw_spin_lock_bh+0x34/0x40 [ 103.849913] rtw_get_stainfo+0x93/0x110 [r8723bs] [ 103.849948] rtw_make_wlanhdr+0x14a/0x270 [r8723bs] [ 103.849983] rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs] [ 103.850019] rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs] [ 103.850050] kthread+0x143/0x160 [ 103.850058] ret_from_fork+0x22/0x30 [ 103.850067] -> #0 (&pxmitpriv->lock){+.-.}-{2:2}: [ 103.850077] __lock_acquire+0x1158/0x1de0 [ 103.850084] lock_acquire+0xb5/0x2b0 [ 103.850090] _raw_spin_lock_bh+0x34/0x40 [ 103.850095] rtw_free_stainfo+0x8a/0x510 [r8723bs] [ 103.850130] rtw_free_assoc_resources+0x53/0x110 [r8723bs] [ 103.850159] PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs] [ 103.850189] cfg80211_disconnect+0x173/0x320 [cfg80211] [ 103.850331] nl80211_disconnect+0x6e/0xb0 [cfg80211] [ 103.850422] genl_family_rcv_msg_doit+0xcd/0x110 [ 103.850430] genl_rcv_msg+0xce/0x1c0 [ 103.850435] netlink_rcv_skb+0x50/0xf0 [ 103.850441] genl_rcv+0x24/0x40 [ 103.850446] netlink_unicast+0x16d/0x230 [ 103.850452] netlink_sendmsg+0x22b/0x450 [ 103.850457] sock_sendmsg+0x5e/0x60 [ 103.850465] ____sys_sendmsg+0x22f/0x270 [ 103.850472] ___sys_sendmsg+0x81/0xc0 [ 103.850479] __sys_sendmsg+0x49/0x80 [ 103.850485] do_syscall_64+0x3b/0x90 [ 103.850493] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 103.850500] other info that might help us debug this: [ 103.850504] Possible unsafe locking scenario: [ 103.850507] CPU0 CPU1 [ 103.850510] ---- ---- [ 103.850512] lock(&pstapriv->sta_hash_lock); [ 103.850518] lock(&pxmitpriv->lock); [ 103.850524] lock(&pstapriv->sta_hash_lock); [ 103.850530] lock(&pxmitpriv->lock); [ 103.850535] *** DEADLOCK *** Push the taking of sta_hash_lock down into rtw_free_stainfo(), where the critical section is, this allows taking the lock after rtw_free_stainfo() has released pxmitpriv->lock. This requires changing rtw_free_all_stainfo() so that it does its freeing in 2 steps, first moving all stainfo-s to free to a local list while holding the sta_hash_lock and then walking that list to call rtw_free_stainfo() on them without holding the sta_hash_lock. Pushing the taking of sta_hash_lock down into rtw_free_stainfo(), also fixes a whole bunch of callers of rtw_free_stainfo() which were not holding that lock even though they should. Note that this also fixes the deadlock from the "remove possible deadlock when disconnect" patch in a different way. But the changes from that patch offer a nice locking cleanup regardless. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 353a6e9acb45a66f8fb80b07c2f4097cf4b826d1 Author: Fabio Aiuto Date: Mon Sep 20 16:55:00 2021 +0200 staging: rtl8723bs: remove possible deadlock when disconnect (v2) [ Upstream commit 54659ca026e586bbb33a7e60daa6443a3ac6b5df ] when turning off a connection, lockdep complains with the following warning (a modprobe has been done but the same happens with a disconnection from NetworkManager, it's enough to trigger a cfg80211_disconnect call): [ 682.855867] ====================================================== [ 682.855877] WARNING: possible circular locking dependency detected [ 682.855887] 5.14.0-rc6+ #16 Tainted: G C OE [ 682.855898] ------------------------------------------------------ [ 682.855906] modprobe/1770 is trying to acquire lock: [ 682.855916] ffffb6d000332b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x52/0x4a0 [r8723bs] [ 682.856073] but task is already holding lock: [ 682.856081] ffffb6d0003336a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs] [ 682.856207] which lock already depends on the new lock. [ 682.856215] the existing dependency chain (in reverse order) is: [ 682.856223] -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}: [ 682.856247] _raw_spin_lock_bh+0x34/0x40 [ 682.856265] rtw_get_stainfo+0x9a/0x110 [r8723bs] [ 682.856389] rtw_xmit_classifier+0x27/0x130 [r8723bs] [ 682.856515] rtw_xmitframe_enqueue+0xa/0x20 [r8723bs] [ 682.856642] rtl8723bs_hal_xmit+0x3b/0xb0 [r8723bs] [ 682.856752] rtw_xmit+0x4ef/0x890 [r8723bs] [ 682.856879] _rtw_xmit_entry+0xba/0x350 [r8723bs] [ 682.856981] dev_hard_start_xmit+0xee/0x320 [ 682.856999] sch_direct_xmit+0x8c/0x330 [ 682.857014] __dev_queue_xmit+0xba5/0xf00 [ 682.857030] packet_sendmsg+0x981/0x1b80 [ 682.857047] sock_sendmsg+0x5b/0x60 [ 682.857060] __sys_sendto+0xf1/0x160 [ 682.857073] __x64_sys_sendto+0x24/0x30 [ 682.857087] do_syscall_64+0x3a/0x80 [ 682.857102] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 682.857117] -> #0 (&pxmitpriv->lock){+.-.}-{2:2}: [ 682.857142] __lock_acquire+0xfd9/0x1b50 [ 682.857158] lock_acquire+0xb4/0x2c0 [ 682.857172] _raw_spin_lock_bh+0x34/0x40 [ 682.857185] rtw_free_stainfo+0x52/0x4a0 [r8723bs] [ 682.857308] rtw_free_assoc_resources+0x53/0x110 [r8723bs] [ 682.857415] cfg80211_rtw_disconnect+0x4b/0x70 [r8723bs] [ 682.857522] cfg80211_disconnect+0x12e/0x2f0 [cfg80211] [ 682.857759] cfg80211_leave+0x2b/0x40 [cfg80211] [ 682.857961] cfg80211_netdev_notifier_call+0xa9/0x560 [cfg80211] [ 682.858163] raw_notifier_call_chain+0x41/0x50 [ 682.858180] __dev_close_many+0x62/0x100 [ 682.858195] dev_close_many+0x7d/0x120 [ 682.858209] unregister_netdevice_many+0x416/0x680 [ 682.858225] unregister_netdevice_queue+0xab/0xf0 [ 682.858240] unregister_netdev+0x18/0x20 [ 682.858255] rtw_unregister_netdevs+0x28/0x40 [r8723bs] [ 682.858360] rtw_dev_remove+0x24/0xd0 [r8723bs] [ 682.858463] sdio_bus_remove+0x31/0xd0 [mmc_core] [ 682.858532] device_release_driver_internal+0xf7/0x1d0 [ 682.858550] driver_detach+0x47/0x90 [ 682.858564] bus_remove_driver+0x77/0xd0 [ 682.858579] rtw_drv_halt+0xc/0x678 [r8723bs] [ 682.858685] __x64_sys_delete_module+0x13f/0x250 [ 682.858699] do_syscall_64+0x3a/0x80 [ 682.858715] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 682.858729] other info that might help us debug this: [ 682.858737] Possible unsafe locking scenario: [ 682.858744] CPU0 CPU1 [ 682.858751] ---- ---- [ 682.858758] lock(&pstapriv->sta_hash_lock); [ 682.858772] lock(&pxmitpriv->lock); [ 682.858786] lock(&pstapriv->sta_hash_lock); [ 682.858799] lock(&pxmitpriv->lock); [ 682.858812] *** DEADLOCK *** [ 682.858820] 5 locks held by modprobe/1770: [ 682.858831] #0: ffff8d870697d980 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x1a/0x1d0 [ 682.858869] #1: ffffffffbdbbf1c8 (rtnl_mutex){+.+.}-{3:3}, at: unregister_netdev+0xe/0x20 [ 682.858906] #2: ffff8d87054ee5e8 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: cfg80211_netdev_notifier_call+0x9e/0x560 [cfg80211] [ 682.859131] #3: ffff8d870f2bc8f0 (&wdev->mtx){+.+.}-{3:3}, at: cfg80211_leave+0x20/0x40 [cfg80211] [ 682.859354] #4: ffffb6d0003336a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs] [ 682.859482] stack backtrace: [ 682.859491] CPU: 1 PID: 1770 Comm: modprobe Tainted: G C OE 5.14.0-rc6+ #16 [ 682.859507] Hardware name: LENOVO 80NR/Madrid, BIOS DACN25WW 08/20/2015 [ 682.859517] Call Trace: [ 682.859531] dump_stack_lvl+0x56/0x6f [ 682.859551] check_noncircular+0xdb/0xf0 [ 682.859579] __lock_acquire+0xfd9/0x1b50 [ 682.859606] lock_acquire+0xb4/0x2c0 [ 682.859623] ? rtw_free_stainfo+0x52/0x4a0 [r8723bs] [ 682.859752] ? mark_held_locks+0x48/0x70 [ 682.859769] ? rtw_free_stainfo+0x4a/0x4a0 [r8723bs] [ 682.859898] _raw_spin_lock_bh+0x34/0x40 [ 682.859914] ? rtw_free_stainfo+0x52/0x4a0 [r8723bs] [ 682.860039] rtw_free_stainfo+0x52/0x4a0 [r8723bs] [ 682.860171] rtw_free_assoc_resources+0x53/0x110 [r8723bs] [ 682.860286] cfg80211_rtw_disconnect+0x4b/0x70 [r8723bs] [ 682.860397] cfg80211_disconnect+0x12e/0x2f0 [cfg80211] [ 682.860629] cfg80211_leave+0x2b/0x40 [cfg80211] [ 682.860836] cfg80211_netdev_notifier_call+0xa9/0x560 [cfg80211] [ 682.861048] ? __lock_acquire+0x4dc/0x1b50 [ 682.861070] ? lock_is_held_type+0xa8/0x110 [ 682.861089] ? lock_is_held_type+0xa8/0x110 [ 682.861104] ? find_held_lock+0x2d/0x90 [ 682.861120] ? packet_notifier+0x173/0x300 [ 682.861141] ? lock_release+0xb3/0x250 [ 682.861160] ? packet_notifier+0x192/0x300 [ 682.861184] raw_notifier_call_chain+0x41/0x50 [ 682.861205] __dev_close_many+0x62/0x100 [ 682.861224] dev_close_many+0x7d/0x120 [ 682.861245] unregister_netdevice_many+0x416/0x680 [ 682.861264] ? find_held_lock+0x2d/0x90 [ 682.861284] unregister_netdevice_queue+0xab/0xf0 [ 682.861306] unregister_netdev+0x18/0x20 [ 682.861325] rtw_unregister_netdevs+0x28/0x40 [r8723bs] [ 682.861434] rtw_dev_remove+0x24/0xd0 [r8723bs] [ 682.861542] sdio_bus_remove+0x31/0xd0 [mmc_core] [ 682.861615] device_release_driver_internal+0xf7/0x1d0 [ 682.861637] driver_detach+0x47/0x90 [ 682.861656] bus_remove_driver+0x77/0xd0 [ 682.861674] rtw_drv_halt+0xc/0x678 [r8723bs] [ 682.861782] __x64_sys_delete_module+0x13f/0x250 [ 682.861801] ? lockdep_hardirqs_on_prepare+0xf3/0x170 [ 682.861817] ? syscall_enter_from_user_mode+0x20/0x70 [ 682.861836] do_syscall_64+0x3a/0x80 [ 682.861855] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 682.861873] RIP: 0033:0x7f6dbe85400b [ 682.861890] Code: 73 01 c3 48 8b 0d 6d 1e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 1e 0c 00 f7 d8 64 89 01 48 [ 682.861906] RSP: 002b:00007ffe7a82f538 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 682.861923] RAX: ffffffffffffffda RBX: 000055a64693bd20 RCX: 00007f6dbe85400b [ 682.861935] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055a64693bd88 [ 682.861946] RBP: 000055a64693bd20 R08: 0000000000000000 R09: 0000000000000000 [ 682.861957] R10: 00007f6dbe8c7ac0 R11: 0000000000000206 R12: 000055a64693bd88 [ 682.861967] R13: 0000000000000000 R14: 000055a64693bd88 R15: 00007ffe7a831848 This happens because when we enqueue a frame for transmission we do it under xmit_priv lock, then calling rtw_get_stainfo (needed for enqueuing) takes sta_hash_lock and this leads to the following lock dependency: xmit_priv->lock -> sta_hash_lock Turning off a connection will bring to call rtw_free_assoc_resources which will set up the inverse dependency: sta_hash_lock -> xmit_priv_lock This could lead to a deadlock as lockdep complains. Fix it by removing the xmit_priv->lock around rtw_xmitframe_enqueue call inside rtl8723bs_hal_xmit and put it in a smaller critical section inside rtw_xmit_classifier, the only place where xmit_priv data are actually accessed. Replace spin_{lock,unlock}_bh(pxmitpriv->lock) in other tx paths leading to rtw_xmitframe_enqueue call with spin_{lock,unlock}_bh(psta->sleep_q.lock) - it's not clear why accessing a sleep_q was protected by a spinlock on xmitpriv->lock. This way is avoided the same faulty lock nesting order. Extra changes in v2 by Hans de Goede: -Lift the taking of the struct __queue.lock spinlock out of rtw_free_xmitframe_queue() into the callers this allows also protecting a bunch of related state in rtw_free_stainfo(): -Protect psta->sleepq_len on rtw_free_xmitframe_queue(&psta->sleep_q); -Protect struct tx_servq.tx_pending and tx_servq.qcnt when calling rtw_free_xmitframe_queue(&tx_servq.sta_pending) -This also allows moving the spin_lock_bh(&pxmitpriv->lock); to below the sleep_q free-ing code, avoiding another ABBA locking issue CC: Larry Finger Co-developed-by: Hans de Goede Tested-on: Lenovo Ideapad MiiX 300-10IBY Signed-off-by: Fabio Aiuto Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210920145502.155454-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f78e23be336ec7bb5d7009587d08edd42e7ff047 Author: Linus Walleij Date: Fri Jun 4 00:00:04 2021 +0200 ARM: dts: ux500: Skomer regulator fixes [ Upstream commit 7aee0288beab72cdfa35af51f62e94373fca595d ] AUX2 has slightly wrong voltage and AUX5 doesn't need to be always on. Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2c71811c963b6c310a29455d521d31a7ea6c5b5e Author: Sven Peter Date: Tue Sep 14 16:02:35 2021 +0200 usb: typec: tipd: Remove WARN_ON in tps6598x_block_read [ Upstream commit b7a0a63f3fed57d413bb857de164ea9c3984bc4e ] Calling tps6598x_block_read with a higher than allowed len can be handled by just returning an error. There's no need to crash systems with panic-on-warn enabled. Reviewed-by: Heikki Krogerus Signed-off-by: Sven Peter Link: https://lore.kernel.org/r/20210914140235.65955-3-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 06cfb4cb2241e704d72e3045cf4d7dfb567fbce0 Author: Yang Yingliang Date: Wed Sep 15 11:49:25 2021 +0800 usb: musb: tusb6010: check return value after calling platform_get_resource() [ Upstream commit 14651496a3de6807a17c310f63c894ea0c5d858e ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210915034925.2399823-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9dd4b84d55216d004e14b56e90a49d5a60fb0b0a Author: Tony Lindgren Date: Tue Sep 21 12:42:25 2021 +0300 bus: ti-sysc: Use context lost quirk for otg [ Upstream commit 9067839ff45a528bcb015cc2f24f656126b91e3f ] Let's use SYSC_QUIRK_REINIT_ON_CTX_LOST quirk for am335x otg instead of SYSC_QUIRK_REINIT_ON_RESUME quirk as we can now handle the context loss in a more generic way. Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit c182fa00fcdd3f191d65b0d7fbe2b0a382e0f412 Author: Tony Lindgren Date: Tue Sep 21 12:42:25 2021 +0300 bus: ti-sysc: Add quirk handling for reinit on context lost [ Upstream commit 9d881361206ebcf6285c2ec2ef275aff80875347 ] Some interconnect target modules such as otg and gpmc on am335x need a re-init after resume. As we also have PM runtime cases where the context may be lost, let's handle these all with cpu_pm. For the am335x resume path, we already have cpu_pm_resume() call cpu_pm_cluster_exit(). Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 1e299b02bae806800c9559a71c559b26b28aed92 Author: Selvin Xavier Date: Wed Sep 15 05:32:42 2021 -0700 RDMA/bnxt_re: Check if the vlan is valid before reporting [ Upstream commit 6bda39149d4b8920fdb8744090653aca3daa792d ] When VF is configured with default vlan, HW strips the vlan from the packet and driver receives it in Rx completion. VLAN needs to be reported for UD work completion only if the vlan is configured on the host. Add a check for valid vlan in the UD receive path. Link: https://lore.kernel.org/r/1631709163-2287-12-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit bed5a80fc851aaa130dbcb3aee01ce31c3737e26 Author: Michael Walle Date: Mon Aug 30 18:51:13 2021 +0200 arm64: dts: hisilicon: fix arm,sp805 compatible string [ Upstream commit 894d4f1f77d0e88f1f81af2e1e37333c1c41b631 ] According to Documentation/devicetree/bindings/watchdog/arm,sp805.yaml the compatible is: compatible = "arm,sp805", "arm,primecell"; The current compatible string doesn't exist at all. Fix it. Signed-off-by: Michael Walle Signed-off-by: Wei Xu Signed-off-by: Sasha Levin commit 376bad67058561eaa612140337c6836c889ccd4e Author: Matthias Brugger Date: Thu Jul 15 18:41:01 2021 +0200 arm64: dts: rockchip: Disable CDN DP on Pinebook Pro [ Upstream commit 2513fa5c25d42f55ca5f0f0ab247af7c9fbfa3b1 ] The CDN DP needs a PHY and a extcon to work correctly. But no extcon is provided by the device-tree, which leads to an error: cdn-dp fec00000.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR* missing extcon or phy cdn-dp: probe of fec00000.dp failed with error -22 Disable the CDN DP to make graphic work on the Pinebook Pro. Reported-by: Guillaume Gardet Signed-off-by: Matthias Brugger Link: https://lore.kernel.org/r/20210715164101.11486-1-matthias.bgg@kernel.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 867cfea6ae5589a553712f4d7b34427e343c5fbb Author: Bixuan Cui Date: Sat Sep 11 16:12:46 2021 +0800 ASoC: mediatek: mt8195: Add missing of_node_put() [ Upstream commit b2fc2c92d2fd34d93268f677e514936f50dd6b5c ] The platform_node is returned by of_parse_phandle() should have of_node_put() before return. Reported-by: Hulk Robot Signed-off-by: Bixuan Cui Link: https://lore.kernel.org/r/20210911081246.33867-1-cuibixuan@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 814d3610c4ce86e8cf285b2cdac0057a42e82de5 Author: James Smart Date: Fri Sep 10 16:31:46 2021 -0700 scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq() [ Upstream commit 99154581b05c8fb22607afb7c3d66c1bace6aa5d ] When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local "fail_msg" string is set and a log message output. The job is then added to a completions list for cancellation. Processing of any further jobs from the txq list continues, but since "fail_msg" remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption. Fix by clearing the fail_msg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure. Link: https://lore.kernel.org/r/20210910233159.115896-2-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 269a4311b15f68d24e816f43f123888f241ed13d Author: Ajish Koshy Date: Mon Sep 6 22:34:04 2021 +0530 scsi: pm80xx: Fix memory leak during rmmod [ Upstream commit 51e6ed83bb4ade7c360551fa4ae55c4eacea354b ] Driver failed to release all memory allocated. This would lead to memory leak during driver removal. Properly free memory when the module is removed. Link: https://lore.kernel.org/r/20210906170404.5682-5-Ajish.Koshy@microchip.com Acked-by: Jack Wang Signed-off-by: Ajish Koshy Signed-off-by: Viswas G Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a070e30d1b7ba40b240b38fe820c7a095596d59f Author: Rafał Miłecki Date: Thu Aug 19 14:26:06 2021 +0200 arm64: dts: broadcom: bcm4908: Move reboot syscon out of bus [ Upstream commit 6cf9f70255b90b540b9cbde062f18fea29024a75 ] This fixes following error for every bcm4908 DTS file: bus@ff800000: reboot: {'type': 'object'} is not allowed for {'compatible': ['syscon-reboot'], 'regmap': [[15]], 'offset': [[52]], 'mask': [[1]]} Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 8e4b6c2f027e36d5ff7ebf15f49be6f0c423d2c9 Author: Matthew Hagan Date: Sun Aug 29 22:37:48 2021 +0000 ARM: dts: NSP: Fix mpcore, mmc node names [ Upstream commit 15a563d008ef9d04df525f0c476cd7d7127bb883 ] Running dtbs_check yielded the issues with bcm-nsp.dtsi. Firstly this patch fixes the following message by appending "-bus" to the mpcore node name: mpcore@19000000: $nodename:0: 'mpcore@19000000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' Secondly mmc node name. The label name can remain as is. sdhci@21000: $nodename:0: 'sdhci@21000' does not match '^mmc(@.*)?$' Signed-off-by: Matthew Hagan Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 8033b37f969ab8fbde4c70cead6162daf873df30 Author: Rafał Miłecki Date: Thu Aug 19 08:57:01 2021 +0200 ARM: dts: BCM5301X: Fix MDIO mux binding [ Upstream commit 6ee0b56f7530e0ebb496fe15d0b54c5f3a1b5e17 ] This fixes following error for all BCM5301X dts files: mdio-bus-mux@18003000: compatible: ['mdio-mux-mmioreg'] is too short Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 50b631c5a38e92d064660aaa759f93563928f0cd Author: Rafał Miłecki Date: Thu Aug 19 08:57:00 2021 +0200 ARM: dts: BCM5301X: Fix nodes names [ Upstream commit 9dba049b6d32e95c0dd2a0d607f593ea288ac140 ] This fixes following errors for all BCM5301X dts files: chipcommonA@18000000: $nodename:0: 'chipcommonA@18000000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' mpcore@19000000: $nodename:0: 'mpcore@19000000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' mdio-bus-mux@18003000: $nodename:0: 'mdio-bus-mux@18003000' does not match '^mdio-mux[\\-@]?' dmu@1800c000: $nodename:0: 'dmu@1800c000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit f7d67885beb3d0e3446eda631eb0390c81121b67 Author: Jérôme Pouiller Date: Mon Sep 13 15:02:03 2021 +0200 staging: wfx: ensure IRQ is ready before enabling it [ Upstream commit 5e57c668dc097c6c27c973504706edec53f79281 ] Since commit 5561770f80b1 ("staging: wfx: repair external IRQ for SDIO"), wfx_sdio_irq_subscribe() enforce the device to use IRQs. However, there is currently a race in this code. An IRQ may happen before the IRQ has been registered. The problem has observed during debug session when the device crashes before the IRQ set up: [ 1.546] wfx-sdio mmc0:0001:1: started firmware 3.12.2 "WF200_ASIC_WFM_(Jenkins)_FW3.12.2" (API: 3.7, keyset: C0, caps: 0x00000002) [ 2.559] wfx-sdio mmc0:0001:1: time out while polling control register [ 3.565] wfx-sdio mmc0:0001:1: chip is abnormally long to answer [ 6.563] wfx-sdio mmc0:0001:1: chip did not answer [ 6.568] wfx-sdio mmc0:0001:1: hardware request CONFIGURATION (0x09) on vif 2 returned error -110 [ 6.577] wfx-sdio mmc0:0001:1: PDS bytes 0 to 12: chip didn't reply (corrupted file?) [ 6.585] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 6.592] pgd = c0004000 [ 6.595] [00000000] *pgd=00000000 [ 6.598] Internal error: Oops - BUG: 17 [#1] THUMB2 [ 6.603] Modules linked in: [ 6.606] CPU: 0 PID: 23 Comm: kworker/u2:1 Not tainted 3.18.19 #78 [ 6.612] Workqueue: kmmcd mmc_rescan [ 6.616] task: c176d100 ti: c0e50000 task.ti: c0e50000 [ 6.621] PC is at wake_up_process+0xa/0x14 [ 6.625] LR is at sdio_irq+0x61/0x250 [ 6.629] pc : [] lr : [] psr: 600001b3 [ 6.629] sp : c0e51bd8 ip : c0e51cc8 fp : 00000001 [ 6.640] r10: 00000003 r9 : 00000000 r8 : c0003c34 [ 6.644] r7 : c0e51bd8 r6 : c0003c30 r5 : 00000001 r4 : c0e78c00 [ 6.651] r3 : 00000000 r2 : 00000000 r1 : 00000003 r0 : 00000000 [ 6.657] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA Thumb Segment kernel [ 6.664] Control: 50c53c7d Table: 11fd8059 DAC: 00000015 [ 6.670] Process kworker/u2:1 (pid: 23, stack limit = 0xc0e501b0) [ 6.676] Stack: (0xc0e51bd8 to 0xc0e52000) [...] [ 6.949] [] (wake_up_process) from [] (sdio_irq+0x61/0x250) [ 6.956] [] (sdio_irq) from [] (handle_irq_event_percpu+0x17/0x92) [ 6.964] [] (handle_irq_event_percpu) from [] (handle_irq_event+0x1b/0x24) [ 6.973] [] (handle_irq_event) from [] (handle_level_irq+0x5d/0x76) [ 6.981] [] (handle_level_irq) from [] (generic_handle_irq+0x13/0x1c) [ 6.989] [] (generic_handle_irq) from [] (__handle_domain_irq+0x31/0x48) [ 6.997] [] (__handle_domain_irq) from [] (ov_handle_irq+0x31/0xe0) [ 7.005] [] (ov_handle_irq) from [] (__irq_svc+0x3b/0x5c) [ 7.013] Exception stack(0xc0e51c68 to 0xc0e51cb0) [...] [ 7.038] [] (__irq_svc) from [] (wait_for_common+0x9e/0xc4) [ 7.045] [] (wait_for_common) from [] (mmc_wait_for_req+0x4b/0xdc) [ 7.053] [] (mmc_wait_for_req) from [] (mmc_wait_for_cmd+0x2f/0x34) [ 7.061] [] (mmc_wait_for_cmd) from [] (mmc_io_rw_direct_host+0x71/0xac) [ 7.070] [] (mmc_io_rw_direct_host) from [] (sdio_claim_irq+0x6b/0x116) [ 7.078] [] (sdio_claim_irq) from [] (wfx_sdio_irq_subscribe+0x19/0x94) [ 7.086] [] (wfx_sdio_irq_subscribe) from [] (wfx_probe+0x189/0x2ac) [ 7.095] [] (wfx_probe) from [] (wfx_sdio_probe+0x8f/0xcc) [ 7.102] [] (wfx_sdio_probe) from [] (sdio_bus_probe+0x5f/0xa8) [ 7.109] [] (sdio_bus_probe) from [] (driver_probe_device+0x59/0x134) [ 7.118] [] (driver_probe_device) from [] (bus_for_each_drv+0x3f/0x4a) [ 7.126] [] (bus_for_each_drv) from [] (device_attach+0x3b/0x52) [ 7.134] [] (device_attach) from [] (bus_probe_device+0x17/0x4c) [ 7.141] [] (bus_probe_device) from [] (device_add+0x2c5/0x334) [ 7.149] [] (device_add) from [] (sdio_add_func+0x23/0x44) [ 7.156] [] (sdio_add_func) from [] (mmc_attach_sdio+0x187/0x1ec) [ 7.164] [] (mmc_attach_sdio) from [] (mmc_rescan+0x18d/0x1fc) [ 7.172] [] (mmc_rescan) from [] (process_one_work+0xd7/0x170) [ 7.179] [] (process_one_work) from [] (worker_thread+0x103/0x1bc) [ 7.187] [] (worker_thread) from [] (kthread+0x7d/0x90) [ 7.194] [] (kthread) from [] (ret_from_fork+0x11/0x30) [ 7.201] Code: 2103 b580 2200 af00 (681b) 46bd [ 7.206] ---[ end trace 3ab50aced42eedb4 ]--- Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20210913130203.1903622-33-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f08c0d6a673cd05669d7d5e6086f46ecce5a9afb Author: Maxime Ripard Date: Wed Sep 1 11:18:49 2021 +0200 arm64: dts: allwinner: a100: Fix thermal zone node name [ Upstream commit 5c34c4e46e601554bfa370b23c8ae3c3c734e9f7 ] The thermal zones one the A100 are called $device-thermal-zone. However, the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it. Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://lore.kernel.org/r/20210901091852.479202-50-maxime@cerno.tech Signed-off-by: Sasha Levin commit f2b9e78b3e14b12749724039ec3f7c0a95bfa72f Author: Maxime Ripard Date: Wed Sep 1 11:18:47 2021 +0200 arm64: dts: allwinner: h5: Fix GPU thermal zone node name [ Upstream commit 94a0f2b0e4e0953d8adf319c44244ef7a57de32c ] The GPU thermal zone is named gpu_thermal. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it. Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://lore.kernel.org/r/20210901091852.479202-48-maxime@cerno.tech Signed-off-by: Sasha Levin commit ea4f91645d5b9d22c90ffc2b276f91595d918ebf Author: Maxime Ripard Date: Wed Sep 1 11:18:42 2021 +0200 ARM: dts: sunxi: Fix OPPs node name [ Upstream commit ffbe853a3f5a37fa0a511265b21abf097ffdbe45 ] The operating-points-v2 nodes are named inconsistently, but mostly either opp_table0 or gpu-opp-table. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called opp-table-*. Let's fix it. Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://lore.kernel.org/r/20210901091852.479202-43-maxime@cerno.tech Signed-off-by: Sasha Levin commit b5dd513daa70ee8f6d281a20bd28485ee9bb7db2 Author: Samuel Holland Date: Wed Sep 1 00:05:19 2021 -0500 clk: sunxi-ng: Unregister clocks/resets when unbinding [ Upstream commit 9bec2b9c6134052994115d2d3374e96f2ccb9b9d ] Currently, unbinding a CCU driver unmaps the device's MMIO region, while leaving its clocks/resets and their providers registered. This can cause a page fault later when some clock operation tries to perform MMIO. Fix this by separating the CCU initialization from the memory allocation, and then using a devres callback to unregister the clocks and resets. This also fixes a memory leak of the `struct ccu_reset`, and uses the correct owner (the specific platform driver) for the clocks and resets. Early OF clock providers are never unregistered, and limited error handling is possible, so they are mostly unchanged. The error reporting is made more consistent by moving the message inside of_sunxi_ccu_probe. Signed-off-by: Samuel Holland Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210901050526.45673-2-samuel@sholland.org Signed-off-by: Sasha Levin commit 5d729f4b5b56975781e279d3039ff28882789c99 Author: Michal Simek Date: Fri Aug 6 10:58:29 2021 +0200 arm64: zynqmp: Fix serial compatible string [ Upstream commit 812fa2f0e9d33564bd0131a69750e0d165f4c82a ] Based on commit 65a2c14d4f00 ("dt-bindings: serial: convert Cadence UART bindings to YAML") compatible string should look like differently that's why fix it to be aligned with dt binding. Signed-off-by: Michal Simek Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/89b36e0a6187cc6b05b27a035efdf79173bd4486.1628240307.git.michal.simek@xilinx.com Signed-off-by: Sasha Levin commit 69d0f6a7c8cff9a3bbbb7287f620399c97d197df Author: Amit Kumar Mahapatra Date: Mon Jun 14 17:25:10 2021 +0200 arm64: zynqmp: Do not duplicate flash partition label property [ Upstream commit 167721a5909f867f8c18c8e78ea58e705ad9bbd4 ] In kernel 5.4, support has been added for reading MTD devices via the nvmem API. For this the mtd devices are registered as read-only NVMEM providers under sysfs with the same name as the flash partition label property. So if flash partition label property of multiple flash devices are identical then the second mtd device fails to get registered as a NVMEM provider. This patch fixes the issue by having different label property for different flashes. Signed-off-by: Amit Kumar Mahapatra Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/6c4b9b9232b93d9e316a63c086540fd5bf6b8687.1623684253.git.michal.simek@xilinx.com Signed-off-by: Sasha Levin