--- /dev/null
+From 0aa6b294b312d9710804679abd2c0c8ca52cc2bc Mon Sep 17 00:00:00 2001
+From: Zhen Ni <nizhen@uniontech.com>
+Date: Wed, 2 Mar 2022 15:42:41 +0800
+Subject: ALSA: intel_hdmi: Fix reference to PCM buffer address
+
+From: Zhen Ni <nizhen@uniontech.com>
+
+commit 0aa6b294b312d9710804679abd2c0c8ca52cc2bc upstream.
+
+PCM buffers might be allocated dynamically when the buffer
+preallocation failed or a larger buffer is requested, and it's not
+guaranteed that substream->dma_buffer points to the actually used
+buffer. The driver needs to refer to substream->runtime->dma_addr
+instead for the buffer address.
+
+Signed-off-by: Zhen Ni <nizhen@uniontech.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220302074241.30469-1-nizhen@uniontech.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/x86/intel_hdmi_audio.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/x86/intel_hdmi_audio.c
++++ b/sound/x86/intel_hdmi_audio.c
+@@ -1261,7 +1261,7 @@ static int had_pcm_mmap(struct snd_pcm_s
+ {
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+ return remap_pfn_range(vma, vma->vm_start,
+- substream->dma_buffer.addr >> PAGE_SHIFT,
++ substream->runtime->dma_addr >> PAGE_SHIFT,
+ vma->vm_end - vma->vm_start, vma->vm_page_prot);
+ }
+
--- /dev/null
+From 9bdd10d57a8807dba0003af0325191f3cec0f11c Mon Sep 17 00:00:00 2001
+From: Marek Vasut <marex@denx.de>
+Date: Tue, 15 Feb 2022 14:06:45 +0100
+Subject: ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min
+
+From: Marek Vasut <marex@denx.de>
+
+commit 9bdd10d57a8807dba0003af0325191f3cec0f11c upstream.
+
+While the $val/$val2 values passed in from userspace are always >= 0
+integers, the limits of the control can be signed integers and the $min
+can be non-zero and less than zero. To correctly validate $val/$val2
+against platform_max, add the $min offset to val first.
+
+Fixes: 817f7c9335ec0 ("ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()")
+Signed-off-by: Marek Vasut <marex@denx.de>
+Cc: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20220215130645.164025-1-marex@denx.de
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/soc-ops.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/soc/soc-ops.c
++++ b/sound/soc/soc-ops.c
+@@ -317,7 +317,7 @@ int snd_soc_put_volsw(struct snd_kcontro
+ mask = BIT(sign_bit + 1) - 1;
+
+ val = ucontrol->value.integer.value[0];
+- if (mc->platform_max && val > mc->platform_max)
++ if (mc->platform_max && ((int)val + min) > mc->platform_max)
+ return -EINVAL;
+ if (val > max - min)
+ return -EINVAL;
+@@ -330,7 +330,7 @@ int snd_soc_put_volsw(struct snd_kcontro
+ val = val << shift;
+ if (snd_soc_volsw_is_stereo(mc)) {
+ val2 = ucontrol->value.integer.value[1];
+- if (mc->platform_max && val2 > mc->platform_max)
++ if (mc->platform_max && ((int)val2 + min) > mc->platform_max)
+ return -EINVAL;
+ if (val2 > max - min)
+ return -EINVAL;
--- /dev/null
+From 439a8468242b313486e69b8cc3b45ddcfa898fbf Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Mon, 28 Feb 2022 10:59:12 -0800
+Subject: binfmt_elf: Avoid total_mapping_size for ET_EXEC
+
+From: Kees Cook <keescook@chromium.org>
+
+commit 439a8468242b313486e69b8cc3b45ddcfa898fbf upstream.
+
+Partially revert commit 5f501d555653 ("binfmt_elf: reintroduce using
+MAP_FIXED_NOREPLACE"), which applied the ET_DYN "total_mapping_size"
+logic also to ET_EXEC.
+
+At least ia64 has ET_EXEC PT_LOAD segments that are not virtual-address
+contiguous (but _are_ file-offset contiguous). This would result in a
+giant mapping attempting to cover the entire span, including the virtual
+address range hole, and well beyond the size of the ELF file itself,
+causing the kernel to refuse to load it. For example:
+
+$ readelf -lW /usr/bin/gcc
+...
+Program Headers:
+ Type Offset VirtAddr PhysAddr FileSiz MemSiz ...
+...
+ LOAD 0x000000 0x4000000000000000 0x4000000000000000 0x00b5a0 0x00b5a0 ...
+ LOAD 0x00b5a0 0x600000000000b5a0 0x600000000000b5a0 0x0005ac 0x000710 ...
+...
+ ^^^^^^^^ ^^^^^^^^^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^
+
+File offset range : 0x000000-0x00bb4c
+ 0x00bb4c bytes
+
+Virtual address range : 0x4000000000000000-0x600000000000bcb0
+ 0x200000000000bcb0 bytes
+
+Remove the total_mapping_size logic for ET_EXEC, which reduces the
+ET_EXEC MAP_FIXED_NOREPLACE coverage to only the first PT_LOAD (better
+than nothing), and retains it for ET_DYN.
+
+Ironically, this is the reverse of the problem that originally caused
+problems with MAP_FIXED_NOREPLACE: overlapping PT_LOAD segments. Future
+work could restore full coverage if load_elf_binary() were to perform
+mappings in a separate phase from the loading (where it could resolve
+both overlaps and holes).
+
+Cc: Eric Biederman <ebiederm@xmission.com>
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Cc: linux-fsdevel@vger.kernel.org
+Cc: linux-mm@kvack.org
+Reported-by: matoro <matoro_bugzilla_kernel@matoro.tk>
+Fixes: 5f501d555653 ("binfmt_elf: reintroduce using MAP_FIXED_NOREPLACE")
+Link: https://lore.kernel.org/r/a3edd529-c42d-3b09-135c-7e98a15b150f@leemhuis.info
+Tested-by: matoro <matoro_mailinglist_kernel@matoro.tk>
+Link: https://lore.kernel.org/lkml/ce8af9c13bcea9230c7689f3c1e0e2cd@matoro.tk
+Tested-By: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Link: https://lore.kernel.org/lkml/49182d0d-708b-4029-da5f-bc18603440a6@physik.fu-berlin.de
+Cc: stable@vger.kernel.org
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/binfmt_elf.c | 25 ++++++++++++++++++-------
+ 1 file changed, 18 insertions(+), 7 deletions(-)
+
+--- a/fs/binfmt_elf.c
++++ b/fs/binfmt_elf.c
+@@ -1135,14 +1135,25 @@ out_free_interp:
+ * is then page aligned.
+ */
+ load_bias = ELF_PAGESTART(load_bias - vaddr);
+- }
+
+- /*
+- * Calculate the entire size of the ELF mapping (total_size).
+- * (Note that load_addr_set is set to true later once the
+- * initial mapping is performed.)
+- */
+- if (!load_addr_set) {
++ /*
++ * Calculate the entire size of the ELF mapping
++ * (total_size), used for the initial mapping,
++ * due to load_addr_set which is set to true later
++ * once the initial mapping is performed.
++ *
++ * Note that this is only sensible when the LOAD
++ * segments are contiguous (or overlapping). If
++ * used for LOADs that are far apart, this would
++ * cause the holes between LOADs to be mapped,
++ * running the risk of having the mapping fail,
++ * as it would be larger than the ELF file itself.
++ *
++ * As a result, only ET_DYN does this, since
++ * some ET_EXEC (e.g. ia64) may have large virtual
++ * memory holes between LOADs.
++ *
++ */
+ total_size = total_mapping_size(elf_phdata,
+ elf_ex->e_phnum);
+ if (!total_size) {
--- /dev/null
+From 30939293262eb433c960c4532a0d59c4073b2b84 Mon Sep 17 00:00:00 2001
+From: Yu Kuai <yukuai3@huawei.com>
+Date: Mon, 28 Feb 2022 11:43:54 +0800
+Subject: blktrace: fix use after free for struct blk_trace
+
+From: Yu Kuai <yukuai3@huawei.com>
+
+commit 30939293262eb433c960c4532a0d59c4073b2b84 upstream.
+
+When tracing the whole disk, 'dropped' and 'msg' will be created
+under 'q->debugfs_dir' and 'bt->dir' is NULL, thus blk_trace_free()
+won't remove those files. What's worse, the following UAF can be
+triggered because of accessing stale 'dropped' and 'msg':
+
+==================================================================
+BUG: KASAN: use-after-free in blk_dropped_read+0x89/0x100
+Read of size 4 at addr ffff88816912f3d8 by task blktrace/1188
+
+CPU: 27 PID: 1188 Comm: blktrace Not tainted 5.17.0-rc4-next-20220217+ #469
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-4
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x34/0x44
+ print_address_description.constprop.0.cold+0xab/0x381
+ ? blk_dropped_read+0x89/0x100
+ ? blk_dropped_read+0x89/0x100
+ kasan_report.cold+0x83/0xdf
+ ? blk_dropped_read+0x89/0x100
+ kasan_check_range+0x140/0x1b0
+ blk_dropped_read+0x89/0x100
+ ? blk_create_buf_file_callback+0x20/0x20
+ ? kmem_cache_free+0xa1/0x500
+ ? do_sys_openat2+0x258/0x460
+ full_proxy_read+0x8f/0xc0
+ vfs_read+0xc6/0x260
+ ksys_read+0xb9/0x150
+ ? vfs_write+0x3d0/0x3d0
+ ? fpregs_assert_state_consistent+0x55/0x60
+ ? exit_to_user_mode_prepare+0x39/0x1e0
+ do_syscall_64+0x35/0x80
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+RIP: 0033:0x7fbc080d92fd
+Code: ce 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 1
+RSP: 002b:00007fbb95ff9cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000000
+RAX: ffffffffffffffda RBX: 00007fbb95ff9dc0 RCX: 00007fbc080d92fd
+RDX: 0000000000000100 RSI: 00007fbb95ff9cc0 RDI: 0000000000000045
+RBP: 0000000000000045 R08: 0000000000406299 R09: 00000000fffffffd
+R10: 000000000153afa0 R11: 0000000000000293 R12: 00007fbb780008c0
+R13: 00007fbb78000938 R14: 0000000000608b30 R15: 00007fbb780029c8
+ </TASK>
+
+Allocated by task 1050:
+ kasan_save_stack+0x1e/0x40
+ __kasan_kmalloc+0x81/0xa0
+ do_blk_trace_setup+0xcb/0x410
+ __blk_trace_setup+0xac/0x130
+ blk_trace_ioctl+0xe9/0x1c0
+ blkdev_ioctl+0xf1/0x390
+ __x64_sys_ioctl+0xa5/0xe0
+ do_syscall_64+0x35/0x80
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+Freed by task 1050:
+ kasan_save_stack+0x1e/0x40
+ kasan_set_track+0x21/0x30
+ kasan_set_free_info+0x20/0x30
+ __kasan_slab_free+0x103/0x180
+ kfree+0x9a/0x4c0
+ __blk_trace_remove+0x53/0x70
+ blk_trace_ioctl+0x199/0x1c0
+ blkdev_common_ioctl+0x5e9/0xb30
+ blkdev_ioctl+0x1a5/0x390
+ __x64_sys_ioctl+0xa5/0xe0
+ do_syscall_64+0x35/0x80
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+The buggy address belongs to the object at ffff88816912f380
+ which belongs to the cache kmalloc-96 of size 96
+The buggy address is located 88 bytes inside of
+ 96-byte region [ffff88816912f380, ffff88816912f3e0)
+The buggy address belongs to the page:
+page:000000009a1b4e7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0f
+flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)
+raw: 0017ffffc0000200 ffffea00044f1100 dead000000000002 ffff88810004c780
+raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
+page dumped because: kasan: bad access detected
+
+Memory state around the buggy address:
+ ffff88816912f280: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
+ ffff88816912f300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
+>ffff88816912f380: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
+ ^
+ ffff88816912f400: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
+ ffff88816912f480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
+==================================================================
+
+Fixes: c0ea57608b69 ("blktrace: remove debugfs file dentries from struct blk_trace")
+Signed-off-by: Yu Kuai <yukuai3@huawei.com>
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Link: https://lore.kernel.org/r/20220228034354.4047385-1-yukuai3@huawei.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/blktrace.c | 26 ++++++++++++++++++--------
+ 1 file changed, 18 insertions(+), 8 deletions(-)
+
+--- a/kernel/trace/blktrace.c
++++ b/kernel/trace/blktrace.c
+@@ -310,10 +310,20 @@ record_it:
+ local_irq_restore(flags);
+ }
+
+-static void blk_trace_free(struct blk_trace *bt)
++static void blk_trace_free(struct request_queue *q, struct blk_trace *bt)
+ {
+ relay_close(bt->rchan);
+- debugfs_remove(bt->dir);
++
++ /*
++ * If 'bt->dir' is not set, then both 'dropped' and 'msg' are created
++ * under 'q->debugfs_dir', thus lookup and remove them.
++ */
++ if (!bt->dir) {
++ debugfs_remove(debugfs_lookup("dropped", q->debugfs_dir));
++ debugfs_remove(debugfs_lookup("msg", q->debugfs_dir));
++ } else {
++ debugfs_remove(bt->dir);
++ }
+ free_percpu(bt->sequence);
+ free_percpu(bt->msg_data);
+ kfree(bt);
+@@ -335,10 +345,10 @@ static void put_probe_ref(void)
+ mutex_unlock(&blk_probe_mutex);
+ }
+
+-static void blk_trace_cleanup(struct blk_trace *bt)
++static void blk_trace_cleanup(struct request_queue *q, struct blk_trace *bt)
+ {
+ synchronize_rcu();
+- blk_trace_free(bt);
++ blk_trace_free(q, bt);
+ put_probe_ref();
+ }
+
+@@ -352,7 +362,7 @@ static int __blk_trace_remove(struct req
+ return -EINVAL;
+
+ if (bt->trace_state != Blktrace_running)
+- blk_trace_cleanup(bt);
++ blk_trace_cleanup(q, bt);
+
+ return 0;
+ }
+@@ -572,7 +582,7 @@ static int do_blk_trace_setup(struct req
+ ret = 0;
+ err:
+ if (ret)
+- blk_trace_free(bt);
++ blk_trace_free(q, bt);
+ return ret;
+ }
+
+@@ -1616,7 +1626,7 @@ static int blk_trace_remove_queue(struct
+
+ put_probe_ref();
+ synchronize_rcu();
+- blk_trace_free(bt);
++ blk_trace_free(q, bt);
+ return 0;
+ }
+
+@@ -1647,7 +1657,7 @@ static int blk_trace_setup_queue(struct
+ return 0;
+
+ free_bt:
+- blk_trace_free(bt);
++ blk_trace_free(q, bt);
+ return ret;
+ }
+
--- /dev/null
+From 1d925758ba1a5d2716a847903e2fd04efcbd9862 Mon Sep 17 00:00:00 2001
+From: "Leo (Hanghong) Ma" <hanghong.ma@amd.com>
+Date: Fri, 12 Nov 2021 10:11:35 -0500
+Subject: drm/amd/display: Reduce dmesg error to a debug print
+
+From: Leo (Hanghong) Ma <hanghong.ma@amd.com>
+
+commit 1d925758ba1a5d2716a847903e2fd04efcbd9862 upstream.
+
+[Why & How]
+Dmesg errors are found on dcn3.1 during reset test, but it's not
+a really failure. So reduce it to a debug print.
+
+Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com>
+Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
++++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+@@ -4454,7 +4454,9 @@ bool dp_retrieve_lttpr_cap(struct dc_lin
+ lttpr_dpcd_data,
+ sizeof(lttpr_dpcd_data));
+ if (status != DC_OK) {
+- dm_error("%s: Read LTTPR caps data failed.\n", __func__);
++#if defined(CONFIG_DRM_AMD_DC_DCN)
++ DC_LOG_DP2("%s: Read LTTPR caps data failed.\n", __func__);
++#endif
+ return false;
+ }
+
--- /dev/null
+From 08783aa7693f55619859f4f63f384abf17cb58c5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Thu, 24 Feb 2022 15:21:42 +0200
+Subject: drm/i915: s/JSP2/ICP2/ PCH
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit 08783aa7693f55619859f4f63f384abf17cb58c5 upstream.
+
+This JSP2 PCH actually seems to be some special Apple
+specific ICP variant rather than a JSP. Make it so. Or at
+least all the references to it seem to be some Apple ICL
+machines. Didn't manage to find these PCI IDs in any
+public chipset docs unfortunately.
+
+The only thing we're losing here with this JSP->ICP change
+is Wa_14011294188, but based on the HSD that isn't actually
+needed on any ICP based design (including JSP), only TGP
+based stuff (including MCC) really need it. The documented
+w/a just never made that distinction because Windows didn't
+want to differentiate between JSP and MCC (not sure how
+they handle hpd/ddc/etc. then though...).
+
+Cc: stable@vger.kernel.org
+Cc: Matt Roper <matthew.d.roper@intel.com>
+Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
+Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4226
+Fixes: 943682e3bd19 ("drm/i915: Introduce Jasper Lake PCH")
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220224132142.12927-1-ville.syrjala@linux.intel.com
+Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
+Tested-by: Tomas Bzatek <bugs@bzatek.net>
+(cherry picked from commit 53581504a8e216d435f114a4f2596ad0dfd902fc)
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/intel_pch.c | 2 +-
+ drivers/gpu/drm/i915/intel_pch.h | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_pch.c
++++ b/drivers/gpu/drm/i915/intel_pch.c
+@@ -108,6 +108,7 @@ intel_pch_type(const struct drm_i915_pri
+ /* Comet Lake V PCH is based on KBP, which is SPT compatible */
+ return PCH_SPT;
+ case INTEL_PCH_ICP_DEVICE_ID_TYPE:
++ case INTEL_PCH_ICP2_DEVICE_ID_TYPE:
+ drm_dbg_kms(&dev_priv->drm, "Found Ice Lake PCH\n");
+ drm_WARN_ON(&dev_priv->drm, !IS_ICELAKE(dev_priv));
+ return PCH_ICP;
+@@ -123,7 +124,6 @@ intel_pch_type(const struct drm_i915_pri
+ !IS_GEN9_BC(dev_priv));
+ return PCH_TGP;
+ case INTEL_PCH_JSP_DEVICE_ID_TYPE:
+- case INTEL_PCH_JSP2_DEVICE_ID_TYPE:
+ drm_dbg_kms(&dev_priv->drm, "Found Jasper Lake PCH\n");
+ drm_WARN_ON(&dev_priv->drm, !IS_JSL_EHL(dev_priv));
+ return PCH_JSP;
+--- a/drivers/gpu/drm/i915/intel_pch.h
++++ b/drivers/gpu/drm/i915/intel_pch.h
+@@ -50,11 +50,11 @@ enum intel_pch {
+ #define INTEL_PCH_CMP2_DEVICE_ID_TYPE 0x0680
+ #define INTEL_PCH_CMP_V_DEVICE_ID_TYPE 0xA380
+ #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
++#define INTEL_PCH_ICP2_DEVICE_ID_TYPE 0x3880
+ #define INTEL_PCH_MCC_DEVICE_ID_TYPE 0x4B00
+ #define INTEL_PCH_TGP_DEVICE_ID_TYPE 0xA080
+ #define INTEL_PCH_TGP2_DEVICE_ID_TYPE 0x4380
+ #define INTEL_PCH_JSP_DEVICE_ID_TYPE 0x4D80
+-#define INTEL_PCH_JSP2_DEVICE_ID_TYPE 0x3880
+ #define INTEL_PCH_ADP_DEVICE_ID_TYPE 0x7A80
+ #define INTEL_PCH_ADP2_DEVICE_ID_TYPE 0x5180
+ #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
--- /dev/null
+From 5ce97f4ec5e0f8726a5dda1710727b1ee9badcac Mon Sep 17 00:00:00 2001
+From: Lennert Buytenhek <buytenh@wantstofly.org>
+Date: Mon, 4 Oct 2021 13:07:24 +0300
+Subject: iommu/amd: Recover from event log overflow
+
+From: Lennert Buytenhek <buytenh@wantstofly.org>
+
+commit 5ce97f4ec5e0f8726a5dda1710727b1ee9badcac upstream.
+
+The AMD IOMMU logs I/O page faults and such to a ring buffer in
+system memory, and this ring buffer can overflow. The AMD IOMMU
+spec has the following to say about the interrupt status bit that
+signals this overflow condition:
+
+ EventOverflow: Event log overflow. RW1C. Reset 0b. 1 = IOMMU
+ event log overflow has occurred. This bit is set when a new
+ event is to be written to the event log and there is no usable
+ entry in the event log, causing the new event information to
+ be discarded. An interrupt is generated when EventOverflow = 1b
+ and MMIO Offset 0018h[EventIntEn] = 1b. No new event log
+ entries are written while this bit is set. Software Note: To
+ resume logging, clear EventOverflow (W1C), and write a 1 to
+ MMIO Offset 0018h[EventLogEn].
+
+The AMD IOMMU driver doesn't currently implement this recovery
+sequence, meaning that if a ring buffer overflow occurs, logging
+of EVT/PPR/GA events will cease entirely.
+
+This patch implements the spec-mandated reset sequence, with the
+minor tweak that the hardware seems to want to have a 0 written to
+MMIO Offset 0018h[EventLogEn] first, before writing an 1 into this
+field, or the IOMMU won't actually resume logging events.
+
+Signed-off-by: Lennert Buytenhek <buytenh@arista.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/YVrSXEdW2rzEfOvk@wantstofly.org
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/amd/amd_iommu.h | 1 +
+ drivers/iommu/amd/amd_iommu_types.h | 1 +
+ drivers/iommu/amd/init.c | 10 ++++++++++
+ drivers/iommu/amd/iommu.c | 10 ++++++++--
+ 4 files changed, 20 insertions(+), 2 deletions(-)
+
+--- a/drivers/iommu/amd/amd_iommu.h
++++ b/drivers/iommu/amd/amd_iommu.h
+@@ -14,6 +14,7 @@
+ extern irqreturn_t amd_iommu_int_thread(int irq, void *data);
+ extern irqreturn_t amd_iommu_int_handler(int irq, void *data);
+ extern void amd_iommu_apply_erratum_63(u16 devid);
++extern void amd_iommu_restart_event_logging(struct amd_iommu *iommu);
+ extern void amd_iommu_reset_cmd_buffer(struct amd_iommu *iommu);
+ extern int amd_iommu_init_devices(void);
+ extern void amd_iommu_uninit_devices(void);
+--- a/drivers/iommu/amd/amd_iommu_types.h
++++ b/drivers/iommu/amd/amd_iommu_types.h
+@@ -110,6 +110,7 @@
+ #define PASID_MASK 0x0000ffff
+
+ /* MMIO status bits */
++#define MMIO_STATUS_EVT_OVERFLOW_INT_MASK (1 << 0)
+ #define MMIO_STATUS_EVT_INT_MASK (1 << 1)
+ #define MMIO_STATUS_COM_WAIT_INT_MASK (1 << 2)
+ #define MMIO_STATUS_PPR_INT_MASK (1 << 6)
+--- a/drivers/iommu/amd/init.c
++++ b/drivers/iommu/amd/init.c
+@@ -658,6 +658,16 @@ static int __init alloc_command_buffer(s
+ }
+
+ /*
++ * This function restarts event logging in case the IOMMU experienced
++ * an event log buffer overflow.
++ */
++void amd_iommu_restart_event_logging(struct amd_iommu *iommu)
++{
++ iommu_feature_disable(iommu, CONTROL_EVT_LOG_EN);
++ iommu_feature_enable(iommu, CONTROL_EVT_LOG_EN);
++}
++
++/*
+ * This function resets the command buffer if the IOMMU stopped fetching
+ * commands from it.
+ */
+--- a/drivers/iommu/amd/iommu.c
++++ b/drivers/iommu/amd/iommu.c
+@@ -764,7 +764,8 @@ amd_iommu_set_pci_msi_domain(struct devi
+ #endif /* !CONFIG_IRQ_REMAP */
+
+ #define AMD_IOMMU_INT_MASK \
+- (MMIO_STATUS_EVT_INT_MASK | \
++ (MMIO_STATUS_EVT_OVERFLOW_INT_MASK | \
++ MMIO_STATUS_EVT_INT_MASK | \
+ MMIO_STATUS_PPR_INT_MASK | \
+ MMIO_STATUS_GALOG_INT_MASK)
+
+@@ -774,7 +775,7 @@ irqreturn_t amd_iommu_int_thread(int irq
+ u32 status = readl(iommu->mmio_base + MMIO_STATUS_OFFSET);
+
+ while (status & AMD_IOMMU_INT_MASK) {
+- /* Enable EVT and PPR and GA interrupts again */
++ /* Enable interrupt sources again */
+ writel(AMD_IOMMU_INT_MASK,
+ iommu->mmio_base + MMIO_STATUS_OFFSET);
+
+@@ -795,6 +796,11 @@ irqreturn_t amd_iommu_int_thread(int irq
+ }
+ #endif
+
++ if (status & MMIO_STATUS_EVT_OVERFLOW_INT_MASK) {
++ pr_info_ratelimited("IOMMU event log overflow\n");
++ amd_iommu_restart_event_logging(iommu);
++ }
++
+ /*
+ * Hardware bug: ERBT1312
+ * When re-enabling interrupt (by writing 1
--- /dev/null
+From b00833768e170a31af09268f7ab96aecfcca9623 Mon Sep 17 00:00:00 2001
+From: Adrian Huang <ahuang12@lenovo.com>
+Date: Mon, 21 Feb 2022 13:33:48 +0800
+Subject: iommu/vt-d: Fix double list_add when enabling VMD in scalable mode
+
+From: Adrian Huang <ahuang12@lenovo.com>
+
+commit b00833768e170a31af09268f7ab96aecfcca9623 upstream.
+
+When enabling VMD and IOMMU scalable mode, the following kernel panic
+call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids
+CPU) during booting:
+
+pci 0000:59:00.5: Adding to iommu group 42
+...
+vmd 0000:59:00.5: PCI host bridge to bus 10000:80
+pci 10000:80:01.0: [8086:352a] type 01 class 0x060400
+pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]
+pci 10000:80:01.0: enabling Extended Tags
+pci 10000:80:01.0: PME# supported from D0 D3hot D3cold
+pci 10000:80:01.0: DMAR: Setup RID2PASID failed
+pci 10000:80:01.0: Failed to add to iommu group 42: -16
+pci 10000:80:03.0: [8086:352b] type 01 class 0x060400
+pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]
+pci 10000:80:03.0: enabling Extended Tags
+pci 10000:80:03.0: PME# supported from D0 D3hot D3cold
+------------[ cut here ]------------
+kernel BUG at lib/list_debug.c:29!
+invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
+CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7
+Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022
+Workqueue: events work_for_cpu_fn
+RIP: 0010:__list_add_valid.cold+0x26/0x3f
+Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f
+ 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1
+ fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9
+ 9e e8 8b b1 fe
+RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246
+RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8
+RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20
+RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888
+R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0
+R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70
+FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
+PKRU: 55555554
+Call Trace:
+ <TASK>
+ intel_pasid_alloc_table+0x9c/0x1d0
+ dmar_insert_one_dev_info+0x423/0x540
+ ? device_to_iommu+0x12d/0x2f0
+ intel_iommu_attach_device+0x116/0x290
+ __iommu_attach_device+0x1a/0x90
+ iommu_group_add_device+0x190/0x2c0
+ __iommu_probe_device+0x13e/0x250
+ iommu_probe_device+0x24/0x150
+ iommu_bus_notifier+0x69/0x90
+ blocking_notifier_call_chain+0x5a/0x80
+ device_add+0x3db/0x7b0
+ ? arch_memremap_can_ram_remap+0x19/0x50
+ ? memremap+0x75/0x140
+ pci_device_add+0x193/0x1d0
+ pci_scan_single_device+0xb9/0xf0
+ pci_scan_slot+0x4c/0x110
+ pci_scan_child_bus_extend+0x3a/0x290
+ vmd_enable_domain.constprop.0+0x63e/0x820
+ vmd_probe+0x163/0x190
+ local_pci_probe+0x42/0x80
+ work_for_cpu_fn+0x13/0x20
+ process_one_work+0x1e2/0x3b0
+ worker_thread+0x1c4/0x3a0
+ ? rescuer_thread+0x370/0x370
+ kthread+0xc7/0xf0
+ ? kthread_complete_and_exit+0x20/0x20
+ ret_from_fork+0x1f/0x30
+ </TASK>
+Modules linked in:
+---[ end trace 0000000000000000 ]---
+...
+Kernel panic - not syncing: Fatal exception
+Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
+---[ end Kernel panic - not syncing: Fatal exception ]---
+
+The following 'lspci' output shows devices '10000:80:*' are subdevices of
+the VMD device 0000:59:00.5:
+
+ $ lspci
+ ...
+ 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)
+ ...
+ 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)
+ 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)
+ 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)
+ 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)
+ 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]
+ 10000:82:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]
+
+The symptom 'list_add double add' is caused by the following failure
+message:
+
+ pci 10000:80:01.0: DMAR: Setup RID2PASID failed
+ pci 10000:80:01.0: Failed to add to iommu group 42: -16
+ pci 10000:80:03.0: [8086:352b] type 01 class 0x060400
+
+Device 10000:80:01.0 is the subdevice of the VMD device 0000:59:00.5,
+so invoking intel_pasid_alloc_table() gets the pasid_table of the VMD
+device 0000:59:00.5. Here is call path:
+
+ intel_pasid_alloc_table
+ pci_for_each_dma_alias
+ get_alias_pasid_table
+ search_pasid_table
+
+pci_real_dma_dev() in pci_for_each_dma_alias() gets the real dma device
+which is the VMD device 0000:59:00.5. However, pte of the VMD device
+0000:59:00.5 has been configured during this message "pci 0000:59:00.5:
+Adding to iommu group 42". So, the status -EBUSY is returned when
+configuring pasid entry for device 10000:80:01.0.
+
+It then invokes dmar_remove_one_dev_info() to release
+'struct device_domain_info *' from iommu_devinfo_cache. But, the pasid
+table is not released because of the following statement in
+__dmar_remove_one_dev_info():
+
+ if (info->dev && !dev_is_real_dma_subdevice(info->dev)) {
+ ...
+ intel_pasid_free_table(info->dev);
+ }
+
+The subsequent dmar_insert_one_dev_info() operation of device
+10000:80:03.0 allocates 'struct device_domain_info *' from
+iommu_devinfo_cache. The allocated address is the same address that
+is released previously for device 10000:80:01.0. Finally, invoking
+device_attach_pasid_table() causes the issue.
+
+`git bisect` points to the offending commit 474dd1c65064 ("iommu/vt-d:
+Fix clearing real DMA device's scalable-mode context entries"), which
+releases the pasid table if the device is not the subdevice by
+checking the returned status of dev_is_real_dma_subdevice().
+Reverting the offending commit can work around the issue.
+
+The solution is to prevent from allocating pasid table if those
+devices are subdevices of the VMD device.
+
+Fixes: 474dd1c65064 ("iommu/vt-d: Fix clearing real DMA device's scalable-mode context entries")
+Cc: stable@vger.kernel.org # v5.14+
+Signed-off-by: Adrian Huang <ahuang12@lenovo.com>
+Link: https://lore.kernel.org/r/20220216091307.703-1-adrianhuang0701@gmail.com
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Link: https://lore.kernel.org/r/20220221053348.262724-2-baolu.lu@linux.intel.com
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/intel/iommu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iommu/intel/iommu.c
++++ b/drivers/iommu/intel/iommu.c
+@@ -2773,7 +2773,7 @@ static struct dmar_domain *dmar_insert_o
+ spin_unlock_irqrestore(&device_domain_lock, flags);
+
+ /* PASID table is mandatory for a PCI device in scalable mode. */
+- if (dev && dev_is_pci(dev) && sm_supported(iommu)) {
++ if (sm_supported(iommu) && !dev_is_real_dma_subdevice(dev)) {
+ ret = intel_pasid_alloc_table(dev);
+ if (ret) {
+ dev_err(dev, "PASID table allocation failed\n");
--- /dev/null
+From 5a6248c0a22352f09ea041665d3bd3e18f6f872c Mon Sep 17 00:00:00 2001
+From: Randy Dunlap <rdunlap@infradead.org>
+Date: Tue, 22 Feb 2022 19:06:30 -0800
+Subject: iwlwifi: mvm: check debugfs_dir ptr before use
+
+From: Randy Dunlap <rdunlap@infradead.org>
+
+commit 5a6248c0a22352f09ea041665d3bd3e18f6f872c upstream.
+
+When "debugfs=off" is used on the kernel command line, iwiwifi's
+mvm module uses an invalid/unchecked debugfs_dir pointer and causes
+a BUG:
+
+ BUG: kernel NULL pointer dereference, address: 000000000000004f
+ #PF: supervisor read access in kernel mode
+ #PF: error_code(0x0000) - not-present page
+ PGD 0 P4D 0
+ Oops: 0000 [#1] PREEMPT SMP
+ CPU: 1 PID: 503 Comm: modprobe Tainted: G W 5.17.0-rc5 #7
+ Hardware name: Dell Inc. Inspiron 15 5510/076F7Y, BIOS 2.4.1 11/05/2021
+ RIP: 0010:iwl_mvm_dbgfs_register+0x692/0x700 [iwlmvm]
+ Code: 69 a0 be 80 01 00 00 48 c7 c7 50 73 6a a0 e8 95 cf ee e0 48 8b 83 b0 1e 00 00 48 c7 c2 54 73 6a a0 be 64 00 00 00 48 8d 7d 8c <48> 8b 48 50 e8 15 22 07 e1 48 8b 43 28 48 8d 55 8c 48 c7 c7 5f 73
+ RSP: 0018:ffffc90000a0ba68 EFLAGS: 00010246
+ RAX: ffffffffffffffff RBX: ffff88817d6e3328 RCX: ffff88817d6e3328
+ RDX: ffffffffa06a7354 RSI: 0000000000000064 RDI: ffffc90000a0ba6c
+ RBP: ffffc90000a0bae0 R08: ffffffff824e4880 R09: ffffffffa069d620
+ R10: ffffc90000a0ba00 R11: ffffffffffffffff R12: 0000000000000000
+ R13: ffffc90000a0bb28 R14: ffff88817d6e3328 R15: ffff88817d6e3320
+ FS: 00007f64dd92d740(0000) GS:ffff88847f640000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 000000000000004f CR3: 000000016fc79001 CR4: 0000000000770ee0
+ PKRU: 55555554
+ Call Trace:
+ <TASK>
+ ? iwl_mvm_mac_setup_register+0xbdc/0xda0 [iwlmvm]
+ iwl_mvm_start_post_nvm+0x71/0x100 [iwlmvm]
+ iwl_op_mode_mvm_start+0xab8/0xb30 [iwlmvm]
+ _iwl_op_mode_start+0x6f/0xd0 [iwlwifi]
+ iwl_opmode_register+0x6a/0xe0 [iwlwifi]
+ ? 0xffffffffa0231000
+ iwl_mvm_init+0x35/0x1000 [iwlmvm]
+ ? 0xffffffffa0231000
+ do_one_initcall+0x5a/0x1b0
+ ? kmem_cache_alloc+0x1e5/0x2f0
+ ? do_init_module+0x1e/0x220
+ do_init_module+0x48/0x220
+ load_module+0x2602/0x2bc0
+ ? __kernel_read+0x145/0x2e0
+ ? kernel_read_file+0x229/0x290
+ __do_sys_finit_module+0xc5/0x130
+ ? __do_sys_finit_module+0xc5/0x130
+ __x64_sys_finit_module+0x13/0x20
+ do_syscall_64+0x38/0x90
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+ RIP: 0033:0x7f64dda564dd
+ Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1b 29 0f 00 f7 d8 64 89 01 48
+ RSP: 002b:00007ffdba393f88 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
+ RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f64dda564dd
+ RDX: 0000000000000000 RSI: 00005575399e2ab2 RDI: 0000000000000001
+ RBP: 000055753a91c5e0 R08: 0000000000000000 R09: 0000000000000002
+ R10: 0000000000000001 R11: 0000000000000246 R12: 00005575399e2ab2
+ R13: 000055753a91ceb0 R14: 0000000000000000 R15: 000055753a923018
+ </TASK>
+ Modules linked in: btintel(+) btmtk bluetooth vfat snd_hda_codec_hdmi fat snd_hda_codec_realtek snd_hda_codec_generic iwlmvm(+) snd_sof_pci_intel_tgl mac80211 snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence soundwire_bus snd_sof_intel_hda snd_sof_pci snd_sof snd_sof_xtensa_dsp snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core btrfs snd_compress snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec raid6_pq iwlwifi snd_hda_core snd_pcm snd_timer snd soundcore cfg80211 intel_ish_ipc(+) thunderbolt rfkill intel_ishtp ucsi_acpi wmi i2c_hid_acpi i2c_hid evdev
+ CR2: 000000000000004f
+ ---[ end trace 0000000000000000 ]---
+
+Check the debugfs_dir pointer for an error before using it.
+
+Fixes: 8c082a99edb9 ("iwlwifi: mvm: simplify iwl_mvm_dbgfs_register")
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Cc: Luca Coelho <luciano.coelho@intel.com>
+Cc: linux-wireless@vger.kernel.org
+Cc: Kalle Valo <kvalo@kernel.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Cc: stable <stable@vger.kernel.org>
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Link: https://lore.kernel.org/r/20220223030630.23241-1-rdunlap@infradead.org
+[change to make both conditional]
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
++++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
+@@ -5,6 +5,7 @@
+ * Copyright (C) 2016-2017 Intel Deutschland GmbH
+ */
+ #include <linux/vmalloc.h>
++#include <linux/err.h>
+ #include <linux/ieee80211.h>
+ #include <linux/netdevice.h>
+
+@@ -1849,7 +1850,6 @@ void iwl_mvm_sta_add_debugfs(struct ieee
+ void iwl_mvm_dbgfs_register(struct iwl_mvm *mvm)
+ {
+ struct dentry *bcast_dir __maybe_unused;
+- char buf[100];
+
+ spin_lock_init(&mvm->drv_stats_lock);
+
+@@ -1930,6 +1930,11 @@ void iwl_mvm_dbgfs_register(struct iwl_m
+ * Create a symlink with mac80211. It will be removed when mac80211
+ * exists (before the opmode exists which removes the target.)
+ */
+- snprintf(buf, 100, "../../%pd2", mvm->debugfs_dir->d_parent);
+- debugfs_create_symlink("iwlwifi", mvm->hw->wiphy->debugfsdir, buf);
++ if (!IS_ERR(mvm->debugfs_dir)) {
++ char buf[100];
++
++ snprintf(buf, 100, "../../%pd2", mvm->debugfs_dir->d_parent);
++ debugfs_create_symlink("iwlwifi", mvm->hw->wiphy->debugfsdir,
++ buf);
++ }
+ }
--- /dev/null
+From 610d086d6df0b15c3732a7b4a5b0f1c3e1b84d4c Mon Sep 17 00:00:00 2001
+From: Deren Wu <deren.wu@mediatek.com>
+Date: Sun, 13 Feb 2022 00:20:15 +0800
+Subject: mac80211: fix EAPoL rekey fail in 802.3 rx path
+
+From: Deren Wu <deren.wu@mediatek.com>
+
+commit 610d086d6df0b15c3732a7b4a5b0f1c3e1b84d4c upstream.
+
+mac80211 set capability NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211
+to upper layer by default. That means we should pass EAPoL packets through
+nl80211 path only, and should not send the EAPoL skb to netdevice diretly.
+At the meanwhile, wpa_supplicant would not register sock to listen EAPoL
+skb on the netdevice.
+
+However, there is no control_port_protocol handler in mac80211 for 802.3 RX
+packets, mac80211 driver would pass up the EAPoL rekey frame to netdevice
+and wpa_supplicant would be never interactive with this kind of packets,
+if SUPPORTS_RX_DECAP_OFFLOAD is enabled. This causes STA always rekey fail
+if EAPoL frame go through 802.3 path.
+
+To avoid this problem, align the same process as 802.11 type to handle
+this frame before put it into network stack.
+
+This also addresses a potential security issue in 802.3 RX mode that was
+previously fixed in commit a8c4d76a8dd4 ("mac80211: do not accept/forward
+invalid EAPOL frames").
+
+Cc: stable@vger.kernel.org # 5.12+
+Fixes: 80a915ec4427 ("mac80211: add rx decapsulation offload support")
+Signed-off-by: Deren Wu <deren.wu@mediatek.com>
+Link: https://lore.kernel.org/r/6889c9fced5859ebb088564035f84fd0fa792a49.1644680751.git.deren.wu@mediatek.com
+[fix typos, update comment and add note about security issue]
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mac80211/rx.c | 10 +++-------
+ 1 file changed, 3 insertions(+), 7 deletions(-)
+
+--- a/net/mac80211/rx.c
++++ b/net/mac80211/rx.c
+@@ -2602,7 +2602,8 @@ static void ieee80211_deliver_skb_to_loc
+ * address, so that the authenticator (e.g. hostapd) will see
+ * the frame, but bridge won't forward it anywhere else. Note
+ * that due to earlier filtering, the only other address can
+- * be the PAE group address.
++ * be the PAE group address, unless the hardware allowed them
++ * through in 802.3 offloaded mode.
+ */
+ if (unlikely(skb->protocol == sdata->control_port_protocol &&
+ !ether_addr_equal(ehdr->h_dest, sdata->vif.addr)))
+@@ -4509,12 +4510,7 @@ static void ieee80211_rx_8023(struct iee
+
+ /* deliver to local stack */
+ skb->protocol = eth_type_trans(skb, fast_rx->dev);
+- memset(skb->cb, 0, sizeof(skb->cb));
+- if (rx->list)
+- list_add_tail(&skb->list, rx->list);
+- else
+- netif_receive_skb(skb);
+-
++ ieee80211_deliver_skb_to_local_stack(skb, rx);
+ }
+
+ static bool ieee80211_invoke_fast_rx(struct ieee80211_rx_data *rx,
--- /dev/null
+From d5081bf5dcfb1cb83fb538708b0ac07a10a79cc4 Mon Sep 17 00:00:00 2001
+From: Dave Jiang <dave.jiang@intel.com>
+Date: Thu, 27 Jan 2022 13:31:12 -0700
+Subject: ntb: intel: fix port config status offset for SPR
+
+From: Dave Jiang <dave.jiang@intel.com>
+
+commit d5081bf5dcfb1cb83fb538708b0ac07a10a79cc4 upstream.
+
+The field offset for port configuration status on SPR has been changed to
+bit 14 from ICX where it resides at bit 12. By chance link status detection
+continued to work on SPR. This is due to bit 12 being a configuration bit
+which is in sync with the status bit. Fix this by checking for a SPR device
+and checking correct status bit.
+
+Fixes: 26bfe3d0b227 ("ntb: intel: Add Icelake (gen4) support for Intel NTB")
+Tested-by: Jerry Dai <jerry.dai@intel.com>
+Signed-off-by: Dave Jiang <dave.jiang@intel.com>
+Signed-off-by: Jon Mason <jdmason@kudzu.us>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ntb/hw/intel/ntb_hw_gen4.c | 17 ++++++++++++++++-
+ drivers/ntb/hw/intel/ntb_hw_gen4.h | 16 ++++++++++++++++
+ 2 files changed, 32 insertions(+), 1 deletion(-)
+
+--- a/drivers/ntb/hw/intel/ntb_hw_gen4.c
++++ b/drivers/ntb/hw/intel/ntb_hw_gen4.c
+@@ -168,6 +168,18 @@ static enum ntb_topo gen4_ppd_topo(struc
+ return NTB_TOPO_NONE;
+ }
+
++static enum ntb_topo spr_ppd_topo(struct intel_ntb_dev *ndev, u32 ppd)
++{
++ switch (ppd & SPR_PPD_TOPO_MASK) {
++ case SPR_PPD_TOPO_B2B_USD:
++ return NTB_TOPO_B2B_USD;
++ case SPR_PPD_TOPO_B2B_DSD:
++ return NTB_TOPO_B2B_DSD;
++ }
++
++ return NTB_TOPO_NONE;
++}
++
+ int gen4_init_dev(struct intel_ntb_dev *ndev)
+ {
+ struct pci_dev *pdev = ndev->ntb.pdev;
+@@ -183,7 +195,10 @@ int gen4_init_dev(struct intel_ntb_dev *
+ }
+
+ ppd1 = ioread32(ndev->self_mmio + GEN4_PPD1_OFFSET);
+- ndev->ntb.topo = gen4_ppd_topo(ndev, ppd1);
++ if (pdev_is_ICX(pdev))
++ ndev->ntb.topo = gen4_ppd_topo(ndev, ppd1);
++ else if (pdev_is_SPR(pdev))
++ ndev->ntb.topo = spr_ppd_topo(ndev, ppd1);
+ dev_dbg(&pdev->dev, "ppd %#x topo %s\n", ppd1,
+ ntb_topo_string(ndev->ntb.topo));
+ if (ndev->ntb.topo == NTB_TOPO_NONE)
+--- a/drivers/ntb/hw/intel/ntb_hw_gen4.h
++++ b/drivers/ntb/hw/intel/ntb_hw_gen4.h
+@@ -49,10 +49,14 @@
+ #define GEN4_PPD_CLEAR_TRN 0x0001
+ #define GEN4_PPD_LINKTRN 0x0008
+ #define GEN4_PPD_CONN_MASK 0x0300
++#define SPR_PPD_CONN_MASK 0x0700
+ #define GEN4_PPD_CONN_B2B 0x0200
+ #define GEN4_PPD_DEV_MASK 0x1000
+ #define GEN4_PPD_DEV_DSD 0x1000
+ #define GEN4_PPD_DEV_USD 0x0000
++#define SPR_PPD_DEV_MASK 0x4000
++#define SPR_PPD_DEV_DSD 0x4000
++#define SPR_PPD_DEV_USD 0x0000
+ #define GEN4_LINK_CTRL_LINK_DISABLE 0x0010
+
+ #define GEN4_SLOTSTS 0xb05a
+@@ -62,6 +66,10 @@
+ #define GEN4_PPD_TOPO_B2B_USD (GEN4_PPD_CONN_B2B | GEN4_PPD_DEV_USD)
+ #define GEN4_PPD_TOPO_B2B_DSD (GEN4_PPD_CONN_B2B | GEN4_PPD_DEV_DSD)
+
++#define SPR_PPD_TOPO_MASK (SPR_PPD_CONN_MASK | SPR_PPD_DEV_MASK)
++#define SPR_PPD_TOPO_B2B_USD (GEN4_PPD_CONN_B2B | SPR_PPD_DEV_USD)
++#define SPR_PPD_TOPO_B2B_DSD (GEN4_PPD_CONN_B2B | SPR_PPD_DEV_DSD)
++
+ #define GEN4_DB_COUNT 32
+ #define GEN4_DB_LINK 32
+ #define GEN4_DB_LINK_BIT BIT_ULL(GEN4_DB_LINK)
+@@ -111,5 +119,13 @@ static inline int pdev_is_ICX(struct pci
+ return 1;
+ return 0;
+ }
++
++static inline int pdev_is_SPR(struct pci_dev *pdev)
++{
++ if (pdev_is_gen4(pdev) &&
++ pdev->revision > PCI_DEVICE_REVISION_ICX_MAX)
++ return 1;
++ return 0;
++}
+
+ #endif
--- /dev/null
+From dcf0c838854c86e1f41fb1934aea906845d69782 Mon Sep 17 00:00:00 2001
+From: Sunil V L <sunilvl@ventanamicro.com>
+Date: Fri, 28 Jan 2022 10:20:04 +0530
+Subject: riscv/efi_stub: Fix get_boot_hartid_from_fdt() return value
+
+From: Sunil V L <sunilvl@ventanamicro.com>
+
+commit dcf0c838854c86e1f41fb1934aea906845d69782 upstream.
+
+The get_boot_hartid_from_fdt() function currently returns U32_MAX
+for failure case which is not correct because U32_MAX is a valid
+hartid value. This patch fixes the issue by returning error code.
+
+Cc: <stable@vger.kernel.org>
+Fixes: d7071743db31 ("RISC-V: Add EFI stub support.")
+Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
+Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/efi/libstub/riscv-stub.c | 17 ++++++++++-------
+ 1 file changed, 10 insertions(+), 7 deletions(-)
+
+--- a/drivers/firmware/efi/libstub/riscv-stub.c
++++ b/drivers/firmware/efi/libstub/riscv-stub.c
+@@ -25,7 +25,7 @@ typedef void __noreturn (*jump_kernel_fu
+
+ static u32 hartid;
+
+-static u32 get_boot_hartid_from_fdt(void)
++static int get_boot_hartid_from_fdt(void)
+ {
+ const void *fdt;
+ int chosen_node, len;
+@@ -33,23 +33,26 @@ static u32 get_boot_hartid_from_fdt(void
+
+ fdt = get_efi_config_table(DEVICE_TREE_GUID);
+ if (!fdt)
+- return U32_MAX;
++ return -EINVAL;
+
+ chosen_node = fdt_path_offset(fdt, "/chosen");
+ if (chosen_node < 0)
+- return U32_MAX;
++ return -EINVAL;
+
+ prop = fdt_getprop((void *)fdt, chosen_node, "boot-hartid", &len);
+ if (!prop || len != sizeof(u32))
+- return U32_MAX;
++ return -EINVAL;
+
+- return fdt32_to_cpu(*prop);
++ hartid = fdt32_to_cpu(*prop);
++ return 0;
+ }
+
+ efi_status_t check_platform_features(void)
+ {
+- hartid = get_boot_hartid_from_fdt();
+- if (hartid == U32_MAX) {
++ int ret;
++
++ ret = get_boot_hartid_from_fdt();
++ if (ret) {
+ efi_err("/chosen/boot-hartid missing or invalid!\n");
+ return EFI_UNSUPPORTED;
+ }
--- /dev/null
+From c648c4bb7d02ceb53ee40172fdc4433b37cee9c6 Mon Sep 17 00:00:00 2001
+From: Alexandre Ghiti <alexandre.ghiti@canonical.com>
+Date: Fri, 25 Feb 2022 13:39:51 +0100
+Subject: riscv: Fix config KASAN && DEBUG_VIRTUAL
+
+From: Alexandre Ghiti <alexandre.ghiti@canonical.com>
+
+commit c648c4bb7d02ceb53ee40172fdc4433b37cee9c6 upstream.
+
+__virt_to_phys function is called very early in the boot process (ie
+kasan_early_init) so it should not be instrumented by KASAN otherwise it
+bugs.
+
+Fix this by declaring phys_addr.c as non-kasan instrumentable.
+
+Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
+Fixes: 8ad8b72721d0 (riscv: Add KASAN support)
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/mm/Makefile | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/riscv/mm/Makefile
++++ b/arch/riscv/mm/Makefile
+@@ -24,6 +24,9 @@ obj-$(CONFIG_KASAN) += kasan_init.o
+ ifdef CONFIG_KASAN
+ KASAN_SANITIZE_kasan_init.o := n
+ KASAN_SANITIZE_init.o := n
++ifdef CONFIG_DEBUG_VIRTUAL
++KASAN_SANITIZE_physaddr.o := n
++endif
+ endif
+
+ obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
--- /dev/null
+From a3d328037846d013bb4c7f3777241e190e4c75e1 Mon Sep 17 00:00:00 2001
+From: Alexandre Ghiti <alexandre.ghiti@canonical.com>
+Date: Fri, 25 Feb 2022 13:39:49 +0100
+Subject: riscv: Fix config KASAN && SPARSEMEM && !SPARSE_VMEMMAP
+
+From: Alexandre Ghiti <alexandre.ghiti@canonical.com>
+
+commit a3d328037846d013bb4c7f3777241e190e4c75e1 upstream.
+
+In order to get the pfn of a struct page* when sparsemem is enabled
+without vmemmap, the mem_section structures need to be initialized which
+happens in sparse_init.
+
+But kasan_early_init calls pfn_to_page way before sparse_init is called,
+which then tries to dereference a null mem_section pointer.
+
+Fix this by removing the usage of this function in kasan_early_init.
+
+Fixes: 8ad8b72721d0 ("riscv: Add KASAN support")
+Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/mm/kasan_init.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/arch/riscv/mm/kasan_init.c
++++ b/arch/riscv/mm/kasan_init.c
+@@ -22,8 +22,7 @@ asmlinkage void __init kasan_early_init(
+
+ for (i = 0; i < PTRS_PER_PTE; ++i)
+ set_pte(kasan_early_shadow_pte + i,
+- mk_pte(virt_to_page(kasan_early_shadow_page),
+- PAGE_KERNEL));
++ pfn_pte(virt_to_pfn(kasan_early_shadow_page), PAGE_KERNEL));
+
+ for (i = 0; i < PTRS_PER_PMD; ++i)
+ set_pmd(kasan_early_shadow_pmd + i,
ipv6-fix-skb-drops-in-igmp6_event_query-and-igmp6_ev.patch
btrfs-defrag-bring-back-the-old-file-extent-search-behavior.patch
btrfs-defrag-don-t-use-merged-extent-map-for-their-generation-check.patch
+alsa-intel_hdmi-fix-reference-to-pcm-buffer-address.patch
+ucounts-fix-systemd-limitnproc-with-private-users-regression.patch
+binfmt_elf-avoid-total_mapping_size-for-et_exec.patch
+riscv-efi_stub-fix-get_boot_hartid_from_fdt-return-value.patch
+riscv-fix-config-kasan-sparsemem-sparse_vmemmap.patch
+riscv-fix-config-kasan-debug_virtual.patch
+iwlwifi-mvm-check-debugfs_dir-ptr-before-use.patch
+asoc-ops-shift-tested-values-in-snd_soc_put_volsw-by-min.patch
+iommu-vt-d-fix-double-list_add-when-enabling-vmd-in-scalable-mode.patch
+iommu-amd-recover-from-event-log-overflow.patch
+drm-i915-s-jsp2-icp2-pch.patch
+drm-amd-display-reduce-dmesg-error-to-a-debug-print.patch
+xen-netfront-destroy-queues-before-real_num_tx_queues-is-zeroed.patch
+thermal-core-fix-tz_get_trip-null-pointer-dereference.patch
+mac80211-fix-eapol-rekey-fail-in-802.3-rx-path.patch
+blktrace-fix-use-after-free-for-struct-blk_trace.patch
+ntb-intel-fix-port-config-status-offset-for-spr.patch
--- /dev/null
+From 5838a14832d447990827d85e90afe17e6fb9c175 Mon Sep 17 00:00:00 2001
+From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
+Date: Mon, 28 Feb 2022 12:03:51 +0100
+Subject: thermal: core: Fix TZ_GET_TRIP NULL pointer dereference
+
+From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
+
+commit 5838a14832d447990827d85e90afe17e6fb9c175 upstream.
+
+Do not call get_trip_hyst() from thermal_genl_cmd_tz_get_trip() if
+the thermal zone does not define one.
+
+Fixes: 1ce50e7d408e ("thermal: core: genetlink support for events/cmd/sampling")
+Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
+Cc: 5.10+ <stable@vger.kernel.org> # 5.10+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thermal/thermal_netlink.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/thermal/thermal_netlink.c
++++ b/drivers/thermal/thermal_netlink.c
+@@ -419,11 +419,12 @@ static int thermal_genl_cmd_tz_get_trip(
+ for (i = 0; i < tz->trips; i++) {
+
+ enum thermal_trip_type type;
+- int temp, hyst;
++ int temp, hyst = 0;
+
+ tz->ops->get_trip_type(tz, i, &type);
+ tz->ops->get_trip_temp(tz, i, &temp);
+- tz->ops->get_trip_hyst(tz, i, &hyst);
++ if (tz->ops->get_trip_hyst)
++ tz->ops->get_trip_hyst(tz, i, &hyst);
+
+ if (nla_put_u32(msg, THERMAL_GENL_ATTR_TZ_TRIP_ID, i) ||
+ nla_put_u32(msg, THERMAL_GENL_ATTR_TZ_TRIP_TYPE, type) ||
--- /dev/null
+From 0ac983f512033cb7b5e210c9589768ad25b1e36b Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Thu, 24 Feb 2022 08:32:28 -0600
+Subject: ucounts: Fix systemd LimitNPROC with private users regression
+
+From: Eric W. Biederman <ebiederm@xmission.com>
+
+commit 0ac983f512033cb7b5e210c9589768ad25b1e36b upstream.
+
+Long story short recursively enforcing RLIMIT_NPROC when it is not
+enforced on the process that creates a new user namespace, causes
+currently working code to fail. There is no reason to enforce
+RLIMIT_NPROC recursively when we don't enforce it normally so update
+the code to detect this case.
+
+I would like to simply use capable(CAP_SYS_RESOURCE) to detect when
+RLIMIT_NPROC is not enforced upon the caller. Unfortunately because
+RLIMIT_NPROC is charged and checked for enforcement based upon the
+real uid, using capable() which is euid based is inconsistent with reality.
+Come as close as possible to testing for capable(CAP_SYS_RESOURCE) by
+testing for when the real uid would match the conditions when
+CAP_SYS_RESOURCE would be present if the real uid was the effective
+uid.
+
+Reported-by: Etienne Dechamps <etienne@edechamps.fr>
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=215596
+Link: https://lkml.kernel.org/r/e9589141-cfeb-90cd-2d0e-83a62787239a@edechamps.fr
+Link: https://lkml.kernel.org/r/87sfs8jmpz.fsf_-_@email.froward.int.ebiederm.org
+Cc: stable@vger.kernel.org
+Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/user_namespace.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+--- a/kernel/user_namespace.c
++++ b/kernel/user_namespace.c
+@@ -58,6 +58,18 @@ static void set_cred_user_ns(struct cred
+ cred->user_ns = user_ns;
+ }
+
++static unsigned long enforced_nproc_rlimit(void)
++{
++ unsigned long limit = RLIM_INFINITY;
++
++ /* Is RLIMIT_NPROC currently enforced? */
++ if (!uid_eq(current_uid(), GLOBAL_ROOT_UID) ||
++ (current_user_ns() != &init_user_ns))
++ limit = rlimit(RLIMIT_NPROC);
++
++ return limit;
++}
++
+ /*
+ * Create a new user namespace, deriving the creator from the user in the
+ * passed credentials, and replacing that user with the new root user for the
+@@ -122,7 +134,7 @@ int create_user_ns(struct cred *new)
+ for (i = 0; i < MAX_PER_NAMESPACE_UCOUNTS; i++) {
+ ns->ucount_max[i] = INT_MAX;
+ }
+- set_rlimit_ucount_max(ns, UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC));
++ set_rlimit_ucount_max(ns, UCOUNT_RLIMIT_NPROC, enforced_nproc_rlimit());
+ set_rlimit_ucount_max(ns, UCOUNT_RLIMIT_MSGQUEUE, rlimit(RLIMIT_MSGQUEUE));
+ set_rlimit_ucount_max(ns, UCOUNT_RLIMIT_SIGPENDING, rlimit(RLIMIT_SIGPENDING));
+ set_rlimit_ucount_max(ns, UCOUNT_RLIMIT_MEMLOCK, rlimit(RLIMIT_MEMLOCK));
--- /dev/null
+From dcf4ff7a48e7598e6b10126cc02177abb8ae4f3f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
+ <marmarek@invisiblethingslab.com>
+Date: Wed, 23 Feb 2022 22:19:54 +0100
+Subject: xen/netfront: destroy queues before real_num_tx_queues is zeroed
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
+
+commit dcf4ff7a48e7598e6b10126cc02177abb8ae4f3f upstream.
+
+xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to
+delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5
+("net-sysfs: update the queue counts in the unregistration path"),
+unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two
+facts together means, that xennet_destroy_queues() called from
+xennet_remove() cannot do its job, because it's called after
+unregister_netdev(). This results in kfree-ing queues that are still
+linked in napi, which ultimately crashes:
+
+ BUG: kernel NULL pointer dereference, address: 0000000000000000
+ #PF: supervisor read access in kernel mode
+ #PF: error_code(0x0000) - not-present page
+ PGD 0 P4D 0
+ Oops: 0000 [#1] PREEMPT SMP PTI
+ CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226
+ RIP: 0010:free_netdev+0xa3/0x1a0
+ Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00
+ RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286
+ RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000
+ RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff
+ RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000
+ R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050
+ R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680
+ FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0
+ Call Trace:
+ <TASK>
+ xennet_remove+0x13d/0x300 [xen_netfront]
+ xenbus_dev_remove+0x6d/0xf0
+ __device_release_driver+0x17a/0x240
+ device_release_driver+0x24/0x30
+ bus_remove_device+0xd8/0x140
+ device_del+0x18b/0x410
+ ? _raw_spin_unlock+0x16/0x30
+ ? klist_iter_exit+0x14/0x20
+ ? xenbus_dev_request_and_reply+0x80/0x80
+ device_unregister+0x13/0x60
+ xenbus_dev_changed+0x18e/0x1f0
+ xenwatch_thread+0xc0/0x1a0
+ ? do_wait_intr_irq+0xa0/0xa0
+ kthread+0x16b/0x190
+ ? set_kthread_struct+0x40/0x40
+ ret_from_fork+0x22/0x30
+ </TASK>
+
+Fix this by calling xennet_destroy_queues() from xennet_uninit(),
+when real_num_tx_queues is still available. This ensures that queues are
+destroyed when real_num_tx_queues is set to 0, regardless of how
+unregister_netdev() was called.
+
+Originally reported at
+https://github.com/QubesOS/qubes-issues/issues/7257
+
+Fixes: d7dac083414eb5bb9 ("net-sysfs: update the queue counts in the unregistration path")
+Cc: stable@vger.kernel.org
+Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/xen-netfront.c | 39 +++++++++++++++++++++++----------------
+ 1 file changed, 23 insertions(+), 16 deletions(-)
+
+--- a/drivers/net/xen-netfront.c
++++ b/drivers/net/xen-netfront.c
+@@ -842,6 +842,28 @@ static int xennet_close(struct net_devic
+ return 0;
+ }
+
++static void xennet_destroy_queues(struct netfront_info *info)
++{
++ unsigned int i;
++
++ for (i = 0; i < info->netdev->real_num_tx_queues; i++) {
++ struct netfront_queue *queue = &info->queues[i];
++
++ if (netif_running(info->netdev))
++ napi_disable(&queue->napi);
++ netif_napi_del(&queue->napi);
++ }
++
++ kfree(info->queues);
++ info->queues = NULL;
++}
++
++static void xennet_uninit(struct net_device *dev)
++{
++ struct netfront_info *np = netdev_priv(dev);
++ xennet_destroy_queues(np);
++}
++
+ static void xennet_set_rx_rsp_cons(struct netfront_queue *queue, RING_IDX val)
+ {
+ unsigned long flags;
+@@ -1611,6 +1633,7 @@ static int xennet_xdp(struct net_device
+ }
+
+ static const struct net_device_ops xennet_netdev_ops = {
++ .ndo_uninit = xennet_uninit,
+ .ndo_open = xennet_open,
+ .ndo_stop = xennet_close,
+ .ndo_start_xmit = xennet_start_xmit,
+@@ -2103,22 +2126,6 @@ error:
+ return err;
+ }
+
+-static void xennet_destroy_queues(struct netfront_info *info)
+-{
+- unsigned int i;
+-
+- for (i = 0; i < info->netdev->real_num_tx_queues; i++) {
+- struct netfront_queue *queue = &info->queues[i];
+-
+- if (netif_running(info->netdev))
+- napi_disable(&queue->napi);
+- netif_napi_del(&queue->napi);
+- }
+-
+- kfree(info->queues);
+- info->queues = NULL;
+-}
+-
+
+
+ static int xennet_create_page_pool(struct netfront_queue *queue)
projects / thirdparty / kernel / stable-queue.git / commitdiff
