--- /dev/null
+From d4955c0ad77dbc684fc716387070ac24801b8bca Mon Sep 17 00:00:00 2001
+From: Sergey Shtylyov <s.shtylyov@omp.ru>
+Date: Fri, 16 Sep 2022 23:17:07 +0300
+Subject: arm64: topology: fix possible overflow in amu_fie_setup()
+
+From: Sergey Shtylyov <s.shtylyov@omp.ru>
+
+commit d4955c0ad77dbc684fc716387070ac24801b8bca upstream.
+
+cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*,
+while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'.
+Multiplying max frequency by 1000 can potentially result in overflow --
+multiplying by 1000ULL instead should avoid that...
+
+Found by Linux Verification Center (linuxtesting.org) with the SVACE static
+analysis tool.
+
+Fixes: cd0ed03a8903 ("arm64: use activity monitors for frequency invariance")
+Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
+Link: https://lore.kernel.org/r/01493d64-2bce-d968-86dc-11a122a9c07d@omp.ru
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kernel/topology.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/kernel/topology.c
++++ b/arch/arm64/kernel/topology.c
+@@ -249,7 +249,7 @@ static void amu_fie_setup(const struct c
+ for_each_cpu(cpu, cpus) {
+ if (!freq_counters_valid(cpu) ||
+ freq_inv_set_max_ratio(cpu,
+- cpufreq_get_hw_max_freq(cpu) * 1000,
++ cpufreq_get_hw_max_freq(cpu) * 1000ULL,
+ arch_timer_get_rate()))
+ return;
+ }
--- /dev/null
+From a09721dd47c8468b3f2fdd73f40422699ffe26dd Mon Sep 17 00:00:00 2001
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+Date: Thu, 11 Aug 2022 10:25:44 +0200
+Subject: can: flexcan: flexcan_mailbox_read() fix return value for drop = true
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+
+commit a09721dd47c8468b3f2fdd73f40422699ffe26dd upstream.
+
+The following happened on an i.MX25 using flexcan with many packets on
+the bus:
+
+The rx-offload queue reached a length more than skb_queue_len_max. In
+can_rx_offload_offload_one() the drop variable was set to true which
+made the call to .mailbox_read() (here: flexcan_mailbox_read()) to
+_always_ return ERR_PTR(-ENOBUFS) and drop the rx'ed CAN frame. So
+can_rx_offload_offload_one() returned ERR_PTR(-ENOBUFS), too.
+
+can_rx_offload_irq_offload_fifo() looks as follows:
+
+| while (1) {
+| skb = can_rx_offload_offload_one(offload, 0);
+| if (IS_ERR(skb))
+| continue;
+| if (!skb)
+| break;
+| ...
+| }
+
+The flexcan driver wrongly always returns ERR_PTR(-ENOBUFS) if drop is
+requested, even if there is no CAN frame pending. As the i.MX25 is a
+single core CPU, while the rx-offload processing is active, there is
+no thread to process packets from the offload queue. So the queue
+doesn't get any shorter and this results is a tight loop.
+
+Instead of always returning ERR_PTR(-ENOBUFS) if drop is requested,
+return NULL if no CAN frame is pending.
+
+Changes since v1: https://lore.kernel.org/all/20220810144536.389237-1-u.kleine-koenig@pengutronix.de
+- don't break in can_rx_offload_irq_offload_fifo() in case of an error,
+ return NULL in flexcan_mailbox_read() in case of no pending CAN frame
+ instead
+
+Fixes: 4e9c9484b085 ("can: rx-offload: Prepare for CAN FD support")
+Link: https://lore.kernel.org/all/20220811094254.1864367-1-mkl@pengutronix.de
+Cc: stable@vger.kernel.org # v5.5
+Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Tested-by: Thorsten Scherer <t.scherer@eckelmann.de>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/flexcan.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/can/flexcan.c
++++ b/drivers/net/can/flexcan.c
+@@ -1036,11 +1036,6 @@ static struct sk_buff *flexcan_mailbox_r
+ u32 reg_ctrl, reg_id, reg_iflag1;
+ int i;
+
+- if (unlikely(drop)) {
+- skb = ERR_PTR(-ENOBUFS);
+- goto mark_as_read;
+- }
+-
+ mb = flexcan_get_mb(priv, n);
+
+ if (priv->devtype_data.quirks & FLEXCAN_QUIRK_USE_RX_MAILBOX) {
+@@ -1069,6 +1064,11 @@ static struct sk_buff *flexcan_mailbox_r
+ reg_ctrl = priv->read(&mb->can_ctrl);
+ }
+
++ if (unlikely(drop)) {
++ skb = ERR_PTR(-ENOBUFS);
++ goto mark_as_read;
++ }
++
+ if (reg_ctrl & FLEXCAN_MB_CNT_EDL)
+ skb = alloc_canfd_skb(offload->dev, &cfd);
+ else
--- /dev/null
+From b7df41a6f79dfb18ba2203f8c5f0e9c0b9b57f68 Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski <brgl@bgdev.pl>
+Date: Tue, 20 Sep 2022 09:18:41 +0200
+Subject: gpio: mockup: fix NULL pointer dereference when removing debugfs
+
+From: Bartosz Golaszewski <brgl@bgdev.pl>
+
+commit b7df41a6f79dfb18ba2203f8c5f0e9c0b9b57f68 upstream.
+
+We now remove the device's debugfs entries when unbinding the driver.
+This now causes a NULL-pointer dereference on module exit because the
+platform devices are unregistered *after* the global debugfs directory
+has been recursively removed. Fix it by unregistering the devices first.
+
+Fixes: 303e6da99429 ("gpio: mockup: remove gpio debugfs when remove device")
+Cc: Wei Yongjun <weiyongjun1@huawei.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpio-mockup.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpio/gpio-mockup.c
++++ b/drivers/gpio/gpio-mockup.c
+@@ -618,9 +618,9 @@ static int __init gpio_mockup_init(void)
+
+ static void __exit gpio_mockup_exit(void)
+ {
++ gpio_mockup_unregister_pdevs();
+ debugfs_remove_recursive(gpio_mockup_dbg_dir);
+ platform_driver_unregister(&gpio_mockup_driver);
+- gpio_mockup_unregister_pdevs();
+ }
+
+ module_init(gpio_mockup_init);
--- /dev/null
+From 02743c4091ccfb246f5cdbbe3f44b152d5d12933 Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Tue, 20 Sep 2022 16:30:31 +0300
+Subject: gpio: mockup: Fix potential resource leakage when register a chip
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit 02743c4091ccfb246f5cdbbe3f44b152d5d12933 upstream.
+
+If creation of software node fails, the locally allocated string
+array is left unfreed. Free it on error path.
+
+Fixes: 6fda593f3082 ("gpio: mockup: Convert to use software nodes")
+Cc: stable@vger.kernel.org
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpio-mockup.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpio/gpio-mockup.c
++++ b/drivers/gpio/gpio-mockup.c
+@@ -554,8 +554,10 @@ static int __init gpio_mockup_register_c
+ }
+
+ fwnode = fwnode_create_software_node(properties, NULL);
+- if (IS_ERR(fwnode))
++ if (IS_ERR(fwnode)) {
++ kfree_strarray(line_names, ngpio);
+ return PTR_ERR(fwnode);
++ }
+
+ pdevinfo.name = "gpio-mockup";
+ pdevinfo.id = idx;
--- /dev/null
+From 69bef19d6b9700e96285f4b4e28691cda3dcd0d1 Mon Sep 17 00:00:00 2001
+From: Meng Li <Meng.Li@windriver.com>
+Date: Wed, 21 Sep 2022 11:20:20 +0800
+Subject: gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully
+
+From: Meng Li <Meng.Li@windriver.com>
+
+commit 69bef19d6b9700e96285f4b4e28691cda3dcd0d1 upstream.
+
+When running gpio test on nxp-ls1028 platform with below command
+gpiomon --num-events=3 --rising-edge gpiochip1 25
+There will be a warning trace as below:
+Call trace:
+free_irq+0x204/0x360
+lineevent_free+0x64/0x70
+gpio_ioctl+0x598/0x6a0
+__arm64_sys_ioctl+0xb4/0x100
+invoke_syscall+0x5c/0x130
+......
+el0t_64_sync+0x1a0/0x1a4
+The reason of this issue is that calling request_threaded_irq()
+function failed, and then lineevent_free() is invoked to release
+the resource. Since the lineevent_state::irq was already set, so
+the subsequent invocation of free_irq() would trigger the above
+warning call trace. To fix this issue, set the lineevent_state::irq
+after the IRQ register successfully.
+
+Fixes: 468242724143 ("gpiolib: cdev: refactor lineevent cleanup into lineevent_free")
+Cc: stable@vger.kernel.org
+Signed-off-by: Meng Li <Meng.Li@windriver.com>
+Reviewed-by: Kent Gibson <warthog618@gmail.com>
+Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpiolib-cdev.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpio/gpiolib-cdev.c
++++ b/drivers/gpio/gpiolib-cdev.c
+@@ -1784,7 +1784,6 @@ static int lineevent_create(struct gpio_
+ ret = -ENODEV;
+ goto out_free_le;
+ }
+- le->irq = irq;
+
+ if (eflags & GPIOEVENT_REQUEST_RISING_EDGE)
+ irqflags |= test_bit(FLAG_ACTIVE_LOW, &desc->flags) ?
+@@ -1798,7 +1797,7 @@ static int lineevent_create(struct gpio_
+ init_waitqueue_head(&le->wait);
+
+ /* Request a thread to read the events */
+- ret = request_threaded_irq(le->irq,
++ ret = request_threaded_irq(irq,
+ lineevent_irq_handler,
+ lineevent_irq_thread,
+ irqflags,
+@@ -1807,6 +1806,8 @@ static int lineevent_create(struct gpio_
+ if (ret)
+ goto out_free_le;
+
++ le->irq = irq;
++
+ fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC);
+ if (fd < 0) {
+ ret = fd;
--- /dev/null
+From 5373b8a09d6e037ee0587cb5d9fe4cc09077deeb Mon Sep 17 00:00:00 2001
+From: Peter Collingbourne <pcc@google.com>
+Date: Tue, 13 Sep 2022 19:00:01 -0700
+Subject: kasan: call kasan_malloc() from __kmalloc_*track_caller()
+
+From: Peter Collingbourne <pcc@google.com>
+
+commit 5373b8a09d6e037ee0587cb5d9fe4cc09077deeb upstream.
+
+We were failing to call kasan_malloc() from __kmalloc_*track_caller()
+which was causing us to sometimes fail to produce KASAN error reports
+for allocations made using e.g. devm_kcalloc(), as the KASAN poison was
+not being initialized. Fix it.
+
+Signed-off-by: Peter Collingbourne <pcc@google.com>
+Cc: <stable@vger.kernel.org> # 5.15
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/slub.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/mm/slub.c
++++ b/mm/slub.c
+@@ -4920,6 +4920,8 @@ void *__kmalloc_track_caller(size_t size
+ /* Honor the call site pointer we received. */
+ trace_kmalloc(caller, ret, size, s->size, gfpflags);
+
++ ret = kasan_kmalloc(s, ret, size, gfpflags);
++
+ return ret;
+ }
+ EXPORT_SYMBOL(__kmalloc_track_caller);
+@@ -4951,6 +4953,8 @@ void *__kmalloc_node_track_caller(size_t
+ /* Honor the call site pointer we received. */
+ trace_kmalloc_node(caller, ret, size, s->size, gfpflags, node);
+
++ ret = kasan_kmalloc(s, ret, size, gfpflags);
++
+ return ret;
+ }
+ EXPORT_SYMBOL(__kmalloc_node_track_caller);
--- /dev/null
+From 50b2d49bafa16e6311ab2da82f5aafc5f9ada99b Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Wed, 24 Aug 2022 03:30:57 +0000
+Subject: KVM: x86: Inject #UD on emulated XSETBV if XSAVES isn't enabled
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 50b2d49bafa16e6311ab2da82f5aafc5f9ada99b upstream.
+
+Inject #UD when emulating XSETBV if CR4.OSXSAVE is not set. This also
+covers the "XSAVE not supported" check, as setting CR4.OSXSAVE=1 #GPs if
+XSAVE is not supported (and userspace gets to keep the pieces if it
+forces incoherent vCPU state).
+
+Add a comment to kvm_emulate_xsetbv() to call out that the CPU checks
+CR4.OSXSAVE before checking for intercepts. AMD'S APM implies that #UD
+has priority (says that intercepts are checked before #GP exceptions),
+while Intel's SDM says nothing about interception priority. However,
+testing on hardware shows that both AMD and Intel CPUs prioritize the #UD
+over interception.
+
+Fixes: 02d4160fbd76 ("x86: KVM: add xsetbv to the emulator")
+Cc: stable@vger.kernel.org
+Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20220824033057.3576315-4-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/emulate.c | 3 +++
+ arch/x86/kvm/x86.c | 1 +
+ 2 files changed, 4 insertions(+)
+
+--- a/arch/x86/kvm/emulate.c
++++ b/arch/x86/kvm/emulate.c
+@@ -4122,6 +4122,9 @@ static int em_xsetbv(struct x86_emulate_
+ {
+ u32 eax, ecx, edx;
+
++ if (!(ctxt->ops->get_cr(ctxt, 4) & X86_CR4_OSXSAVE))
++ return emulate_ud(ctxt);
++
+ eax = reg_read(ctxt, VCPU_REGS_RAX);
+ edx = reg_read(ctxt, VCPU_REGS_RDX);
+ ecx = reg_read(ctxt, VCPU_REGS_RCX);
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -1021,6 +1021,7 @@ static int __kvm_set_xcr(struct kvm_vcpu
+
+ int kvm_emulate_xsetbv(struct kvm_vcpu *vcpu)
+ {
++ /* Note, #UD due to CR4.OSXSAVE=0 has priority over the intercept. */
+ if (static_call(kvm_x86_get_cpl)(vcpu) != 0 ||
+ __kvm_set_xcr(vcpu, kvm_rcx_read(vcpu), kvm_read_edx_eax(vcpu))) {
+ kvm_inject_gp(vcpu, 0);
--- /dev/null
+From e45cc288724f0cfd497bb5920bcfa60caa335729 Mon Sep 17 00:00:00 2001
+From: Maurizio Lombardi <mlombard@redhat.com>
+Date: Mon, 19 Sep 2022 18:39:29 +0200
+Subject: mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.
+
+From: Maurizio Lombardi <mlombard@redhat.com>
+
+commit e45cc288724f0cfd497bb5920bcfa60caa335729 upstream.
+
+Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations
+__free_slab() invocations out of IRQ context") moved all flush_cpu_slab()
+invocations to the global workqueue to avoid a problem related
+with deactivate_slab()/__free_slab() being called from an IRQ context
+on PREEMPT_RT kernels.
+
+When the flush_all_cpu_locked() function is called from a task context
+it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up
+flushing the global workqueue, this will cause a dependency issue.
+
+ workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core]
+ is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab
+ WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637
+ check_flush_dependency+0x10a/0x120
+ Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core]
+ RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace:
+ __flush_work.isra.0+0xbf/0x220
+ ? __queue_work+0x1dc/0x420
+ flush_all_cpus_locked+0xfb/0x120
+ __kmem_cache_shutdown+0x2b/0x320
+ kmem_cache_destroy+0x49/0x100
+ bioset_exit+0x143/0x190
+ blk_release_queue+0xb9/0x100
+ kobject_cleanup+0x37/0x130
+ nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc]
+ nvme_free_ctrl+0x1ac/0x2b0 [nvme_core]
+
+Fix this bug by creating a workqueue for the flush operation with
+the WQ_MEM_RECLAIM bit set.
+
+Fixes: 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
+Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/slub.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/mm/slub.c
++++ b/mm/slub.c
+@@ -308,6 +308,11 @@ static inline void stat(const struct kme
+ */
+ static nodemask_t slab_nodes;
+
++/*
++ * Workqueue used for flush_cpu_slab().
++ */
++static struct workqueue_struct *flushwq;
++
+ /********************************************************************
+ * Core slab cache functions
+ *******************************************************************/
+@@ -2688,7 +2693,7 @@ static void flush_all_cpus_locked(struct
+ INIT_WORK(&sfw->work, flush_cpu_slab);
+ sfw->skip = false;
+ sfw->s = s;
+- schedule_work_on(cpu, &sfw->work);
++ queue_work_on(cpu, flushwq, &sfw->work);
+ }
+
+ for_each_online_cpu(cpu) {
+@@ -4850,6 +4855,8 @@ void __init kmem_cache_init(void)
+
+ void __init kmem_cache_init_late(void)
+ {
++ flushwq = alloc_workqueue("slub_flushwq", WQ_MEM_RECLAIM, 0);
++ WARN_ON(!flushwq);
+ }
+
+ struct kmem_cache *
--- /dev/null
+From 7e9c323c52b379d261a72dc7bd38120a761a93cd Mon Sep 17 00:00:00 2001
+From: Chao Yu <chao.yu@oppo.com>
+Date: Wed, 31 Aug 2022 22:54:54 +0800
+Subject: mm/slub: fix to return errno if kmalloc() fails
+
+From: Chao Yu <chao.yu@oppo.com>
+
+commit 7e9c323c52b379d261a72dc7bd38120a761a93cd upstream.
+
+In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to
+out-of-memory, if it fails, return errno correctly rather than
+triggering panic via BUG_ON();
+
+kernel BUG at mm/slub.c:5893!
+Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
+
+Call trace:
+ sysfs_slab_add+0x258/0x260 mm/slub.c:5973
+ __kmem_cache_create+0x60/0x118 mm/slub.c:4899
+ create_cache mm/slab_common.c:229 [inline]
+ kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335
+ kmem_cache_create+0x1c/0x28 mm/slab_common.c:390
+ f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]
+ f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808
+ f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149
+ mount_bdev+0x1b8/0x210 fs/super.c:1400
+ f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512
+ legacy_get_tree+0x30/0x74 fs/fs_context.c:610
+ vfs_get_tree+0x40/0x140 fs/super.c:1530
+ do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040
+ path_mount+0x358/0x914 fs/namespace.c:3370
+ do_mount fs/namespace.c:3383 [inline]
+ __do_sys_mount fs/namespace.c:3591 [inline]
+ __se_sys_mount fs/namespace.c:3568 [inline]
+ __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568
+
+Cc: <stable@kernel.org>
+Fixes: 81819f0fc8285 ("SLUB core")
+Reported-by: syzbot+81684812ea68216e08c5@syzkaller.appspotmail.com
+Reviewed-by: Muchun Song <songmuchun@bytedance.com>
+Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
+Signed-off-by: Chao Yu <chao.yu@oppo.com>
+Acked-by: David Rientjes <rientjes@google.com>
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/slub.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/mm/slub.c
++++ b/mm/slub.c
+@@ -5869,7 +5869,8 @@ static char *create_unique_id(struct kme
+ char *name = kmalloc(ID_STR_LENGTH, GFP_KERNEL);
+ char *p = name;
+
+- BUG_ON(!name);
++ if (!name)
++ return ERR_PTR(-ENOMEM);
+
+ *p++ = ':';
+ /*
+@@ -5927,6 +5928,8 @@ static int sysfs_slab_add(struct kmem_ca
+ * for the symlinks.
+ */
+ name = create_unique_id(s);
++ if (IS_ERR(name))
++ return PTR_ERR(name);
+ }
+
+ s->kobj.kset = kset;
--- /dev/null
+From 6fd2c68da55c552f86e401ebe40c4a619025ef69 Mon Sep 17 00:00:00 2001
+From: Haiyang Zhang <haiyangz@microsoft.com>
+Date: Sun, 11 Sep 2022 13:40:05 -0700
+Subject: net: mana: Add rmb after checking owner bits
+
+From: Haiyang Zhang <haiyangz@microsoft.com>
+
+commit 6fd2c68da55c552f86e401ebe40c4a619025ef69 upstream.
+
+Per GDMA spec, rmb is necessary after checking owner_bits, before
+reading EQ or CQ entries.
+
+Add rmb in these two places to comply with the specs.
+
+Cc: stable@vger.kernel.org
+Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
+Reported-by: Sinan Kaya <Sinan.Kaya@microsoft.com>
+Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
+Reviewed-by: Dexuan Cui <decui@microsoft.com>
+Link: https://lore.kernel.org/r/1662928805-15861-1-git-send-email-haiyangz@microsoft.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/microsoft/mana/gdma_main.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
++++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
+@@ -368,6 +368,11 @@ static void mana_gd_process_eq_events(vo
+ break;
+ }
+
++ /* Per GDMA spec, rmb is necessary after checking owner_bits, before
++ * reading eqe.
++ */
++ rmb();
++
+ mana_gd_process_eqe(eq);
+
+ eq->head++;
+@@ -1096,6 +1101,11 @@ static int mana_gd_read_cqe(struct gdma_
+ if (WARN_ON_ONCE(owner_bits != new_bits))
+ return -1;
+
++ /* Per GDMA spec, rmb is necessary after checking owner_bits, before
++ * reading completion info
++ */
++ rmb();
++
+ comp->wq_num = cqe->cqe_info.wq_num;
+ comp->is_sq = cqe->cqe_info.is_sq;
+ memcpy(comp->cqe_data, cqe->cqe_data, GDMA_COMP_DATA_SIZE);
--- /dev/null
+From 762df359aa5849e010ef04c3ed79d57588ce17d9 Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Fri, 24 Sep 2021 01:55:27 +0000
+Subject: riscv: fix a nasty sigreturn bug...
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit 762df359aa5849e010ef04c3ed79d57588ce17d9 upstream.
+
+riscv has an equivalent of arm bug fixed by 653d48b22166 ("arm: fix
+really nasty sigreturn bug"); if signal gets caught by an interrupt that
+hits when we have the right value in a0 (-513), *and* another signal
+gets delivered upon sigreturn() (e.g. included into the blocked mask for
+the first signal and posted while the handler had been running), the
+syscall restart logics will see regs->cause equal to EXC_SYSCALL (we are
+in a syscall, after all) and a0 already restored to its original value
+(-513, which happens to be -ERESTARTNOINTR) and assume that we need to
+apply the usual syscall restart logics.
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Fixes: e2c0cdfba7f6 ("RISC-V: User-facing API")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/YxJEiSq%2FCGaL6Gm9@ZenIV/
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/kernel/signal.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/riscv/kernel/signal.c
++++ b/arch/riscv/kernel/signal.c
+@@ -121,6 +121,8 @@ SYSCALL_DEFINE0(rt_sigreturn)
+ if (restore_altstack(&frame->uc.uc_stack))
+ goto badframe;
+
++ regs->cause = -1UL;
++
+ return regs->a0;
+
+ badframe:
thunderbolt-add-support-for-intel-maple-ridge-single-port-controller.patch
efi-x86-wipe-setup_data-on-pure-efi-boot.patch
efi-libstub-check-shim-mode-using-moksbstatert.patch
+wifi-mt76-fix-reading-current-per-tid-starting-sequence-number-for-aggregation.patch
+gpio-mockup-fix-null-pointer-dereference-when-removing-debugfs.patch
+gpio-mockup-fix-potential-resource-leakage-when-register-a-chip.patch
+gpiolib-cdev-set-lineevent_state-irq-after-irq-register-successfully.patch
+riscv-fix-a-nasty-sigreturn-bug.patch
+kasan-call-kasan_malloc-from-__kmalloc_-track_caller.patch
+can-flexcan-flexcan_mailbox_read-fix-return-value-for-drop-true.patch
+net-mana-add-rmb-after-checking-owner-bits.patch
+mm-slub-fix-to-return-errno-if-kmalloc-fails.patch
+mm-slub-fix-flush_cpu_slab-__free_slab-invocations-in-task-context.patch
+kvm-x86-inject-ud-on-emulated-xsetbv-if-xsaves-isn-t-enabled.patch
+arm64-topology-fix-possible-overflow-in-amu_fie_setup.patch
+vmlinux.lds.h-cfi-reduce-alignment-of-jump-table-to-function-alignment.patch
--- /dev/null
+From 13b0566962914e167cb3238fbe29ced618f07a27 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Thu, 22 Sep 2022 22:57:15 +0100
+Subject: vmlinux.lds.h: CFI: Reduce alignment of jump-table to function alignment
+
+From: Will Deacon <will@kernel.org>
+
+commit 13b0566962914e167cb3238fbe29ced618f07a27 upstream.
+
+Due to undocumented, hysterical raisins on x86, the CFI jump-table
+sections in .text are needlessly aligned to PMD_SIZE in the vmlinux
+linker script. When compiling a CFI-enabled arm64 kernel with a 64KiB
+page-size, a PMD maps 512MiB of virtual memory and so the .text section
+increases to a whopping 940MiB and blows the final Image up to 960MiB.
+Others report a link failure.
+
+Since the CFI jump-table requires only instruction alignment, reduce the
+alignment directives to function alignment for parity with other parts
+of the .text section. This reduces the size of the .text section for the
+aforementioned 64KiB page size arm64 kernel to 19MiB for a much more
+reasonable total Image size of 39MiB.
+
+Cc: Sami Tolvanen <samitolvanen@google.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: "Mohan Rao .vanimina" <mailtoc.mohanrao@gmail.com>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Nathan Chancellor <nathan@kernel.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/all/CAL_GTzigiNOMYkOPX1KDnagPhJtFNqSK=1USNbS0wUL4PW6-Uw@mail.gmail.com/
+Fixes: cf68fffb66d6 ("add support for Clang CFI")
+Reviewed-by: Mark Rutland <mark.rutland@arm.com>
+Tested-by: Mark Rutland <mark.rutland@arm.com>
+Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Link: https://lore.kernel.org/r/20220922215715.13345-1-will@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/asm-generic/vmlinux.lds.h | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/include/asm-generic/vmlinux.lds.h
++++ b/include/asm-generic/vmlinux.lds.h
+@@ -549,10 +549,9 @@
+ */
+ #ifdef CONFIG_CFI_CLANG
+ #define TEXT_CFI_JT \
+- . = ALIGN(PMD_SIZE); \
++ ALIGN_FUNCTION(); \
+ __cfi_jt_start = .; \
+ *(.text..L.cfi.jumptable .text..L.cfi.jumptable.*) \
+- . = ALIGN(PMD_SIZE); \
+ __cfi_jt_end = .;
+ #else
+ #define TEXT_CFI_JT
--- /dev/null
+From c3a510e2b53785df31d882a773c4c0780b4c825f Mon Sep 17 00:00:00 2001
+From: Felix Fietkau <nbd@nbd.name>
+Date: Fri, 26 Aug 2022 20:23:29 +0200
+Subject: wifi: mt76: fix reading current per-tid starting sequence number for aggregation
+
+From: Felix Fietkau <nbd@nbd.name>
+
+commit c3a510e2b53785df31d882a773c4c0780b4c825f upstream.
+
+The code was accidentally shifting register values down by tid % 32 instead of
+(tid * field_size) % 32.
+
+Cc: stable@vger.kernel.org
+Fixes: a28bef561a5c ("mt76: mt7615: re-enable offloading of sequence number assignment")
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://lore.kernel.org/r/20220826182329.18155-1-nbd@nbd.name
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/mediatek/mt76/mt7615/mac.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
++++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+@@ -1038,7 +1038,7 @@ u32 mt7615_mac_get_sta_tid_sn(struct mt7
+ offset %= 32;
+
+ val = mt76_rr(dev, addr);
+- val >>= (tid % 32);
++ val >>= offset;
+
+ if (offset > 20) {
+ addr += 4;
projects / thirdparty / kernel / stable-queue.git / commitdiff
