--- /dev/null
+From eafae0fdd115a71b3a200ef1a31f86da04bac77f Mon Sep 17 00:00:00 2001
+From: Evgeniy Harchenko <evgeniyharchenko.dev@gmail.com>
+Date: Fri, 15 Aug 2025 12:58:14 +0300
+Subject: ALSA: hda/realtek: Add support for HP EliteBook x360 830 G6 and EliteBook 830 G6
+
+From: Evgeniy Harchenko <evgeniyharchenko.dev@gmail.com>
+
+commit eafae0fdd115a71b3a200ef1a31f86da04bac77f upstream.
+
+The HP EliteBook x360 830 G6 and HP EliteBook 830 G6 have
+Realtek HDA codec ALC215. It needs the ALC285_FIXUP_HP_GPIO_LED
+quirk to enable the mute LED.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Evgeniy Harchenko <evgeniyharchenko.dev@gmail.com>
+Link: https://patch.msgid.link/20250815095814.75845-1-evgeniyharchenko.dev@gmail.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
+@@ -9319,6 +9319,8 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x103c, 0x84e7, "HP Pavilion 15", ALC269_FIXUP_HP_MUTE_LED_MIC3),
+ SND_PCI_QUIRK(0x103c, 0x8519, "HP Spectre x360 15-df0xxx", ALC285_FIXUP_HP_SPECTRE_X360),
+ SND_PCI_QUIRK(0x103c, 0x8537, "HP ProBook 440 G6", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
++ SND_PCI_QUIRK(0x103c, 0x8548, "HP EliteBook x360 830 G6", ALC285_FIXUP_HP_GPIO_LED),
++ SND_PCI_QUIRK(0x103c, 0x854a, "HP EliteBook 830 G6", ALC285_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x85c6, "HP Pavilion x360 Convertible 14-dy1xxx", ALC295_FIXUP_HP_MUTE_LED_COEFBIT11),
+ SND_PCI_QUIRK(0x103c, 0x85de, "HP Envy x360 13-ar0xxx", ALC285_FIXUP_HP_ENVY_X360),
+ SND_PCI_QUIRK(0x103c, 0x860f, "HP ZBook 15 G6", ALC285_FIXUP_HP_GPIO_AMP_INIT),
--- /dev/null
+From 99d7ab8db9d8230b243f5ed20ba0229e54cc0dfa Mon Sep 17 00:00:00 2001
+From: Jiayi Li <lijiayi@kylinos.cn>
+Date: Mon, 4 Aug 2025 09:36:04 +0800
+Subject: memstick: Fix deadlock by moving removing flag earlier
+
+From: Jiayi Li <lijiayi@kylinos.cn>
+
+commit 99d7ab8db9d8230b243f5ed20ba0229e54cc0dfa upstream.
+
+The existing memstick core patch: commit 62c59a8786e6 ("memstick: Skip
+allocating card when removing host") sets host->removing in
+memstick_remove_host(),but still exists a critical time window where
+memstick_check can run after host->eject is set but before removing is set.
+
+In the rtsx_usb_ms driver, the problematic sequence is:
+
+rtsx_usb_ms_drv_remove: memstick_check:
+ host->eject = true
+ cancel_work_sync(handle_req) if(!host->removing)
+ ... memstick_alloc_card()
+ memstick_set_rw_addr()
+ memstick_new_req()
+ rtsx_usb_ms_request()
+ if(!host->eject)
+ skip schedule_work
+ wait_for_completion()
+ memstick_remove_host: [blocks indefinitely]
+ host->removing = true
+ flush_workqueue()
+ [block]
+
+1. rtsx_usb_ms_drv_remove sets host->eject = true
+2. cancel_work_sync(&host->handle_req) runs
+3. memstick_check work may be executed here <-- danger window
+4. memstick_remove_host sets removing = 1
+
+During this window (step 3), memstick_check calls memstick_alloc_card,
+which may indefinitely waiting for mrq_complete completion that will
+never occur because rtsx_usb_ms_request sees eject=true and skips
+scheduling work, memstick_set_rw_addr waits forever for completion.
+
+This causes a deadlock when memstick_remove_host tries to flush_workqueue,
+waiting for memstick_check to complete, while memstick_check is blocked
+waiting for mrq_complete completion.
+
+Fix this by setting removing=true at the start of rtsx_usb_ms_drv_remove,
+before any work cancellation. This ensures memstick_check will see the
+removing flag immediately and exit early, avoiding the deadlock.
+
+Fixes: 62c59a8786e6 ("memstick: Skip allocating card when removing host")
+Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20250804013604.1311218-1-lijiayi@kylinos.cn
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/memstick/core/memstick.c | 1 -
+ drivers/memstick/host/rtsx_usb_ms.c | 1 +
+ 2 files changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/memstick/core/memstick.c
++++ b/drivers/memstick/core/memstick.c
+@@ -548,7 +548,6 @@ EXPORT_SYMBOL(memstick_add_host);
+ */
+ void memstick_remove_host(struct memstick_host *host)
+ {
+- host->removing = 1;
+ flush_workqueue(workqueue);
+ mutex_lock(&host->lock);
+ if (host->card)
+--- a/drivers/memstick/host/rtsx_usb_ms.c
++++ b/drivers/memstick/host/rtsx_usb_ms.c
+@@ -812,6 +812,7 @@ static int rtsx_usb_ms_drv_remove(struct
+ int err;
+
+ host->eject = true;
++ msh->removing = true;
+ cancel_work_sync(&host->handle_req);
+ cancel_delayed_work_sync(&host->poll_card);
+
--- /dev/null
+From dde30854bddfb5d69f30022b53c5955a41088b33 Mon Sep 17 00:00:00 2001
+From: "Herton R. Krzesinski" <herton@redhat.com>
+Date: Thu, 31 Jul 2025 18:40:51 -0300
+Subject: mm/debug_vm_pgtable: clear page table entries at destroy_args()
+
+From: Herton R. Krzesinski <herton@redhat.com>
+
+commit dde30854bddfb5d69f30022b53c5955a41088b33 upstream.
+
+The mm/debug_vm_pagetable test allocates manually page table entries for
+the tests it runs, using also its manually allocated mm_struct. That in
+itself is ok, but when it exits, at destroy_args() it fails to clear those
+entries with the *_clear functions.
+
+The problem is that leaves stale entries. If another process allocates an
+mm_struct with a pgd at the same address, it may end up running into the
+stale entry. This is happening in practice on a debug kernel with
+CONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extra
+debugging I added (it prints a warning trace if pgtables_bytes goes
+negative, in addition to the warning at check_mm() function):
+
+[ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000
+[ 2.539366] kmem_cache info
+[ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508
+[ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e
+(...)
+[ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0
+[ 2.552816] Modules linked in:
+[ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY
+[ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries
+[ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90
+[ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug)
+[ 2.552899] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002822 XER: 0000000a
+[ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0
+[ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001
+[ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff
+[ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000
+[ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb
+[ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0
+[ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000
+[ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001
+[ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760
+[ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0
+[ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0
+[ 2.553199] Call Trace:
+[ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)
+[ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0
+[ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570
+[ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650
+[ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290
+[ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0
+[ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870
+[ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150
+[ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50
+[ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0
+[ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec
+(...)
+[ 2.558892] ---[ end trace 0000000000000000 ]---
+[ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1
+[ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144
+
+Here the modprobe process ended up with an allocated mm_struct from the
+mm_struct slab that was used before by the debug_vm_pgtable test. That is
+not a problem, since the mm_struct is initialized again etc., however, if
+it ends up using the same pgd table, it bumps into the old stale entry
+when clearing/freeing the page table entries, so it tries to free an entry
+already gone (that one which was allocated by the debug_vm_pgtable test),
+which also explains the negative pgtables_bytes since it's accounting for
+not allocated entries in the current process.
+
+As far as I looked pgd_{alloc,free} etc. does not clear entries, and
+clearing of the entries is explicitly done in the free_pgtables->
+free_pgd_range->free_p4d_range->free_pud_range->free_pmd_range->
+free_pte_range path. However, the debug_vm_pgtable test does not call
+free_pgtables, since it allocates mm_struct and entries manually for its
+test and eg. not goes through page faults. So it also should clear
+manually the entries before exit at destroy_args().
+
+This problem was noticed on a reboot X number of times test being done on
+a powerpc host, with a debug kernel with CONFIG_DEBUG_VM_PGTABLE enabled.
+Depends on the system, but on a 100 times reboot loop the problem could
+manifest once or twice, if a process ends up getting the right mm->pgd
+entry with the stale entries used by mm/debug_vm_pagetable. After using
+this patch, I couldn't reproduce/experience the problems anymore. I was
+able to reproduce the problem as well on latest upstream kernel (6.16).
+
+I also modified destroy_args() to use mmput() instead of mmdrop(), there
+is no reason to hold mm_users reference and not release the mm_struct
+entirely, and in the output above with my debugging prints I already had
+patched it to use mmput, it did not fix the problem, but helped in the
+debugging as well.
+
+Link: https://lkml.kernel.org/r/20250731214051.4115182-1-herton@redhat.com
+Fixes: 3c9b84f044a9 ("mm/debug_vm_pgtable: introduce struct pgtable_debug_args")
+Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
+Cc: Anshuman Khandual <anshuman.khandual@arm.com>
+Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
+Cc: Gavin Shan <gshan@redhat.com>
+Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/debug_vm_pgtable.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/mm/debug_vm_pgtable.c
++++ b/mm/debug_vm_pgtable.c
+@@ -1050,29 +1050,34 @@ static void __init destroy_args(struct p
+
+ /* Free page table entries */
+ if (args->start_ptep) {
++ pmd_clear(args->pmdp);
+ pte_free(args->mm, args->start_ptep);
+ mm_dec_nr_ptes(args->mm);
+ }
+
+ if (args->start_pmdp) {
++ pud_clear(args->pudp);
+ pmd_free(args->mm, args->start_pmdp);
+ mm_dec_nr_pmds(args->mm);
+ }
+
+ if (args->start_pudp) {
++ p4d_clear(args->p4dp);
+ pud_free(args->mm, args->start_pudp);
+ mm_dec_nr_puds(args->mm);
+ }
+
+- if (args->start_p4dp)
++ if (args->start_p4dp) {
++ pgd_clear(args->pgdp);
+ p4d_free(args->mm, args->start_p4dp);
++ }
+
+ /* Free vma and mm struct */
+ if (args->vma)
+ vm_area_free(args->vma);
+
+ if (args->mm)
+- mmdrop(args->mm);
++ mmput(args->mm);
+ }
+
+ static struct page * __init
--- /dev/null
+From 293ed0f5f34e1e9df888456af4b0a021f57b5f54 Mon Sep 17 00:00:00 2001
+From: Victor Shih <victor.shih@genesyslogic.com.tw>
+Date: Thu, 31 Jul 2025 14:57:51 +0800
+Subject: mmc: sdhci-pci-gli: GL9763e: Rename the gli_set_gl9763e() for consistency
+
+From: Victor Shih <victor.shih@genesyslogic.com.tw>
+
+commit 293ed0f5f34e1e9df888456af4b0a021f57b5f54 upstream.
+
+In preparation to fix replay timer timeout, rename the
+gli_set_gl9763e() to gl9763e_hw_setting() for consistency.
+
+Signed-off-by: Victor Shih <victor.shih@genesyslogic.com.tw>
+Fixes: 1ae1d2d6e555 ("mmc: sdhci-pci-gli: Add Genesys Logic GL9763E support")
+Cc: stable@vger.kernel.org
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Link: https://lore.kernel.org/r/20250731065752.450231-3-victorshihgli@gmail.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-pci-gli.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/sdhci-pci-gli.c
++++ b/drivers/mmc/host/sdhci-pci-gli.c
+@@ -860,7 +860,7 @@ static void sdhci_gl9763e_reset(struct s
+ sdhci_reset(host, mask);
+ }
+
+-static void gli_set_gl9763e(struct sdhci_pci_slot *slot)
++static void gl9763e_hw_setting(struct sdhci_pci_slot *slot)
+ {
+ struct pci_dev *pdev = slot->chip->pdev;
+ u32 value;
+@@ -918,7 +918,7 @@ static int gli_probe_slot_gl9763e(struct
+ gli_pcie_enable_msi(slot);
+ host->mmc_host_ops.hs400_enhanced_strobe =
+ gl9763e_hs400_enhanced_strobe;
+- gli_set_gl9763e(slot);
++ gl9763e_hw_setting(slot);
+ sdhci_enable_v4_mode(host);
+
+ return 0;
scsi-ufs-ufs-pci-fix-hibernate-state-transition-for-intel-mtl-like-host-controllers.patch
scsi-ufs-ufs-pci-fix-default-runtime-and-system-pm-levels.patch
kvm-arm64-fix-kernel-bug-due-to-bad-backport-of-fpsimd-sve-sme-fix.patch
+memstick-fix-deadlock-by-moving-removing-flag-earlier.patch
+mmc-sdhci-pci-gli-gl9763e-rename-the-gli_set_gl9763e-for-consistency.patch
+squashfs-fix-memory-leak-in-squashfs_fill_super.patch
+mm-debug_vm_pgtable-clear-page-table-entries-at-destroy_args.patch
+alsa-hda-realtek-add-support-for-hp-elitebook-x360-830-g6-and-elitebook-830-g6.patch
--- /dev/null
+From b64700d41bdc4e9f82f1346c15a3678ebb91a89c Mon Sep 17 00:00:00 2001
+From: Phillip Lougher <phillip@squashfs.org.uk>
+Date: Mon, 11 Aug 2025 23:37:40 +0100
+Subject: squashfs: fix memory leak in squashfs_fill_super
+
+From: Phillip Lougher <phillip@squashfs.org.uk>
+
+commit b64700d41bdc4e9f82f1346c15a3678ebb91a89c upstream.
+
+If sb_min_blocksize returns 0, squashfs_fill_super exits without freeing
+allocated memory (sb->s_fs_info).
+
+Fix this by moving the call to sb_min_blocksize to before memory is
+allocated.
+
+Link: https://lkml.kernel.org/r/20250811223740.110392-1-phillip@squashfs.org.uk
+Fixes: 734aa85390ea ("Squashfs: check return result of sb_min_blocksize")
+Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
+Reported-by: Scott GUO <scottzhguo@tencent.com>
+Closes: https://lore.kernel.org/all/20250811061921.3807353-1-scott_gzh@163.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/squashfs/super.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/fs/squashfs/super.c
++++ b/fs/squashfs/super.c
+@@ -122,10 +122,15 @@ static int squashfs_fill_super(struct su
+ unsigned short flags;
+ unsigned int fragments;
+ u64 lookup_table_start, xattr_id_table_start, next_table;
+- int err;
++ int err, devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);
+
+ TRACE("Entered squashfs_fill_superblock\n");
+
++ if (!devblksize) {
++ errorf(fc, "squashfs: unable to set blocksize\n");
++ return -EINVAL;
++ }
++
+ sb->s_fs_info = kzalloc(sizeof(*msblk), GFP_KERNEL);
+ if (sb->s_fs_info == NULL) {
+ ERROR("Failed to allocate squashfs_sb_info\n");
+@@ -135,12 +140,7 @@ static int squashfs_fill_super(struct su
+
+ msblk->panic_on_errors = (opts->errors == Opt_errors_panic);
+
+- msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);
+- if (!msblk->devblksize) {
+- errorf(fc, "squashfs: unable to set blocksize\n");
+- return -EINVAL;
+- }
+-
++ msblk->devblksize = devblksize;
+ msblk->devblksize_log2 = ffz(~msblk->devblksize);
+
+ mutex_init(&msblk->meta_index_mutex);
projects / thirdparty / kernel / stable-queue.git / commitdiff
