From: Greg Kroah-Hartman Date: Fri, 22 Aug 2025 15:09:01 +0000 (+0200) Subject: 6.6-stable patches X-Git-Tag: v6.16.3~30 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1f33b2fb2d9220ba0320a7393e4f747f6e0bfcd7;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: alsa-hda-realtek-add-support-for-hp-elitebook-x360-830-g6-and-elitebook-830-g6.patch memstick-fix-deadlock-by-moving-removing-flag-earlier.patch mm-debug_vm_pgtable-clear-page-table-entries-at-destroy_args.patch mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn.patch mmc-sdhci-pci-gli-gl9763e-rename-the-gli_set_gl9763e-for-consistency.patch squashfs-fix-memory-leak-in-squashfs_fill_super.patch --- diff --git a/queue-6.6/alsa-hda-realtek-add-support-for-hp-elitebook-x360-830-g6-and-elitebook-830-g6.patch b/queue-6.6/alsa-hda-realtek-add-support-for-hp-elitebook-x360-830-g6-and-elitebook-830-g6.patch new file mode 100644 index 0000000000..704130b9bb --- /dev/null +++ b/queue-6.6/alsa-hda-realtek-add-support-for-hp-elitebook-x360-830-g6-and-elitebook-830-g6.patch @@ -0,0 +1,33 @@ +From eafae0fdd115a71b3a200ef1a31f86da04bac77f Mon Sep 17 00:00:00 2001 +From: Evgeniy Harchenko +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 + +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: +Signed-off-by: Evgeniy Harchenko +Link: https://patch.msgid.link/20250815095814.75845-1-evgeniyharchenko.dev@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -10071,6 +10071,8 @@ static const struct hda_quirk alc269_fix + 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), diff --git a/queue-6.6/memstick-fix-deadlock-by-moving-removing-flag-earlier.patch b/queue-6.6/memstick-fix-deadlock-by-moving-removing-flag-earlier.patch new file mode 100644 index 0000000000..5b47a63993 --- /dev/null +++ b/queue-6.6/memstick-fix-deadlock-by-moving-removing-flag-earlier.patch @@ -0,0 +1,80 @@ +From 99d7ab8db9d8230b243f5ed20ba0229e54cc0dfa Mon Sep 17 00:00:00 2001 +From: Jiayi Li +Date: Mon, 4 Aug 2025 09:36:04 +0800 +Subject: memstick: Fix deadlock by moving removing flag earlier + +From: Jiayi Li + +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 +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20250804013604.1311218-1-lijiayi@kylinos.cn +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + 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); + diff --git a/queue-6.6/mm-debug_vm_pgtable-clear-page-table-entries-at-destroy_args.patch b/queue-6.6/mm-debug_vm_pgtable-clear-page-table-entries-at-destroy_args.patch new file mode 100644 index 0000000000..3177537002 --- /dev/null +++ b/queue-6.6/mm-debug_vm_pgtable-clear-page-table-entries-at-destroy_args.patch @@ -0,0 +1,145 @@ +From dde30854bddfb5d69f30022b53c5955a41088b33 Mon Sep 17 00:00:00 2001 +From: "Herton R. Krzesinski" +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 + +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 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 +Cc: Anshuman Khandual +Cc: Christophe Leroy +Cc: Gavin Shan +Cc: Gerald Schaefer +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -1047,29 +1047,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 diff --git a/queue-6.6/mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn.patch b/queue-6.6/mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn.patch new file mode 100644 index 0000000000..123df507dd --- /dev/null +++ b/queue-6.6/mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn.patch @@ -0,0 +1,62 @@ +From 2e6053fea379806269c4f7f5e36b523c9c0fb35c Mon Sep 17 00:00:00 2001 +From: Jinjiang Tu +Date: Fri, 15 Aug 2025 15:32:09 +0800 +Subject: mm/memory-failure: fix infinite UCE for VM_PFNMAP pfn + +From: Jinjiang Tu + +commit 2e6053fea379806269c4f7f5e36b523c9c0fb35c upstream. + +When memory_failure() is called for a already hwpoisoned pfn, +kill_accessing_process() will be called to kill current task. However, if +the vma of the accessing vaddr is VM_PFNMAP, walk_page_range() will skip +the vma in walk_page_test() and return 0. + +Before commit aaf99ac2ceb7 ("mm/hwpoison: do not send SIGBUS to processes +with recovered clean pages"), kill_accessing_process() will return EFAULT. +For x86, the current task will be killed in kill_me_maybe(). + +However, after this commit, kill_accessing_process() simplies return 0, +that means UCE is handled properly, but it doesn't actually. In such +case, the user task will trigger UCE infinitely. + +To fix it, add .test_walk callback for hwpoison_walk_ops to scan all vmas. + +Link: https://lkml.kernel.org/r/20250815073209.1984582-1-tujinjiang@huawei.com +Fixes: aaf99ac2ceb7 ("mm/hwpoison: do not send SIGBUS to processes with recovered clean pages") +Signed-off-by: Jinjiang Tu +Acked-by: David Hildenbrand +Acked-by: Miaohe Lin +Reviewed-by: Jane Chu +Cc: Kefeng Wang +Cc: Naoya Horiguchi +Cc: Oscar Salvador +Cc: Shuai Xue +Cc: Zi Yan +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/memory-failure.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/mm/memory-failure.c ++++ b/mm/memory-failure.c +@@ -835,9 +835,17 @@ static int hwpoison_hugetlb_range(pte_t + #define hwpoison_hugetlb_range NULL + #endif + ++static int hwpoison_test_walk(unsigned long start, unsigned long end, ++ struct mm_walk *walk) ++{ ++ /* We also want to consider pages mapped into VM_PFNMAP. */ ++ return 0; ++} ++ + static const struct mm_walk_ops hwpoison_walk_ops = { + .pmd_entry = hwpoison_pte_range, + .hugetlb_entry = hwpoison_hugetlb_range, ++ .test_walk = hwpoison_test_walk, + .walk_lock = PGWALK_RDLOCK, + }; + diff --git a/queue-6.6/mmc-sdhci-pci-gli-gl9763e-rename-the-gli_set_gl9763e-for-consistency.patch b/queue-6.6/mmc-sdhci-pci-gli-gl9763e-rename-the-gli_set_gl9763e-for-consistency.patch new file mode 100644 index 0000000000..228db8032c --- /dev/null +++ b/queue-6.6/mmc-sdhci-pci-gli-gl9763e-rename-the-gli_set_gl9763e-for-consistency.patch @@ -0,0 +1,43 @@ +From 293ed0f5f34e1e9df888456af4b0a021f57b5f54 Mon Sep 17 00:00:00 2001 +From: Victor Shih +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 + +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 +Fixes: 1ae1d2d6e555 ("mmc: sdhci-pci-gli: Add Genesys Logic GL9763E support") +Cc: stable@vger.kernel.org +Acked-by: Adrian Hunter +Link: https://lore.kernel.org/r/20250731065752.450231-3-victorshihgli@gmail.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -1343,7 +1343,7 @@ cleanup: + return ret; + } + +-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; +@@ -1515,7 +1515,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; diff --git a/queue-6.6/series b/queue-6.6/series index 0b9a5f1a2c..c1b30f4e14 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -477,3 +477,9 @@ arm64-amu-use-capacity_ref_freq-to-set-amu-ratio.patch topology-set-capacity_freq_ref-in-all-cases.patch sched-fair-fix-frequency-selection-for-non-invariant-case.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 +mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn.patch +alsa-hda-realtek-add-support-for-hp-elitebook-x360-830-g6-and-elitebook-830-g6.patch diff --git a/queue-6.6/squashfs-fix-memory-leak-in-squashfs_fill_super.patch b/queue-6.6/squashfs-fix-memory-leak-in-squashfs_fill_super.patch new file mode 100644 index 0000000000..67b8917384 --- /dev/null +++ b/queue-6.6/squashfs-fix-memory-leak-in-squashfs_fill_super.patch @@ -0,0 +1,60 @@ +From b64700d41bdc4e9f82f1346c15a3678ebb91a89c Mon Sep 17 00:00:00 2001 +From: Phillip Lougher +Date: Mon, 11 Aug 2025 23:37:40 +0100 +Subject: squashfs: fix memory leak in squashfs_fill_super + +From: Phillip Lougher + +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 +Reported-by: Scott GUO +Closes: https://lore.kernel.org/all/20250811061921.3807353-1-scott_gzh@163.com +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/squashfs/super.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/fs/squashfs/super.c ++++ b/fs/squashfs/super.c +@@ -187,10 +187,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"); +@@ -201,12 +206,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);