--- /dev/null
+From 4639c5021029d49fd2f97fa8d74731f167f98919 Mon Sep 17 00:00:00 2001
+From: bo liu <bo.liu@senarytech.com>
+Date: Mon, 5 Feb 2024 09:38:02 +0800
+Subject: ALSA: hda/conexant: Add quirk for SWS JS201D
+
+From: bo liu <bo.liu@senarytech.com>
+
+commit 4639c5021029d49fd2f97fa8d74731f167f98919 upstream.
+
+The SWS JS201D need a different pinconfig from windows driver.
+Add a quirk to use a specific pinconfig to SWS JS201D.
+
+Signed-off-by: bo liu <bo.liu@senarytech.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20240205013802.51907-1-bo.liu@senarytech.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_conexant.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+--- a/sound/pci/hda/patch_conexant.c
++++ b/sound/pci/hda/patch_conexant.c
+@@ -344,6 +344,7 @@ enum {
+ CXT_FIXUP_HP_ZBOOK_MUTE_LED,
+ CXT_FIXUP_HEADSET_MIC,
+ CXT_FIXUP_HP_MIC_NO_PRESENCE,
++ CXT_PINCFG_SWS_JS201D,
+ };
+
+ /* for hda_fixup_thinkpad_acpi() */
+@@ -841,6 +842,17 @@ static const struct hda_pintbl cxt_pincf
+ {}
+ };
+
++/* SuoWoSi/South-holding JS201D with sn6140 */
++static const struct hda_pintbl cxt_pincfg_sws_js201d[] = {
++ { 0x16, 0x03211040 }, /* hp out */
++ { 0x17, 0x91170110 }, /* SPK/Class_D */
++ { 0x18, 0x95a70130 }, /* Internal mic */
++ { 0x19, 0x03a11020 }, /* Headset Mic */
++ { 0x1a, 0x40f001f0 }, /* Not used */
++ { 0x21, 0x40f001f0 }, /* Not used */
++ {}
++};
++
+ static const struct hda_fixup cxt_fixups[] = {
+ [CXT_PINCFG_LENOVO_X200] = {
+ .type = HDA_FIXUP_PINS,
+@@ -996,6 +1008,10 @@ static const struct hda_fixup cxt_fixups
+ .chained = true,
+ .chain_id = CXT_FIXUP_HEADSET_MIC,
+ },
++ [CXT_PINCFG_SWS_JS201D] = {
++ .type = HDA_FIXUP_PINS,
++ .v.pins = cxt_pincfg_sws_js201d,
++ },
+ };
+
+ static const struct snd_pci_quirk cxt5045_fixups[] = {
+@@ -1069,6 +1085,7 @@ static const struct snd_pci_quirk cxt506
+ SND_PCI_QUIRK(0x103c, 0x8457, "HP Z2 G4 mini", CXT_FIXUP_HP_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x103c, 0x8458, "HP Z2 G4 mini premium", CXT_FIXUP_HP_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1043, 0x138d, "Asus", CXT_FIXUP_HEADPHONE_MIC_PIN),
++ SND_PCI_QUIRK(0x14f1, 0x0265, "SWS JS201D", CXT_PINCFG_SWS_JS201D),
+ SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT_FIXUP_OLPC_XO),
+ SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400", CXT_PINCFG_LENOVO_TP410),
+ SND_PCI_QUIRK(0x17aa, 0x215e, "Lenovo T410", CXT_PINCFG_LENOVO_TP410),
+@@ -1109,6 +1126,7 @@ static const struct hda_model_fixup cxt5
+ { .id = CXT_FIXUP_HP_ZBOOK_MUTE_LED, .name = "hp-zbook-mute-led" },
+ { .id = CXT_FIXUP_HP_MIC_NO_PRESENCE, .name = "hp-mic-fix" },
+ { .id = CXT_PINCFG_LENOVO_NOTEBOOK, .name = "lenovo-20149" },
++ { .id = CXT_PINCFG_SWS_JS201D, .name = "sws-js201d" },
+ {}
+ };
+
--- /dev/null
+From 32f03f4002c5df837fb920eb23fcd2f4af9b0b23 Mon Sep 17 00:00:00 2001
+From: Eniac Zhang <eniac-xw.zhang@hp.com>
+Date: Thu, 15 Feb 2024 15:49:22 +0000
+Subject: ALSA: hda/realtek: fix mute/micmute LED For HP mt645
+
+From: Eniac Zhang <eniac-xw.zhang@hp.com>
+
+commit 32f03f4002c5df837fb920eb23fcd2f4af9b0b23 upstream.
+
+The HP mt645 G7 Thin Client uses an ALC236 codec and needs the
+ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to make the mute and
+micmute LEDs work.
+
+There are two variants of the USB-C PD chip on this device. Each uses
+a different BIOS and board ID, hence the two entries.
+
+Signed-off-by: Eniac Zhang <eniac-xw.zhang@hp.com>
+Signed-off-by: Alexandru Gagniuc <alexandru.gagniuc@hp.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20240215154922.778394-1-alexandru.gagniuc@hp.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -9690,6 +9690,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x103c, 0x8abb, "HP ZBook Firefly 14 G9", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8ad1, "HP EliteBook 840 14 inch G9 Notebook PC", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8ad2, "HP EliteBook 860 16 inch G9 Notebook PC", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
++ SND_PCI_QUIRK(0x103c, 0x8b0f, "HP Elite mt645 G7 Mobile Thin Client U81", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8b2f, "HP 255 15.6 inch G10 Notebook PC", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
+ SND_PCI_QUIRK(0x103c, 0x8b42, "HP", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8b43, "HP", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+@@ -9697,6 +9698,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x103c, 0x8b45, "HP", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8b46, "HP", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8b47, "HP", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
++ SND_PCI_QUIRK(0x103c, 0x8b59, "HP Elite mt645 G7 Mobile Thin Client U89", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8b5d, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8b5e, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8b63, "HP Elite Dragonfly 13.5 inch G4", ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED),
--- /dev/null
+From e63e35f0164c43fbc1adb481d6604f253b9f9667 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Mon, 5 Feb 2024 14:54:05 -0700
+Subject: drm/amd/display: Increase frame-larger-than for all display_mode_vba files
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit e63e35f0164c43fbc1adb481d6604f253b9f9667 upstream.
+
+After a recent change in LLVM, allmodconfig (which has CONFIG_KCSAN=y
+and CONFIG_WERROR=y enabled) has a few new instances of
+-Wframe-larger-than for the mode support and system configuration
+functions:
+
+ drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20v2.c:3393:6: error: stack frame size (2144) exceeds limit (2048) in 'dml20v2_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
+ 3393 | void dml20v2_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
+ | ^
+ 1 error generated.
+
+ drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:3520:6: error: stack frame size (2192) exceeds limit (2048) in 'dml21_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
+ 3520 | void dml21_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
+ | ^
+ 1 error generated.
+
+ drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3286:6: error: stack frame size (2128) exceeds limit (2048) in 'dml20_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
+ 3286 | void dml20_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
+ | ^
+ 1 error generated.
+
+Without the sanitizers enabled, there are no warnings.
+
+This was the catalyst for commit 6740ec97bcdb ("drm/amd/display:
+Increase frame warning limit with KASAN or KCSAN in dml2") and that same
+change was made to dml in commit 5b750b22530f ("drm/amd/display:
+Increase frame warning limit with KASAN or KCSAN in dml") but the
+frame_warn_flag variable was not applied to all files. Do so now to
+clear up the warnings and make all these files consistent.
+
+Cc: stable@vger.kernel.org
+Closes: https://github.com/ClangBuiltLinux/linux/issue/1990
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/dml/Makefile | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
++++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
+@@ -60,11 +60,11 @@ ifdef CONFIG_DRM_AMD_DC_DCN
+ CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_ccflags)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn10/dcn10_fpu.o := $(dml_ccflags)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/dcn20_fpu.o := $(dml_ccflags)
+-CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags)
++CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags) $(frame_warn_flag)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20.o := $(dml_ccflags)
+-CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags)
++CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags) $(frame_warn_flag)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o := $(dml_ccflags)
+-CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags)
++CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags) $(frame_warn_flag)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_rq_dlg_calc_21.o := $(dml_ccflags)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) $(frame_warn_flag)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_rq_dlg_calc_30.o := $(dml_ccflags)
--- /dev/null
+From deb110292180cd501f6fde2a0178d65fcbcabb0c Mon Sep 17 00:00:00 2001
+From: Tom Chung <chiahsuan.chung@amd.com>
+Date: Tue, 30 Jan 2024 15:34:08 +0800
+Subject: drm/amd/display: Preserve original aspect ratio in create stream
+
+From: Tom Chung <chiahsuan.chung@amd.com>
+
+commit deb110292180cd501f6fde2a0178d65fcbcabb0c upstream.
+
+[Why]
+The original picture aspect ratio in mode struct may have chance be
+overwritten with wrong aspect ratio data in create_stream_for_sink().
+It will create a different VIC output and cause HDMI compliance test
+failed.
+
+[How]
+Preserve the original picture aspect ratio data during create the
+stream.
+
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
+Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -6001,7 +6001,9 @@ create_stream_for_sink(struct amdgpu_dm_
+ if (recalculate_timing) {
+ freesync_mode = get_highest_refresh_rate_mode(aconnector, false);
+ drm_mode_copy(&saved_mode, &mode);
++ saved_mode.picture_aspect_ratio = mode.picture_aspect_ratio;
+ drm_mode_copy(&mode, freesync_mode);
++ mode.picture_aspect_ratio = saved_mode.picture_aspect_ratio;
+ } else {
+ decide_crtc_timing_for_drm_display_mode(
+ &mode, preferred_mode, scale);
--- /dev/null
+From 8c7bfd8262319fd3f127a5380f593ea76f1b88a2 Mon Sep 17 00:00:00 2001
+From: Rob Clark <robdclark@chromium.org>
+Date: Tue, 13 Feb 2024 09:23:40 -0800
+Subject: drm/msm: Wire up tlb ops
+
+From: Rob Clark <robdclark@chromium.org>
+
+commit 8c7bfd8262319fd3f127a5380f593ea76f1b88a2 upstream.
+
+The brute force iommu_flush_iotlb_all() was good enough for unmap, but
+in some cases a map operation could require removing a table pte entry
+to replace with a block entry. This also requires tlb invalidation.
+Missing this was resulting an obscure iova fault on what should be a
+valid buffer address.
+
+Thanks to Robin Murphy for helping me understand the cause of the fault.
+
+Cc: Robin Murphy <robin.murphy@arm.com>
+Cc: stable@vger.kernel.org
+Fixes: b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
+Signed-off-by: Rob Clark <robdclark@chromium.org>
+Patchwork: https://patchwork.freedesktop.org/patch/578117/
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/msm/msm_iommu.c | 32 +++++++++++++++++++++++++++++---
+ 1 file changed, 29 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/msm/msm_iommu.c
++++ b/drivers/gpu/drm/msm/msm_iommu.c
+@@ -21,6 +21,8 @@ struct msm_iommu_pagetable {
+ struct msm_mmu base;
+ struct msm_mmu *parent;
+ struct io_pgtable_ops *pgtbl_ops;
++ const struct iommu_flush_ops *tlb;
++ struct device *iommu_dev;
+ unsigned long pgsize_bitmap; /* Bitmap of page sizes in use */
+ phys_addr_t ttbr;
+ u32 asid;
+@@ -194,11 +196,33 @@ static const struct msm_mmu_funcs pageta
+
+ static void msm_iommu_tlb_flush_all(void *cookie)
+ {
++ struct msm_iommu_pagetable *pagetable = cookie;
++ struct adreno_smmu_priv *adreno_smmu;
++
++ if (!pm_runtime_get_if_in_use(pagetable->iommu_dev))
++ return;
++
++ adreno_smmu = dev_get_drvdata(pagetable->parent->dev);
++
++ pagetable->tlb->tlb_flush_all((void *)adreno_smmu->cookie);
++
++ pm_runtime_put_autosuspend(pagetable->iommu_dev);
+ }
+
+ static void msm_iommu_tlb_flush_walk(unsigned long iova, size_t size,
+ size_t granule, void *cookie)
+ {
++ struct msm_iommu_pagetable *pagetable = cookie;
++ struct adreno_smmu_priv *adreno_smmu;
++
++ if (!pm_runtime_get_if_in_use(pagetable->iommu_dev))
++ return;
++
++ adreno_smmu = dev_get_drvdata(pagetable->parent->dev);
++
++ pagetable->tlb->tlb_flush_walk(iova, size, granule, (void *)adreno_smmu->cookie);
++
++ pm_runtime_put_autosuspend(pagetable->iommu_dev);
+ }
+
+ static void msm_iommu_tlb_add_page(struct iommu_iotlb_gather *gather,
+@@ -206,7 +230,7 @@ static void msm_iommu_tlb_add_page(struc
+ {
+ }
+
+-static const struct iommu_flush_ops null_tlb_ops = {
++static const struct iommu_flush_ops tlb_ops = {
+ .tlb_flush_all = msm_iommu_tlb_flush_all,
+ .tlb_flush_walk = msm_iommu_tlb_flush_walk,
+ .tlb_add_page = msm_iommu_tlb_add_page,
+@@ -254,10 +278,10 @@ struct msm_mmu *msm_iommu_pagetable_crea
+
+ /* The incoming cfg will have the TTBR1 quirk enabled */
+ ttbr0_cfg.quirks &= ~IO_PGTABLE_QUIRK_ARM_TTBR1;
+- ttbr0_cfg.tlb = &null_tlb_ops;
++ ttbr0_cfg.tlb = &tlb_ops;
+
+ pagetable->pgtbl_ops = alloc_io_pgtable_ops(ARM_64_LPAE_S1,
+- &ttbr0_cfg, iommu->domain);
++ &ttbr0_cfg, pagetable);
+
+ if (!pagetable->pgtbl_ops) {
+ kfree(pagetable);
+@@ -282,6 +306,8 @@ struct msm_mmu *msm_iommu_pagetable_crea
+
+ /* Needed later for TLB flush */
+ pagetable->parent = parent;
++ pagetable->tlb = ttbr1_cfg->tlb;
++ pagetable->iommu_dev = ttbr1_cfg->iommu_dev;
+ pagetable->pgsize_bitmap = ttbr0_cfg.pgsize_bitmap;
+ pagetable->ttbr = ttbr0_cfg.arm_lpae_s1_cfg.ttbr;
+
--- /dev/null
+From b671cd3d456315f63171a670769356a196cf7fd0 Mon Sep 17 00:00:00 2001
+From: Philip Yang <Philip.Yang@amd.com>
+Date: Mon, 21 Aug 2023 16:02:01 -0400
+Subject: drm/prime: Support page array >= 4GB
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Philip Yang <Philip.Yang@amd.com>
+
+commit b671cd3d456315f63171a670769356a196cf7fd0 upstream.
+
+Without unsigned long typecast, the size is passed in as zero if page
+array size >= 4GB, nr_pages >= 0x100000, then sg list converted will
+have the first and the last chunk lost.
+
+Signed-off-by: Philip Yang <Philip.Yang@amd.com>
+Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+CC: stable@vger.kernel.org
+Signed-off-by: Christian König <christian.koenig@amd.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230821200201.24685-1-Philip.Yang@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_prime.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/drm_prime.c
++++ b/drivers/gpu/drm/drm_prime.c
+@@ -828,7 +828,7 @@ struct sg_table *drm_prime_pages_to_sg(s
+ if (max_segment == 0)
+ max_segment = UINT_MAX;
+ err = sg_alloc_table_from_pages_segment(sg, pages, nr_pages, 0,
+- nr_pages << PAGE_SHIFT,
++ (unsigned long)nr_pages << PAGE_SHIFT,
+ max_segment, GFP_KERNEL);
+ if (err) {
+ kfree(sg);
--- /dev/null
+From e0526ec5360a48ad3ab2e26e802b0532302a7e11 Mon Sep 17 00:00:00 2001
+From: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
+Date: Tue, 30 Jan 2024 23:35:51 -0800
+Subject: hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
+
+From: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
+
+commit e0526ec5360a48ad3ab2e26e802b0532302a7e11 upstream.
+
+In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the
+VMBus channel"), napi_disable was getting called for all channels,
+including all subchannels without confirming if they are enabled or not.
+
+This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
+has finished running but nvdev->subchan_work has not started yet.
+netvsc_subchan_work() -> rndis_set_subchannel() has not created the
+sub-channels and because of that netvsc_sc_open() is not running.
+netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which
+netvsc_subchan_work did not run.
+
+netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
+cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the
+NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
+opposite.
+
+Now during netvsc_device_remove(), when napi_disable is called for those
+subchannels, napi_disable gets stuck on infinite msleep.
+
+This fix addresses this problem by ensuring that napi_disable() is not
+getting called for non-enabled NAPI struct.
+But netif_napi_del() is still necessary for these non-enabled NAPI struct
+for cleanup purpose.
+
+Call trace:
+[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002
+[ 654.568030] Call Trace:
+[ 654.571221] <TASK>
+[ 654.573790] __schedule+0x2d6/0x960
+[ 654.577733] schedule+0x69/0xf0
+[ 654.581214] schedule_timeout+0x87/0x140
+[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20
+[ 654.590291] msleep+0x2d/0x40
+[ 654.593625] napi_disable+0x2b/0x80
+[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
+[ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
+[ 654.611101] ? do_wait_intr+0xb0/0xb0
+[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc]
+[ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]
+
+Cc: stable@vger.kernel.org
+Fixes: ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel")
+Signed-off-by: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
+Reviewed-by: Dexuan Cui <decui@microsoft.com>
+Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://lore.kernel.org/r/1706686551-28510-1-git-send-email-schakrabarti@linux.microsoft.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/hyperv/netvsc.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/hyperv/netvsc.c
++++ b/drivers/net/hyperv/netvsc.c
+@@ -740,7 +740,10 @@ void netvsc_device_remove(struct hv_devi
+ /* Disable NAPI and disassociate its context from the device. */
+ for (i = 0; i < net_device->num_chn; i++) {
+ /* See also vmbus_reset_channel_cb(). */
+- napi_disable(&net_device->chan_table[i].napi);
++ /* only disable enabled NAPI channel */
++ if (i < ndev->real_num_rx_queues)
++ napi_disable(&net_device->chan_table[i].napi);
++
+ netif_napi_del(&net_device->chan_table[i].napi);
+ }
+
--- /dev/null
+From a37ee9e117ef73bbc2f5c0b31911afd52d229861 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Wed, 14 Feb 2024 08:23:05 -0700
+Subject: io_uring/net: fix multishot accept overflow handling
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit a37ee9e117ef73bbc2f5c0b31911afd52d229861 upstream.
+
+If we hit CQ ring overflow when attempting to post a multishot accept
+completion, we don't properly save the result or return code. This
+results in losing the accepted fd value.
+
+Instead, we return the result from the poll operation that triggered
+the accept retry. This is generally POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND
+which is 0xc3, or 195, which looks like a valid file descriptor, but it
+really has no connection to that.
+
+Handle this like we do for other multishot completions - assign the
+result, and return IOU_STOP_MULTISHOT to cancel any further completions
+from this request when overflow is hit. This preserves the result, as we
+should, and tells the application that the request needs to be re-armed.
+
+Cc: stable@vger.kernel.org
+Fixes: 515e26961295 ("io_uring: revert "io_uring fix multishot accept ordering"")
+Link: https://github.com/axboe/liburing/issues/1062
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/net.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/io_uring/net.c
++++ b/io_uring/net.c
+@@ -1326,7 +1326,7 @@ retry:
+ * has already been done
+ */
+ if (issue_flags & IO_URING_F_MULTISHOT)
+- ret = IOU_ISSUE_SKIP_COMPLETE;
++ return IOU_ISSUE_SKIP_COMPLETE;
+ return ret;
+ }
+ if (ret == -ERESTARTSYS)
+@@ -1350,7 +1350,8 @@ retry:
+ if (io_post_aux_cqe(ctx, req->cqe.user_data, ret, IORING_CQE_F_MORE, false))
+ goto retry;
+
+- return -ECANCELED;
++ io_req_set_res(req, ret, 0);
++ return IOU_STOP_MULTISHOT;
+ }
+
+ int io_socket_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
--- /dev/null
+From 108a020c64434fed4b69762879d78cd24088b4c7 Mon Sep 17 00:00:00 2001
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+Date: Mon, 5 Feb 2024 14:19:16 +0300
+Subject: ksmbd: free aux buffer if ksmbd_iov_pin_rsp_read fails
+
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+
+commit 108a020c64434fed4b69762879d78cd24088b4c7 upstream.
+
+ksmbd_iov_pin_rsp_read() doesn't free the provided aux buffer if it
+fails. Seems to be the caller's responsibility to clear the buffer in
+error case.
+
+Found by Linux Verification Center (linuxtesting.org).
+
+Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound")
+Cc: stable@vger.kernel.org
+Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
+Acked-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/server/smb2pdu.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/fs/smb/server/smb2pdu.c
++++ b/fs/smb/server/smb2pdu.c
+@@ -6171,8 +6171,10 @@ static noinline int smb2_read_pipe(struc
+ err = ksmbd_iov_pin_rsp_read(work, (void *)rsp,
+ offsetof(struct smb2_read_rsp, Buffer),
+ aux_payload_buf, nbytes);
+- if (err)
++ if (err) {
++ kvfree(aux_payload_buf);
+ goto out;
++ }
+ kvfree(rpc_resp);
+ } else {
+ err = ksmbd_iov_pin_rsp(work, (void *)rsp,
+@@ -6382,8 +6384,10 @@ int smb2_read(struct ksmbd_work *work)
+ err = ksmbd_iov_pin_rsp_read(work, (void *)rsp,
+ offsetof(struct smb2_read_rsp, Buffer),
+ aux_payload_buf, nbytes);
+- if (err)
++ if (err) {
++ kvfree(aux_payload_buf);
+ goto out;
++ }
+ ksmbd_fd_put(work, fp);
+ return 0;
+
--- /dev/null
+From 05519c86d6997cfb9bb6c82ce1595d1015b718dc Mon Sep 17 00:00:00 2001
+From: Mingwei Zhang <mizhang@google.com>
+Date: Tue, 23 Jan 2024 22:12:20 +0000
+Subject: KVM: x86/pmu: Fix type length error when reading pmu->fixed_ctr_ctrl
+
+From: Mingwei Zhang <mizhang@google.com>
+
+commit 05519c86d6997cfb9bb6c82ce1595d1015b718dc upstream.
+
+Use a u64 instead of a u8 when taking a snapshot of pmu->fixed_ctr_ctrl
+when reprogramming fixed counters, as truncating the value results in KVM
+thinking fixed counter 2 is already disabled (the bug also affects fixed
+counters 3+, but KVM doesn't yet support those). As a result, if the
+guest disables fixed counter 2, KVM will get a false negative and fail to
+reprogram/disable emulation of the counter, which can leads to incorrect
+counts and spurious PMIs in the guest.
+
+Fixes: 76d287b2342e ("KVM: x86/pmu: Drop "u8 ctrl, int idx" for reprogram_fixed_counter()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mingwei Zhang <mizhang@google.com>
+Link: https://lore.kernel.org/r/20240123221220.3911317-1-mizhang@google.com
+[sean: rewrite changelog to call out the effects of the bug]
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/pmu_intel.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/vmx/pmu_intel.c
++++ b/arch/x86/kvm/vmx/pmu_intel.c
+@@ -38,7 +38,7 @@ static int fixed_pmc_events[] = {1, 0, 7
+ static void reprogram_fixed_counters(struct kvm_pmu *pmu, u64 data)
+ {
+ struct kvm_pmc *pmc;
+- u8 old_fixed_ctr_ctrl = pmu->fixed_ctr_ctrl;
++ u64 old_fixed_ctr_ctrl = pmu->fixed_ctr_ctrl;
+ int i;
+
+ pmu->fixed_ctr_ctrl = data;
--- /dev/null
+From cc9432c4fb159a3913e0ce3173b8218cd5bad2e0 Mon Sep 17 00:00:00 2001
+From: Alexander Stein <alexander.stein@ew.tq-group.com>
+Date: Tue, 6 Feb 2024 09:39:12 +0100
+Subject: mmc: slot-gpio: Allow non-sleeping GPIO ro
+
+From: Alexander Stein <alexander.stein@ew.tq-group.com>
+
+commit cc9432c4fb159a3913e0ce3173b8218cd5bad2e0 upstream.
+
+This change uses the appropriate _cansleep or non-sleeping API for
+reading GPIO read-only state. This allows users with GPIOs that
+never sleepbeing called in atomic context.
+
+Implement the same mechanism as in commit 52af318c93e97 ("mmc: Allow
+non-sleeping GPIO cd").
+
+Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240206083912.2543142-1-alexander.stein@ew.tq-group.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/core/slot-gpio.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/core/slot-gpio.c
++++ b/drivers/mmc/core/slot-gpio.c
+@@ -62,11 +62,15 @@ int mmc_gpio_alloc(struct mmc_host *host
+ int mmc_gpio_get_ro(struct mmc_host *host)
+ {
+ struct mmc_gpio *ctx = host->slot.handler_priv;
++ int cansleep;
+
+ if (!ctx || !ctx->ro_gpio)
+ return -ENOSYS;
+
+- return gpiod_get_value_cansleep(ctx->ro_gpio);
++ cansleep = gpiod_cansleep(ctx->ro_gpio);
++ return cansleep ?
++ gpiod_get_value_cansleep(ctx->ro_gpio) :
++ gpiod_get_value(ctx->ro_gpio);
+ }
+ EXPORT_SYMBOL(mmc_gpio_get_ro);
+
--- /dev/null
+From 3a007b8009b5f8af021021b7a590a6da0dc4c6e0 Mon Sep 17 00:00:00 2001
+From: Hui Zhou <hui.zhou@corigine.com>
+Date: Wed, 24 Jan 2024 17:19:09 +0200
+Subject: nfp: flower: fix hardware offload for the transfer layer port
+
+From: Hui Zhou <hui.zhou@corigine.com>
+
+commit 3a007b8009b5f8af021021b7a590a6da0dc4c6e0 upstream.
+
+The nfp driver will merge the tp source port and tp destination port
+into one dword which the offset must be zero to do hardware offload.
+However, the mangle action for the tp source port and tp destination
+port is separated for tc ct action. Modify the mangle action for the
+FLOW_ACT_MANGLE_HDR_TYPE_TCP and FLOW_ACT_MANGLE_HDR_TYPE_UDP to
+satisfy the nfp driver offload check for the tp port.
+
+The mangle action provides a 4B value for source, and a 4B value for
+the destination, but only 2B of each contains the useful information.
+For offload the 2B of each is combined into a single 4B word. Since the
+incoming mask for the source is '0xFFFF<mask>' the shift-left will
+throw away the 0xFFFF part. When this gets combined together in the
+offload it will clear the destination field. Fix this by setting the
+lower bits back to 0xFFFF, effectively doing a rotate-left operation on
+the mask.
+
+Fixes: 5cee92c6f57a ("nfp: flower: support hw offload for ct nat action")
+CC: stable@vger.kernel.org # 6.1+
+Signed-off-by: Hui Zhou <hui.zhou@corigine.com>
+Signed-off-by: Louis Peens <louis.peens@corigine.com>
+Link: https://lore.kernel.org/r/20240124151909.31603-3-louis.peens@corigine.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/netronome/nfp/flower/conntrack.c | 24 ++++++++++++++++--
+ 1 file changed, 22 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/netronome/nfp/flower/conntrack.c
++++ b/drivers/net/ethernet/netronome/nfp/flower/conntrack.c
+@@ -1379,10 +1379,30 @@ static void nfp_nft_ct_translate_mangle_
+ mangle_action->mangle.mask = (__force u32)cpu_to_be32(mangle_action->mangle.mask);
+ return;
+
++ /* Both struct tcphdr and struct udphdr start with
++ * __be16 source;
++ * __be16 dest;
++ * so we can use the same code for both.
++ */
+ case FLOW_ACT_MANGLE_HDR_TYPE_TCP:
+ case FLOW_ACT_MANGLE_HDR_TYPE_UDP:
+- mangle_action->mangle.val = (__force u16)cpu_to_be16(mangle_action->mangle.val);
+- mangle_action->mangle.mask = (__force u16)cpu_to_be16(mangle_action->mangle.mask);
++ if (mangle_action->mangle.offset == offsetof(struct tcphdr, source)) {
++ mangle_action->mangle.val =
++ (__force u32)cpu_to_be32(mangle_action->mangle.val << 16);
++ /* The mask of mangle action is inverse mask,
++ * so clear the dest tp port with 0xFFFF to
++ * instead of rotate-left operation.
++ */
++ mangle_action->mangle.mask =
++ (__force u32)cpu_to_be32(mangle_action->mangle.mask << 16 | 0xFFFF);
++ }
++ if (mangle_action->mangle.offset == offsetof(struct tcphdr, dest)) {
++ mangle_action->mangle.offset = 0;
++ mangle_action->mangle.val =
++ (__force u32)cpu_to_be32(mangle_action->mangle.val);
++ mangle_action->mangle.mask =
++ (__force u32)cpu_to_be32(mangle_action->mangle.mask);
++ }
+ return;
+
+ default:
--- /dev/null
+From 67b8bcbaed4777871bb0dcc888fb02a614a98ab1 Mon Sep 17 00:00:00 2001
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Date: Wed, 24 Jan 2024 21:19:36 +0900
+Subject: nilfs2: fix data corruption in dsync block recovery for small block sizes
+
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+
+commit 67b8bcbaed4777871bb0dcc888fb02a614a98ab1 upstream.
+
+The helper function nilfs_recovery_copy_block() of
+nilfs_recovery_dsync_blocks(), which recovers data from logs created by
+data sync writes during a mount after an unclean shutdown, incorrectly
+calculates the on-page offset when copying repair data to the file's page
+cache. In environments where the block size is smaller than the page
+size, this flaw can cause data corruption and leak uninitialized memory
+bytes during the recovery process.
+
+Fix these issues by correcting this byte offset calculation on the page.
+
+Link: https://lkml.kernel.org/r/20240124121936.10575-1-konishi.ryusuke@gmail.com
+Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nilfs2/recovery.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/fs/nilfs2/recovery.c
++++ b/fs/nilfs2/recovery.c
+@@ -472,9 +472,10 @@ static int nilfs_prepare_segment_for_rec
+
+ static int nilfs_recovery_copy_block(struct the_nilfs *nilfs,
+ struct nilfs_recovery_block *rb,
+- struct page *page)
++ loff_t pos, struct page *page)
+ {
+ struct buffer_head *bh_org;
++ size_t from = pos & ~PAGE_MASK;
+ void *kaddr;
+
+ bh_org = __bread(nilfs->ns_bdev, rb->blocknr, nilfs->ns_blocksize);
+@@ -482,7 +483,7 @@ static int nilfs_recovery_copy_block(str
+ return -EIO;
+
+ kaddr = kmap_atomic(page);
+- memcpy(kaddr + bh_offset(bh_org), bh_org->b_data, bh_org->b_size);
++ memcpy(kaddr + from, bh_org->b_data, bh_org->b_size);
+ kunmap_atomic(kaddr);
+ brelse(bh_org);
+ return 0;
+@@ -521,7 +522,7 @@ static int nilfs_recover_dsync_blocks(st
+ goto failed_inode;
+ }
+
+- err = nilfs_recovery_copy_block(nilfs, rb, page);
++ err = nilfs_recovery_copy_block(nilfs, rb, pos, page);
+ if (unlikely(err))
+ goto failed_page;
+
--- /dev/null
+From 38296afe3c6ee07319e01bb249aa4bb47c07b534 Mon Sep 17 00:00:00 2001
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Date: Wed, 31 Jan 2024 23:56:57 +0900
+Subject: nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
+
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+
+commit 38296afe3c6ee07319e01bb249aa4bb47c07b534 upstream.
+
+Syzbot reported a hang issue in migrate_pages_batch() called by mbind()
+and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
+
+While migrate_pages_batch() locks a folio and waits for the writeback to
+complete, the log writer thread that should bring the writeback to
+completion picks up the folio being written back in
+nilfs_lookup_dirty_data_buffers() that it calls for subsequent log
+creation and was trying to lock the folio. Thus causing a deadlock.
+
+In the first place, it is unexpected that folios/pages in the middle of
+writeback will be updated and become dirty. Nilfs2 adds a checksum to
+verify the validity of the log being written and uses it for recovery at
+mount, so data changes during writeback are suppressed. Since this is
+broken, an unclean shutdown could potentially cause recovery to fail.
+
+Investigation revealed that the root cause is that the wait for writeback
+completion in nilfs_page_mkwrite() is conditional, and if the backing
+device does not require stable writes, data may be modified without
+waiting.
+
+Fix these issues by making nilfs_page_mkwrite() wait for writeback to
+finish regardless of the stable write requirement of the backing device.
+
+Link: https://lkml.kernel.org/r/20240131145657.4209-1-konishi.ryusuke@gmail.com
+Fixes: 1d1d1a767206 ("mm: only enforce stable page writes if the backing device requires it")
+Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Reported-by: syzbot+ee2ae68da3b22d04cd8d@syzkaller.appspotmail.com
+Closes: https://lkml.kernel.org/r/00000000000047d819061004ad6c@google.com
+Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nilfs2/file.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/fs/nilfs2/file.c
++++ b/fs/nilfs2/file.c
+@@ -105,7 +105,13 @@ static vm_fault_t nilfs_page_mkwrite(str
+ nilfs_transaction_commit(inode->i_sb);
+
+ mapped:
+- wait_for_stable_page(page);
++ /*
++ * Since checksumming including data blocks is performed to determine
++ * the validity of the log to be written and used for recovery, it is
++ * necessary to wait for writeback to finish here, regardless of the
++ * stable write requirement of the backing device.
++ */
++ wait_on_page_writeback(page);
+ out:
+ sb_end_pagefault(inode->i_sb);
+ return block_page_mkwrite_return(ret);
--- /dev/null
+From aad98efd0b121f63a2e1c221dcb4d4850128c697 Mon Sep 17 00:00:00 2001
+From: Naveen N Rao <naveen@kernel.org>
+Date: Fri, 2 Feb 2024 21:13:16 +0530
+Subject: powerpc/64: Set task pt_regs->link to the LR value on scv entry
+
+From: Naveen N Rao <naveen@kernel.org>
+
+commit aad98efd0b121f63a2e1c221dcb4d4850128c697 upstream.
+
+Nysal reported that userspace backtraces are missing in offcputime bcc
+tool. As an example:
+ $ sudo ./bcc/tools/offcputime.py -uU
+ Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end.
+
+ ^C
+ write
+ - python (9107)
+ 8
+
+ write
+ - sudo (9105)
+ 9
+
+ mmap
+ - python (9107)
+ 16
+
+ clock_nanosleep
+ - multipathd (697)
+ 3001604
+
+The offcputime bcc tool attaches a bpf program to a kprobe on
+finish_task_switch(), which is usually hit on a syscall from userspace.
+With the switch to system call vectored, we started setting
+pt_regs->link to zero. This is because system call vectored behaves like
+a function call with LR pointing to the system call return address, and
+with no modification to SRR0/SRR1. The LR value does indicate our next
+instruction, so it is being saved as pt_regs->nip, and pt_regs->link is
+being set to zero. This is not a problem by itself, but BPF uses perf
+callchain infrastructure for capturing stack traces, and that stores LR
+as the second entry in the stack trace. perf has code to cope with the
+second entry being zero, and skips over it. However, generic userspace
+unwinders assume that a zero entry indicates end of the stack trace,
+resulting in a truncated userspace stack trace.
+
+Rather than fixing all userspace unwinders to ignore/skip past the
+second entry, store the real LR value in pt_regs->link so that there
+continues to be a valid, though duplicate entry in the stack trace.
+
+With this change:
+ $ sudo ./bcc/tools/offcputime.py -uU
+ Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end.
+
+ ^C
+ write
+ write
+ [unknown]
+ [unknown]
+ [unknown]
+ [unknown]
+ [unknown]
+ PyObject_VectorcallMethod
+ [unknown]
+ [unknown]
+ PyObject_CallOneArg
+ PyFile_WriteObject
+ PyFile_WriteString
+ [unknown]
+ [unknown]
+ PyObject_Vectorcall
+ _PyEval_EvalFrameDefault
+ PyEval_EvalCode
+ [unknown]
+ [unknown]
+ [unknown]
+ _PyRun_SimpleFileObject
+ _PyRun_AnyFileObject
+ Py_RunMain
+ [unknown]
+ Py_BytesMain
+ [unknown]
+ __libc_start_main
+ - python (1293)
+ 7
+
+ write
+ write
+ [unknown]
+ sudo_ev_loop_v1
+ sudo_ev_dispatch_v1
+ [unknown]
+ [unknown]
+ [unknown]
+ [unknown]
+ __libc_start_main
+ - sudo (1291)
+ 7
+
+ syscall
+ syscall
+ bpf_open_perf_buffer_opts
+ [unknown]
+ [unknown]
+ [unknown]
+ [unknown]
+ _PyObject_MakeTpCall
+ PyObject_Vectorcall
+ _PyEval_EvalFrameDefault
+ PyEval_EvalCode
+ [unknown]
+ [unknown]
+ [unknown]
+ _PyRun_SimpleFileObject
+ _PyRun_AnyFileObject
+ Py_RunMain
+ [unknown]
+ Py_BytesMain
+ [unknown]
+ __libc_start_main
+ - python (1293)
+ 11
+
+ clock_nanosleep
+ clock_nanosleep
+ nanosleep
+ sleep
+ [unknown]
+ [unknown]
+ __clone
+ - multipathd (698)
+ 3001661
+
+Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions")
+Cc: stable@vger.kernel.org
+Reported-by: "Nysal Jan K.A" <nysal@linux.ibm.com>
+Signed-off-by: Naveen N Rao <naveen@kernel.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://msgid.link/20240202154316.395276-1-naveen@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/kernel/interrupt_64.S | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/kernel/interrupt_64.S
++++ b/arch/powerpc/kernel/interrupt_64.S
+@@ -52,7 +52,8 @@ _ASM_NOKPROBE_SYMBOL(system_call_vectore
+ mr r10,r1
+ ld r1,PACAKSAVE(r13)
+ std r10,0(r1)
+- std r11,_NIP(r1)
++ std r11,_LINK(r1)
++ std r11,_NIP(r1) /* Saved LR is also the next instruction */
+ std r12,_MSR(r1)
+ std r0,GPR0(r1)
+ std r10,GPR1(r1)
+@@ -70,7 +71,6 @@ _ASM_NOKPROBE_SYMBOL(system_call_vectore
+ std r9,GPR13(r1)
+ SAVE_NVGPRS(r1)
+ std r11,_XER(r1)
+- std r11,_LINK(r1)
+ std r11,_CTR(r1)
+
+ li r11,\trapnr
--- /dev/null
+From eb6d871f4ba49ac8d0537e051fe983a3a4027f61 Mon Sep 17 00:00:00 2001
+From: David Engraf <david.engraf@sysgo.com>
+Date: Wed, 7 Feb 2024 10:27:58 +0100
+Subject: powerpc/cputable: Add missing PPC_FEATURE_BOOKE on PPC64 Book-E
+
+From: David Engraf <david.engraf@sysgo.com>
+
+commit eb6d871f4ba49ac8d0537e051fe983a3a4027f61 upstream.
+
+Commit e320a76db4b0 ("powerpc/cputable: Split cpu_specs[] out of
+cputable.h") moved the cpu_specs to separate header files. Previously
+PPC_FEATURE_BOOKE was enabled by CONFIG_PPC_BOOK3E_64. The definition in
+cpu_specs_e500mc.h for PPC64 no longer enables PPC_FEATURE_BOOKE.
+
+This breaks user space reading the ELF hwcaps and expect
+PPC_FEATURE_BOOKE. Debugging an application with gdb is no longer
+working on e5500/e6500 because the 64-bit detection relies on
+PPC_FEATURE_BOOKE for Book-E.
+
+Fixes: e320a76db4b0 ("powerpc/cputable: Split cpu_specs[] out of cputable.h")
+Cc: stable@vger.kernel.org # v6.1+
+Signed-off-by: David Engraf <david.engraf@sysgo.com>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://msgid.link/20240207092758.1058893-1-david.engraf@sysgo.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/kernel/cpu_specs_e500mc.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/kernel/cpu_specs_e500mc.h
++++ b/arch/powerpc/kernel/cpu_specs_e500mc.h
+@@ -8,7 +8,8 @@
+
+ #ifdef CONFIG_PPC64
+ #define COMMON_USER_BOOKE (PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU | \
+- PPC_FEATURE_HAS_FPU | PPC_FEATURE_64)
++ PPC_FEATURE_HAS_FPU | PPC_FEATURE_64 | \
++ PPC_FEATURE_BOOKE)
+ #else
+ #define COMMON_USER_BOOKE (PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU | \
+ PPC_FEATURE_BOOKE)
--- /dev/null
+From cbecc9fcbbec60136b0180ba0609c829afed5c81 Mon Sep 17 00:00:00 2001
+From: Shrikanth Hegde <sshegde@linux.ibm.com>
+Date: Tue, 13 Feb 2024 10:56:35 +0530
+Subject: powerpc/pseries: fix accuracy of stolen time
+
+From: Shrikanth Hegde <sshegde@linux.ibm.com>
+
+commit cbecc9fcbbec60136b0180ba0609c829afed5c81 upstream.
+
+powerVM hypervisor updates the VPA fields with stolen time data.
+It currently reports enqueue_dispatch_tb and ready_enqueue_tb for
+this purpose. In linux these two fields are used to report the stolen time.
+
+The VPA fields are updated at the TB frequency. On powerPC its mostly
+set at 512Mhz. Hence this needs a conversion to ns when reporting it
+back as rest of the kernel timings are in ns. This conversion is already
+handled in tb_to_ns function. So use that function to report accurate
+stolen time.
+
+Observed this issue and used an Capped Shared Processor LPAR(SPLPAR) to
+simplify the experiments. In all these cases, 100% VP Load is run using
+stress-ng workload. Values of stolen time is in percentages as reported
+by mpstat. With the patch values are close to expected.
+
+ 6.8.rc1 +Patch
+12EC/12VP 0.0 0.0
+12EC/24VP 25.7 50.2
+12EC/36VP 37.3 69.2
+12EC/48VP 38.5 78.3
+
+Fixes: 0e8a63132800 ("powerpc/pseries: Implement CONFIG_PARAVIRT_TIME_ACCOUNTING")
+Cc: stable@vger.kernel.org # v6.1+
+Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
+Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
+Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://msgid.link/20240213052635.231597-1-sshegde@linux.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/pseries/lpar.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/platforms/pseries/lpar.c
++++ b/arch/powerpc/platforms/pseries/lpar.c
+@@ -660,8 +660,12 @@ u64 pseries_paravirt_steal_clock(int cpu
+ {
+ struct lppaca *lppaca = &lppaca_of(cpu);
+
+- return be64_to_cpu(READ_ONCE(lppaca->enqueue_dispatch_tb)) +
+- be64_to_cpu(READ_ONCE(lppaca->ready_enqueue_tb));
++ /*
++ * VPA steal time counters are reported at TB frequency. Hence do a
++ * conversion to ns before returning
++ */
++ return tb_to_ns(be64_to_cpu(READ_ONCE(lppaca->enqueue_dispatch_tb)) +
++ be64_to_cpu(READ_ONCE(lppaca->ready_enqueue_tb)));
+ }
+ #endif
+
--- /dev/null
+From 66bbea9ed6446b8471d365a22734dc00556c4785 Mon Sep 17 00:00:00 2001
+From: Vincent Donnefort <vdonnefort@google.com>
+Date: Wed, 31 Jan 2024 14:09:55 +0000
+Subject: ring-buffer: Clean ring_buffer_poll_wait() error return
+
+From: Vincent Donnefort <vdonnefort@google.com>
+
+commit 66bbea9ed6446b8471d365a22734dc00556c4785 upstream.
+
+The return type for ring_buffer_poll_wait() is __poll_t. This is behind
+the scenes an unsigned where we can set event bits. In case of a
+non-allocated CPU, we do return instead -EINVAL (0xffffffea). Lucky us,
+this ends up setting few error bits (EPOLLERR | EPOLLHUP | EPOLLNVAL), so
+user-space at least is aware something went wrong.
+
+Nonetheless, this is an incorrect code. Replace that -EINVAL with a
+proper EPOLLERR to clean that output. As this doesn't change the
+behaviour, there's no need to treat this change as a bug fix.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20240131140955.3322792-1-vdonnefort@google.com
+
+Cc: stable@vger.kernel.org
+Fixes: 6721cb6002262 ("ring-buffer: Do not poll non allocated cpu buffers")
+Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ring_buffer.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -1095,7 +1095,7 @@ __poll_t ring_buffer_poll_wait(struct tr
+ full = 0;
+ } else {
+ if (!cpumask_test_cpu(cpu, buffer->cpumask))
+- return -EINVAL;
++ return EPOLLERR;
+
+ cpu_buffer = buffer->buffers[cpu];
+ work = &cpu_buffer->irq_work;
--- /dev/null
+From 8afa6c6decea37e7cb473d2c60473f37f46cea35 Mon Sep 17 00:00:00 2001
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Date: Tue, 16 Jan 2024 16:30:00 -0500
+Subject: serial: max310x: fail probe if clock crystal is unstable
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+commit 8afa6c6decea37e7cb473d2c60473f37f46cea35 upstream.
+
+A stable clock is really required in order to use this UART, so log an
+error message and bail out if the chip reports that the clock is not
+stable.
+
+Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
+Cc: stable@vger.kernel.org
+Suggested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
+Link: https://www.spinics.net/lists/linux-serial/msg35773.html
+Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Link: https://lore.kernel.org/r/20240116213001.3691629-4-hugo@hugovil.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/max310x.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/tty/serial/max310x.c
++++ b/drivers/tty/serial/max310x.c
+@@ -587,7 +587,7 @@ static int max310x_update_best_err(unsig
+ return 1;
+ }
+
+-static u32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
++static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
+ unsigned long freq, bool xtal)
+ {
+ unsigned int div, clksrc, pllcfg = 0;
+@@ -657,7 +657,8 @@ static u32 max310x_set_ref_clk(struct de
+ } while (!stable && (++try < MAX310X_XTAL_WAIT_RETRIES));
+
+ if (!stable)
+- dev_warn(dev, "clock is not stable yet\n");
++ return dev_err_probe(dev, -EAGAIN,
++ "clock is not stable\n");
+ }
+
+ return bestfreq;
+@@ -1285,7 +1286,7 @@ static int max310x_probe(struct device *
+ {
+ int i, ret, fmin, fmax, freq;
+ struct max310x_port *s;
+- u32 uartclk = 0;
++ s32 uartclk = 0;
+ bool xtal;
+
+ for (i = 0; i < devtype->nr; i++)
+@@ -1363,6 +1364,11 @@ static int max310x_probe(struct device *
+ }
+
+ uartclk = max310x_set_ref_clk(dev, s, freq, xtal);
++ if (uartclk < 0) {
++ ret = uartclk;
++ goto out_uart;
++ }
++
+ dev_dbg(dev, "Reference clock set to %i Hz\n", uartclk);
+
+ for (i = 0; i < devtype->nr; i++) {
--- /dev/null
+From 93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965 Mon Sep 17 00:00:00 2001
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Date: Tue, 16 Jan 2024 16:29:59 -0500
+Subject: serial: max310x: improve crystal stable clock detection
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+commit 93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965 upstream.
+
+Some people are seeing a warning similar to this when using a crystal:
+
+ max310x 11-006c: clock is not stable yet
+
+The datasheet doesn't mention the maximum time to wait for the clock to be
+stable when using a crystal, and it seems that the 10ms delay in the driver
+is not always sufficient.
+
+Jan Kundrát reported that it took three tries (each separated by 10ms) to
+get a stable clock.
+
+Modify behavior to check stable clock ready bit multiple times (20), and
+waiting 10ms between each try.
+
+Note: the first draft of the driver originally used a 50ms delay, without
+checking the clock stable bit.
+Then a loop with 1000 retries was implemented, each time reading the clock
+stable bit.
+
+Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
+Cc: stable@vger.kernel.org
+Suggested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
+Link: https://www.spinics.net/lists/linux-serial/msg35773.html
+Link: https://lore.kernel.org/all/20240110174015.6f20195fde08e5c9e64e5675@hugovil.com/raw
+Link: https://github.com/boundarydevices/linux/commit/e5dfe3e4a751392515d78051973190301a37ca9a
+Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Link: https://lore.kernel.org/r/20240116213001.3691629-3-hugo@hugovil.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/max310x.c | 21 ++++++++++++++++-----
+ 1 file changed, 16 insertions(+), 5 deletions(-)
+
+--- a/drivers/tty/serial/max310x.c
++++ b/drivers/tty/serial/max310x.c
+@@ -237,6 +237,10 @@
+ #define MAX310x_REV_MASK (0xf8)
+ #define MAX310X_WRITE_BIT 0x80
+
++/* Crystal-related definitions */
++#define MAX310X_XTAL_WAIT_RETRIES 20 /* Number of retries */
++#define MAX310X_XTAL_WAIT_DELAY_MS 10 /* Delay between retries */
++
+ /* MAX3107 specific */
+ #define MAX3107_REV_ID (0xa0)
+
+@@ -641,12 +645,19 @@ static u32 max310x_set_ref_clk(struct de
+
+ /* Wait for crystal */
+ if (xtal) {
+- unsigned int val = 0;
+- msleep(10);
+- regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val);
+- if (!(val & MAX310X_STS_CLKREADY_BIT)) {
++ bool stable = false;
++ unsigned int try = 0, val = 0;
++
++ do {
++ msleep(MAX310X_XTAL_WAIT_DELAY_MS);
++ regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val);
++
++ if (val & MAX310X_STS_CLKREADY_BIT)
++ stable = true;
++ } while (!stable && (++try < MAX310X_XTAL_WAIT_RETRIES));
++
++ if (!stable)
+ dev_warn(dev, "clock is not stable yet\n");
+- }
+ }
+
+ return bestfreq;
--- /dev/null
+From b35f8dbbce818b02c730dc85133dc7754266e084 Mon Sep 17 00:00:00 2001
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Date: Tue, 16 Jan 2024 16:30:01 -0500
+Subject: serial: max310x: prevent infinite while() loop in port startup
+
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+commit b35f8dbbce818b02c730dc85133dc7754266e084 upstream.
+
+If there is a problem after resetting a port, the do/while() loop that
+checks the default value of DIVLSB register may run forever and spam the
+I2C bus.
+
+Add a delay before each read of DIVLSB, and a maximum number of tries to
+prevent that situation from happening.
+
+Also fail probe if port reset is unsuccessful.
+
+Fixes: 10d8b34a4217 ("serial: max310x: Driver rework")
+Cc: stable@vger.kernel.org
+Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Link: https://lore.kernel.org/r/20240116213001.3691629-5-hugo@hugovil.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/max310x.c | 20 ++++++++++++++++++--
+ 1 file changed, 18 insertions(+), 2 deletions(-)
+
+--- a/drivers/tty/serial/max310x.c
++++ b/drivers/tty/serial/max310x.c
+@@ -237,6 +237,10 @@
+ #define MAX310x_REV_MASK (0xf8)
+ #define MAX310X_WRITE_BIT 0x80
+
++/* Port startup definitions */
++#define MAX310X_PORT_STARTUP_WAIT_RETRIES 20 /* Number of retries */
++#define MAX310X_PORT_STARTUP_WAIT_DELAY_MS 10 /* Delay between retries */
++
+ /* Crystal-related definitions */
+ #define MAX310X_XTAL_WAIT_RETRIES 20 /* Number of retries */
+ #define MAX310X_XTAL_WAIT_DELAY_MS 10 /* Delay between retries */
+@@ -1349,6 +1353,9 @@ static int max310x_probe(struct device *
+ goto out_clk;
+
+ for (i = 0; i < devtype->nr; i++) {
++ bool started = false;
++ unsigned int try = 0, val = 0;
++
+ /* Reset port */
+ regmap_write(regmaps[i], MAX310X_MODE2_REG,
+ MAX310X_MODE2_RST_BIT);
+@@ -1357,8 +1364,17 @@ static int max310x_probe(struct device *
+
+ /* Wait for port startup */
+ do {
+- regmap_read(regmaps[i], MAX310X_BRGDIVLSB_REG, &ret);
+- } while (ret != 0x01);
++ msleep(MAX310X_PORT_STARTUP_WAIT_DELAY_MS);
++ regmap_read(regmaps[i], MAX310X_BRGDIVLSB_REG, &val);
++
++ if (val == 0x01)
++ started = true;
++ } while (!started && (++try < MAX310X_PORT_STARTUP_WAIT_RETRIES));
++
++ if (!started) {
++ ret = dev_err_probe(dev, -EAGAIN, "port reset failed\n");
++ goto out_uart;
++ }
+
+ regmap_write(regmaps[i], MAX310X_MODE1_REG, devtype->mode1);
+ }
--- /dev/null
+From 0419373333c2f2024966d36261fd82a453281e80 Mon Sep 17 00:00:00 2001
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Date: Tue, 16 Jan 2024 16:29:58 -0500
+Subject: serial: max310x: set default value when reading clock ready bit
+
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+commit 0419373333c2f2024966d36261fd82a453281e80 upstream.
+
+If regmap_read() returns a non-zero value, the 'val' variable can be left
+uninitialized.
+
+Clear it before calling regmap_read() to make sure we properly detect
+the clock ready bit.
+
+Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
+Cc: stable@vger.kernel.org
+Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Link: https://lore.kernel.org/r/20240116213001.3691629-2-hugo@hugovil.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/max310x.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/max310x.c
++++ b/drivers/tty/serial/max310x.c
+@@ -641,7 +641,7 @@ static u32 max310x_set_ref_clk(struct de
+
+ /* Wait for crystal */
+ if (xtal) {
+- unsigned int val;
++ unsigned int val = 0;
+ msleep(10);
+ regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val);
+ if (!(val & MAX310X_STS_CLKREADY_BIT)) {
iio-imu-adis-ensure-proper-dma-alignment.patch
iio-imu-bno055-serdev-requires-regmap.patch
media-rc-bpf-attach-detach-requires-write-permission.patch
+ksmbd-free-aux-buffer-if-ksmbd_iov_pin_rsp_read-fails.patch
+xfrm-remove-inner-outer-modes-from-output-path.patch
+xfrm-remove-inner-outer-modes-from-input-path.patch
+drm-msm-wire-up-tlb-ops.patch
+drm-prime-support-page-array-4gb.patch
+drm-amd-display-increase-frame-larger-than-for-all-display_mode_vba-files.patch
+drm-amd-display-preserve-original-aspect-ratio-in-create-stream.patch
+hv_netvsc-fix-race-condition-between-netvsc_probe-and-netvsc_remove.patch
+ring-buffer-clean-ring_buffer_poll_wait-error-return.patch
+nfp-flower-fix-hardware-offload-for-the-transfer-layer-port.patch
+serial-max310x-set-default-value-when-reading-clock-ready-bit.patch
+serial-max310x-improve-crystal-stable-clock-detection.patch
+serial-max310x-fail-probe-if-clock-crystal-is-unstable.patch
+serial-max310x-prevent-infinite-while-loop-in-port-startup.patch
+powerpc-64-set-task-pt_regs-link-to-the-lr-value-on-scv-entry.patch
+powerpc-cputable-add-missing-ppc_feature_booke-on-ppc64-book-e.patch
+powerpc-pseries-fix-accuracy-of-stolen-time.patch
+x86-kconfig-transmeta-crusoe-is-cpu-family-5-not-6.patch
+x86-fpu-stop-relying-on-userspace-for-info-to-fault-in-xsave-buffer.patch
+kvm-x86-pmu-fix-type-length-error-when-reading-pmu-fixed_ctr_ctrl.patch
+x86-mm-ident_map-use-gbpages-only-where-full-gb-page-should-be-mapped.patch
+io_uring-net-fix-multishot-accept-overflow-handling.patch
+mmc-slot-gpio-allow-non-sleeping-gpio-ro.patch
+alsa-hda-realtek-fix-mute-micmute-led-for-hp-mt645.patch
+alsa-hda-conexant-add-quirk-for-sws-js201d.patch
+nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes.patch
+nilfs2-fix-hang-in-nilfs_lookup_dirty_data_buffers.patch
--- /dev/null
+From d877550eaf2dc9090d782864c96939397a3c6835 Mon Sep 17 00:00:00 2001
+From: Andrei Vagin <avagin@google.com>
+Date: Mon, 29 Jan 2024 22:36:03 -0800
+Subject: x86/fpu: Stop relying on userspace for info to fault in xsave buffer
+
+From: Andrei Vagin <avagin@google.com>
+
+commit d877550eaf2dc9090d782864c96939397a3c6835 upstream.
+
+Before this change, the expected size of the user space buffer was
+taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed
+from user-space, so it is possible construct a sigreturn frame where:
+
+ * fx_sw->xstate_size is smaller than the size required by valid bits in
+ fx_sw->xfeatures.
+ * user-space unmaps parts of the sigrame fpu buffer so that not all of
+ the buffer required by xrstor is accessible.
+
+In this case, xrstor tries to restore and accesses the unmapped area
+which results in a fault. But fault_in_readable succeeds because buf +
+fx_sw->xstate_size is within the still mapped area, so it goes back and
+tries xrstor again. It will spin in this loop forever.
+
+Instead, fault in the maximum size which can be touched by XRSTOR (taken
+from fpstate->user_size).
+
+[ dhansen: tweak subject / changelog ]
+
+Fixes: fcb3635f5018 ("x86/fpu/signal: Handle #PF in the direct restore path")
+Reported-by: Konstantin Bogomolov <bogomolov@google.com>
+Suggested-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Andrei Vagin <avagin@google.com>
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Cc:stable@vger.kernel.org
+Link: https://lore.kernel.org/all/20240130063603.3392627-1-avagin%40google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/fpu/signal.c | 13 +++++--------
+ 1 file changed, 5 insertions(+), 8 deletions(-)
+
+--- a/arch/x86/kernel/fpu/signal.c
++++ b/arch/x86/kernel/fpu/signal.c
+@@ -274,12 +274,13 @@ static int __restore_fpregs_from_user(vo
+ * Attempt to restore the FPU registers directly from user memory.
+ * Pagefaults are handled and any errors returned are fatal.
+ */
+-static bool restore_fpregs_from_user(void __user *buf, u64 xrestore,
+- bool fx_only, unsigned int size)
++static bool restore_fpregs_from_user(void __user *buf, u64 xrestore, bool fx_only)
+ {
+ struct fpu *fpu = ¤t->thread.fpu;
+ int ret;
+
++ /* Restore enabled features only. */
++ xrestore &= fpu->fpstate->user_xfeatures;
+ retry:
+ fpregs_lock();
+ /* Ensure that XFD is up to date */
+@@ -309,7 +310,7 @@ retry:
+ if (ret != X86_TRAP_PF)
+ return false;
+
+- if (!fault_in_readable(buf, size))
++ if (!fault_in_readable(buf, fpu->fpstate->user_size))
+ goto retry;
+ return false;
+ }
+@@ -339,7 +340,6 @@ static bool __fpu_restore_sig(void __use
+ struct user_i387_ia32_struct env;
+ bool success, fx_only = false;
+ union fpregs_state *fpregs;
+- unsigned int state_size;
+ u64 user_xfeatures = 0;
+
+ if (use_xsave()) {
+@@ -349,17 +349,14 @@ static bool __fpu_restore_sig(void __use
+ return false;
+
+ fx_only = !fx_sw_user.magic1;
+- state_size = fx_sw_user.xstate_size;
+ user_xfeatures = fx_sw_user.xfeatures;
+ } else {
+ user_xfeatures = XFEATURE_MASK_FPSSE;
+- state_size = fpu->fpstate->user_size;
+ }
+
+ if (likely(!ia32_fxstate)) {
+ /* Restore the FPU registers directly from user memory. */
+- return restore_fpregs_from_user(buf_fx, user_xfeatures, fx_only,
+- state_size);
++ return restore_fpregs_from_user(buf_fx, user_xfeatures, fx_only);
+ }
+
+ /*
--- /dev/null
+From f6a1892585cd19e63c4ef2334e26cd536d5b678d Mon Sep 17 00:00:00 2001
+From: Aleksander Mazur <deweloper@wp.pl>
+Date: Tue, 23 Jan 2024 14:43:00 +0100
+Subject: x86/Kconfig: Transmeta Crusoe is CPU family 5, not 6
+
+From: Aleksander Mazur <deweloper@wp.pl>
+
+commit f6a1892585cd19e63c4ef2334e26cd536d5b678d upstream.
+
+The kernel built with MCRUSOE is unbootable on Transmeta Crusoe. It shows
+the following error message:
+
+ This kernel requires an i686 CPU, but only detected an i586 CPU.
+ Unable to boot - please use a kernel appropriate for your CPU.
+
+Remove MCRUSOE from the condition introduced in commit in Fixes, effectively
+changing X86_MINIMUM_CPU_FAMILY back to 5 on that machine, which matches the
+CPU family given by CPUID.
+
+ [ bp: Massage commit message. ]
+
+Fixes: 25d76ac88821 ("x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig")
+Signed-off-by: Aleksander Mazur <deweloper@wp.pl>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Acked-by: H. Peter Anvin <hpa@zytor.com>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/r/20240123134309.1117782-1-deweloper@wp.pl
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/Kconfig.cpu | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/Kconfig.cpu
++++ b/arch/x86/Kconfig.cpu
+@@ -375,7 +375,7 @@ config X86_CMOV
+ config X86_MINIMUM_CPU_FAMILY
+ int
+ default "64" if X86_64
+- default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCRUSOE || MCORE2 || MK7 || MK8)
++ default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCORE2 || MK7 || MK8)
+ default "5" if X86_32 && X86_CMPXCHG64
+ default "4"
+
--- /dev/null
+From d794734c9bbfe22f86686dc2909c25f5ffe1a572 Mon Sep 17 00:00:00 2001
+From: Steve Wahl <steve.wahl@hpe.com>
+Date: Fri, 26 Jan 2024 10:48:41 -0600
+Subject: x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
+
+From: Steve Wahl <steve.wahl@hpe.com>
+
+commit d794734c9bbfe22f86686dc2909c25f5ffe1a572 upstream.
+
+When ident_pud_init() uses only gbpages to create identity maps, large
+ranges of addresses not actually requested can be included in the
+resulting table; a 4K request will map a full GB. On UV systems, this
+ends up including regions that will cause hardware to halt the system
+if accessed (these are marked "reserved" by BIOS). Even processor
+speculation into these regions is enough to trigger the system halt.
+
+Only use gbpages when map creation requests include the full GB page
+of space. Fall back to using smaller 2M pages when only portions of a
+GB page are included in the request.
+
+No attempt is made to coalesce mapping requests. If a request requires
+a map entry at the 2M (pmd) level, subsequent mapping requests within
+the same 1G region will also be at the pmd level, even if adjacent or
+overlapping such requests could have been combined to map a full
+gbpage. Existing usage starts with larger regions and then adds
+smaller regions, so this should not have any great consequence.
+
+[ dhansen: fix up comment formatting, simplifty changelog ]
+
+Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/all/20240126164841.170866-1-steve.wahl%40hpe.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/mm/ident_map.c | 23 ++++++++++++++++++-----
+ 1 file changed, 18 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/mm/ident_map.c
++++ b/arch/x86/mm/ident_map.c
+@@ -26,18 +26,31 @@ static int ident_pud_init(struct x86_map
+ for (; addr < end; addr = next) {
+ pud_t *pud = pud_page + pud_index(addr);
+ pmd_t *pmd;
++ bool use_gbpage;
+
+ next = (addr & PUD_MASK) + PUD_SIZE;
+ if (next > end)
+ next = end;
+
+- if (info->direct_gbpages) {
+- pud_t pudval;
++ /* if this is already a gbpage, this portion is already mapped */
++ if (pud_large(*pud))
++ continue;
++
++ /* Is using a gbpage allowed? */
++ use_gbpage = info->direct_gbpages;
+
+- if (pud_present(*pud))
+- continue;
++ /* Don't use gbpage if it maps more than the requested region. */
++ /* at the begining: */
++ use_gbpage &= ((addr & ~PUD_MASK) == 0);
++ /* ... or at the end: */
++ use_gbpage &= ((next & ~PUD_MASK) == 0);
++
++ /* Never overwrite existing mappings */
++ use_gbpage &= !pud_present(*pud);
++
++ if (use_gbpage) {
++ pud_t pudval;
+
+- addr &= PUD_MASK;
+ pudval = __pud((addr - info->offset) | info->page_flag);
+ set_pud(pud, pudval);
+ continue;
--- /dev/null
+From 5f24f41e8ea62a6a9095f9bbafb8b3aebe265c68 Mon Sep 17 00:00:00 2001
+From: Herbert Xu <herbert@gondor.apana.org.au>
+Date: Fri, 10 Mar 2023 17:26:05 +0800
+Subject: xfrm: Remove inner/outer modes from input path
+
+From: Herbert Xu <herbert@gondor.apana.org.au>
+
+commit 5f24f41e8ea62a6a9095f9bbafb8b3aebe265c68 upstream.
+
+The inner/outer modes were added to abstract out common code that
+were once duplicated between IPv4 and IPv6. As time went on the
+abstractions have been removed and we are now left with empty
+shells that only contain duplicate information. These can be
+removed one-by-one as the same information is already present
+elsewhere in the xfrm_state object.
+
+Removing them from the input path actually allows certain valid
+combinations that are currently disallowed. In particular, when
+a transport mode SA sits beneath a tunnel mode SA that changes
+address families, at present the transport mode SA cannot have
+AF_UNSPEC as its selector because it will be erroneously be treated
+as inter-family itself even though it simply sits beneath one.
+
+This is a serious problem because you can't set the selector to
+non-AF_UNSPEC either as that will cause the selector match to
+fail as we always match selectors to the inner-most traffic.
+
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Cc: Sri Sakthi <srisakthi.s@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/xfrm/xfrm_input.c | 66 +++++++++++++++++---------------------------------
+ 1 file changed, 23 insertions(+), 43 deletions(-)
+
+--- a/net/xfrm/xfrm_input.c
++++ b/net/xfrm/xfrm_input.c
+@@ -232,9 +232,6 @@ static int xfrm4_remove_tunnel_encap(str
+ {
+ int err = -EINVAL;
+
+- if (XFRM_MODE_SKB_CB(skb)->protocol != IPPROTO_IPIP)
+- goto out;
+-
+ if (!pskb_may_pull(skb, sizeof(struct iphdr)))
+ goto out;
+
+@@ -270,8 +267,6 @@ static int xfrm6_remove_tunnel_encap(str
+ {
+ int err = -EINVAL;
+
+- if (XFRM_MODE_SKB_CB(skb)->protocol != IPPROTO_IPV6)
+- goto out;
+ if (!pskb_may_pull(skb, sizeof(struct ipv6hdr)))
+ goto out;
+
+@@ -332,22 +327,26 @@ out:
+ */
+ static int
+ xfrm_inner_mode_encap_remove(struct xfrm_state *x,
+- const struct xfrm_mode *inner_mode,
+ struct sk_buff *skb)
+ {
+- switch (inner_mode->encap) {
++ switch (x->props.mode) {
+ case XFRM_MODE_BEET:
+- if (inner_mode->family == AF_INET)
++ switch (XFRM_MODE_SKB_CB(skb)->protocol) {
++ case IPPROTO_IPIP:
++ case IPPROTO_BEETPH:
+ return xfrm4_remove_beet_encap(x, skb);
+- if (inner_mode->family == AF_INET6)
++ case IPPROTO_IPV6:
+ return xfrm6_remove_beet_encap(x, skb);
++ }
+ break;
+ case XFRM_MODE_TUNNEL:
+- if (inner_mode->family == AF_INET)
++ switch (XFRM_MODE_SKB_CB(skb)->protocol) {
++ case IPPROTO_IPIP:
+ return xfrm4_remove_tunnel_encap(x, skb);
+- if (inner_mode->family == AF_INET6)
++ case IPPROTO_IPV6:
+ return xfrm6_remove_tunnel_encap(x, skb);
+ break;
++ }
+ }
+
+ WARN_ON_ONCE(1);
+@@ -356,9 +355,7 @@ xfrm_inner_mode_encap_remove(struct xfrm
+
+ static int xfrm_prepare_input(struct xfrm_state *x, struct sk_buff *skb)
+ {
+- const struct xfrm_mode *inner_mode = &x->inner_mode;
+-
+- switch (x->outer_mode.family) {
++ switch (x->props.family) {
+ case AF_INET:
+ xfrm4_extract_header(skb);
+ break;
+@@ -370,17 +367,12 @@ static int xfrm_prepare_input(struct xfr
+ return -EAFNOSUPPORT;
+ }
+
+- if (x->sel.family == AF_UNSPEC) {
+- inner_mode = xfrm_ip2inner_mode(x, XFRM_MODE_SKB_CB(skb)->protocol);
+- if (!inner_mode)
+- return -EAFNOSUPPORT;
+- }
+-
+- switch (inner_mode->family) {
+- case AF_INET:
++ switch (XFRM_MODE_SKB_CB(skb)->protocol) {
++ case IPPROTO_IPIP:
++ case IPPROTO_BEETPH:
+ skb->protocol = htons(ETH_P_IP);
+ break;
+- case AF_INET6:
++ case IPPROTO_IPV6:
+ skb->protocol = htons(ETH_P_IPV6);
+ break;
+ default:
+@@ -388,7 +380,7 @@ static int xfrm_prepare_input(struct xfr
+ break;
+ }
+
+- return xfrm_inner_mode_encap_remove(x, inner_mode, skb);
++ return xfrm_inner_mode_encap_remove(x, skb);
+ }
+
+ /* Remove encapsulation header.
+@@ -434,17 +426,16 @@ static int xfrm6_transport_input(struct
+ }
+
+ static int xfrm_inner_mode_input(struct xfrm_state *x,
+- const struct xfrm_mode *inner_mode,
+ struct sk_buff *skb)
+ {
+- switch (inner_mode->encap) {
++ switch (x->props.mode) {
+ case XFRM_MODE_BEET:
+ case XFRM_MODE_TUNNEL:
+ return xfrm_prepare_input(x, skb);
+ case XFRM_MODE_TRANSPORT:
+- if (inner_mode->family == AF_INET)
++ if (x->props.family == AF_INET)
+ return xfrm4_transport_input(x, skb);
+- if (inner_mode->family == AF_INET6)
++ if (x->props.family == AF_INET6)
+ return xfrm6_transport_input(x, skb);
+ break;
+ case XFRM_MODE_ROUTEOPTIMIZATION:
+@@ -462,7 +453,6 @@ int xfrm_input(struct sk_buff *skb, int
+ {
+ const struct xfrm_state_afinfo *afinfo;
+ struct net *net = dev_net(skb->dev);
+- const struct xfrm_mode *inner_mode;
+ int err;
+ __be32 seq;
+ __be32 seq_hi;
+@@ -492,7 +482,7 @@ int xfrm_input(struct sk_buff *skb, int
+ goto drop;
+ }
+
+- family = x->outer_mode.family;
++ family = x->props.family;
+
+ /* An encap_type of -1 indicates async resumption. */
+ if (encap_type == -1) {
+@@ -676,17 +666,7 @@ resume:
+
+ XFRM_MODE_SKB_CB(skb)->protocol = nexthdr;
+
+- inner_mode = &x->inner_mode;
+-
+- if (x->sel.family == AF_UNSPEC) {
+- inner_mode = xfrm_ip2inner_mode(x, XFRM_MODE_SKB_CB(skb)->protocol);
+- if (inner_mode == NULL) {
+- XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEMODEERROR);
+- goto drop;
+- }
+- }
+-
+- if (xfrm_inner_mode_input(x, inner_mode, skb)) {
++ if (xfrm_inner_mode_input(x, skb)) {
+ XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEMODEERROR);
+ goto drop;
+ }
+@@ -701,7 +681,7 @@ resume:
+ * transport mode so the outer address is identical.
+ */
+ daddr = &x->id.daddr;
+- family = x->outer_mode.family;
++ family = x->props.family;
+
+ err = xfrm_parse_spi(skb, nexthdr, &spi, &seq);
+ if (err < 0) {
+@@ -732,7 +712,7 @@ resume:
+
+ err = -EAFNOSUPPORT;
+ rcu_read_lock();
+- afinfo = xfrm_state_afinfo_get_rcu(x->inner_mode.family);
++ afinfo = xfrm_state_afinfo_get_rcu(x->props.family);
+ if (likely(afinfo))
+ err = afinfo->transport_finish(skb, xfrm_gro || async);
+ rcu_read_unlock();
--- /dev/null
+From f4796398f21b9844017a2dac883b1dd6ad6edd60 Mon Sep 17 00:00:00 2001
+From: Herbert Xu <herbert@gondor.apana.org.au>
+Date: Fri, 10 Mar 2023 17:40:32 +0800
+Subject: xfrm: Remove inner/outer modes from output path
+
+From: Herbert Xu <herbert@gondor.apana.org.au>
+
+commit f4796398f21b9844017a2dac883b1dd6ad6edd60 upstream.
+
+The inner/outer modes were added to abstract out common code that
+were once duplicated between IPv4 and IPv6. As time went on the
+abstractions have been removed and we are now left with empty
+shells that only contain duplicate information. These can be
+removed one-by-one as the same information is already present
+elsewhere in the xfrm_state object.
+
+Just like the input-side, removing this from the output code
+makes it possible to use transport-mode SAs underneath an
+inter-family tunnel mode SA.
+
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Cc: Sri Sakthi <srisakthi.s@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/xfrm/xfrm_output.c | 33 +++++++++++----------------------
+ 1 file changed, 11 insertions(+), 22 deletions(-)
+
+--- a/net/xfrm/xfrm_output.c
++++ b/net/xfrm/xfrm_output.c
+@@ -414,7 +414,7 @@ static int xfrm4_prepare_output(struct x
+ IPCB(skb)->flags |= IPSKB_XFRM_TUNNEL_SIZE;
+ skb->protocol = htons(ETH_P_IP);
+
+- switch (x->outer_mode.encap) {
++ switch (x->props.mode) {
+ case XFRM_MODE_BEET:
+ return xfrm4_beet_encap_add(x, skb);
+ case XFRM_MODE_TUNNEL:
+@@ -437,7 +437,7 @@ static int xfrm6_prepare_output(struct x
+ skb->ignore_df = 1;
+ skb->protocol = htons(ETH_P_IPV6);
+
+- switch (x->outer_mode.encap) {
++ switch (x->props.mode) {
+ case XFRM_MODE_BEET:
+ return xfrm6_beet_encap_add(x, skb);
+ case XFRM_MODE_TUNNEL:
+@@ -453,22 +453,22 @@ static int xfrm6_prepare_output(struct x
+
+ static int xfrm_outer_mode_output(struct xfrm_state *x, struct sk_buff *skb)
+ {
+- switch (x->outer_mode.encap) {
++ switch (x->props.mode) {
+ case XFRM_MODE_BEET:
+ case XFRM_MODE_TUNNEL:
+- if (x->outer_mode.family == AF_INET)
++ if (x->props.family == AF_INET)
+ return xfrm4_prepare_output(x, skb);
+- if (x->outer_mode.family == AF_INET6)
++ if (x->props.family == AF_INET6)
+ return xfrm6_prepare_output(x, skb);
+ break;
+ case XFRM_MODE_TRANSPORT:
+- if (x->outer_mode.family == AF_INET)
++ if (x->props.family == AF_INET)
+ return xfrm4_transport_output(x, skb);
+- if (x->outer_mode.family == AF_INET6)
++ if (x->props.family == AF_INET6)
+ return xfrm6_transport_output(x, skb);
+ break;
+ case XFRM_MODE_ROUTEOPTIMIZATION:
+- if (x->outer_mode.family == AF_INET6)
++ if (x->props.family == AF_INET6)
+ return xfrm6_ro_output(x, skb);
+ WARN_ON_ONCE(1);
+ break;
+@@ -866,21 +866,10 @@ static int xfrm6_extract_output(struct x
+
+ static int xfrm_inner_extract_output(struct xfrm_state *x, struct sk_buff *skb)
+ {
+- const struct xfrm_mode *inner_mode;
+-
+- if (x->sel.family == AF_UNSPEC)
+- inner_mode = xfrm_ip2inner_mode(x,
+- xfrm_af2proto(skb_dst(skb)->ops->family));
+- else
+- inner_mode = &x->inner_mode;
+-
+- if (inner_mode == NULL)
+- return -EAFNOSUPPORT;
+-
+- switch (inner_mode->family) {
+- case AF_INET:
++ switch (skb->protocol) {
++ case htons(ETH_P_IP):
+ return xfrm4_extract_output(x, skb);
+- case AF_INET6:
++ case htons(ETH_P_IPV6):
+ return xfrm6_extract_output(x, skb);
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
