March 2025 - Linux-stable-mirror

[PATCH v2] char: xillybus: Fix error handling in xillybus_init_chrdev()

by Ma Ke

After cdev_alloc() succeed and cdev_add() failed, call cdev_del() to remove unit->cdev from the system properly. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 8cb5d216ab33 ("char: xillybus: Move class-related functions to new xillybus_class.c") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - modified the patch as suggestions to avoid UAF. --- drivers/char/xillybus/xillybus_class.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/char/xillybus/xillybus_class.c b/drivers/char/xillybus/xillybus_class.c index c92a628e389e..356af6551b0d 100644 --- a/drivers/char/xillybus/xillybus_class.c +++ b/drivers/char/xillybus/xillybus_class.c @@ -104,8 +104,7 @@ int xillybus_init_chrdev(struct device *dev, if (rc) { dev_err(dev, "Failed to add cdev.\n"); /* kobject_put() is normally done by cdev_del() */ - kobject_put(&unit->cdev->kobj); - goto unregister_chrdev; + goto err_cdev; } for (i = 0; i < num_nodes; i++) { @@ -157,6 +156,7 @@ int xillybus_init_chrdev(struct device *dev, device_destroy(&xillybus_class, MKDEV(unit->major, i + unit->lowest_minor)); +err_cdev: cdev_del(unit->cdev); unregister_chrdev: -- 2.25.1

7 months, 4 weeks

2
1
0 0

[PATCH] jfs: add index corruption check to DT_GETPAGE()

by Roman Smirnov

If the file system is corrupted, the header.stblindex variable may become greater than 127. Because of this, an array access out of bounds may occur: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:3096:10 index 237 is out of range for type 'struct dtslot[128]' CPU: 0 UID: 0 PID: 5822 Comm: syz-executor740 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429 dtReadFirst+0x622/0xc50 fs/jfs/jfs_dtree.c:3096 dtReadNext fs/jfs/jfs_dtree.c:3147 [inline] jfs_readdir+0x9aa/0x3c50 fs/jfs/jfs_dtree.c:2862 wrap_directory_iterator+0x91/0xd0 fs/readdir.c:65 iterate_dir+0x571/0x800 fs/readdir.c:108 __do_sys_getdents64 fs/readdir.c:403 [inline] __se_sys_getdents64+0x1e2/0x4b0 fs/readdir.c:389 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ---[ end trace ]--- Add a stblindex check for corruption. Reported-by: syzbot <syzbot+9120834fc227768625ba(a)syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=9120834fc227768625ba Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Roman Smirnov <r.smirnov(a)omp.ru> --- fs/jfs/jfs_dtree.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c index 8f85177f284b..93db6eec4465 100644 --- a/fs/jfs/jfs_dtree.c +++ b/fs/jfs/jfs_dtree.c @@ -117,7 +117,8 @@ do { \ if (!(RC)) { \ if (((P)->header.nextindex > \ (((BN) == 0) ? DTROOTMAXSLOT : (P)->header.maxslot)) || \ - ((BN) && ((P)->header.maxslot > DTPAGEMAXSLOT))) { \ + ((BN) && (((P)->header.maxslot > DTPAGEMAXSLOT) || \ + ((P)->header.stblindex >= DTPAGEMAXSLOT)))) { \ BT_PUTPAGE(MP); \ jfs_error((IP)->i_sb, \ "DT_GETPAGE: dtree page corrupt\n"); \ -- 2.34.1

7 months, 4 weeks

2
1
0 0

[merged mm-hotfixes-stable] dma-kmsan-export-kmsan_handle_dma-for-modules.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: dma: kmsan: export kmsan_handle_dma() for modules has been removed from the -mm tree. Its filename was dma-kmsan-export-kmsan_handle_dma-for-modules.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Subject: dma: kmsan: export kmsan_handle_dma() for modules Date: Tue, 18 Feb 2025 10:14:11 +0100 kmsan_handle_dma() is used by virtio_ring() which can be built as a module. kmsan_handle_dma() needs to be exported otherwise building the virtio_ring fails. Export kmsan_handle_dma for modules. Link: https://lkml.kernel.org/r/20250218091411.MMS3wBN9@linutronix.de Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202502150634.qjxwSeJR-lkp@intel.com/ Fixes: 7ade4f10779c ("dma: kmsan: unpoison DMA mappings") Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Cc: Alexander Potapenko <glider(a)google.com> Cc: Dmitriy Vyukov <dvyukov(a)google.com> Cc: Macro Elver <elver(a)google.com> Cc: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kmsan/hooks.c | 1 + 1 file changed, 1 insertion(+) --- a/mm/kmsan/hooks.c~dma-kmsan-export-kmsan_handle_dma-for-modules +++ a/mm/kmsan/hooks.c @@ -357,6 +357,7 @@ void kmsan_handle_dma(struct page *page, size -= to_go; } } +EXPORT_SYMBOL_GPL(kmsan_handle_dma); void kmsan_handle_dma_sg(struct scatterlist *sg, int nents, enum dma_data_direction dir) _ Patches currently in -mm which might be from bigeasy(a)linutronix.de are rcu-provide-a-static-initializer-for-hlist_nulls_head.patch ucount-replace-get_ucounts_or_wrap-with-atomic_inc_not_zero.patch ucount-use-rcu-for-ucounts-lookups.patch ucount-use-rcuref_t-for-reference-counting.patch

7 months, 4 weeks

2
1
0 0

[PATCH 6.1.y] selftests/vm: fix undefined reference of the `default_huge_page_size`

by Andrey Kalachev

The commit a584c7734a4d ("selftests: mm: fix map_hugetlb failure on 64K page size systems") backported the fix from v6.8 to stable v6.1. The patch uses default_huge_page_size() function, which definition moved into vm_util.[ch] by commit bd4d67e76f699 ("selftests/mm: merge default_huge_page_size() into one") merged to upsream since v6.4. However, in v6.1 common definition/declaration for the default_huge_page_size() we doesn't have, the following build error is seen: map_hugetlb.c:79:25: warning: implicit declaration of function ‘default_huge_page_size’ [-Wimplicit-function-declaration] 79 | hugepage_size = default_huge_page_size(); | ^~~~~~~~~~~~~~~~~~~~~~ /usr/bin/ld: /tmp/ccx95BZz.o: in function `main': map_hugetlb.c:(.text+0x104): undefined reference to `default_huge_page_size' Place default_huge_page_size() function body into map_hugetlb.c to fix this issue. Fixes: a584c7734a4d ("selftests: mm: fix map_hugetlb failure on 64K page size systems") Signed-off-by: Andrey Kalachev <kalachev(a)swemel.ru> --- tools/testing/selftests/vm/map_hugetlb.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/tools/testing/selftests/vm/map_hugetlb.c b/tools/testing/selftests/vm/map_hugetlb.c index c65c55b7a789..5826c50b6736 100644 --- a/tools/testing/selftests/vm/map_hugetlb.c +++ b/tools/testing/selftests/vm/map_hugetlb.c @@ -67,6 +67,30 @@ static int read_bytes(char *addr, size_t length) return 0; } +/* + * default_huge_page_size copied from mlock2-tests.c + */ +unsigned long default_huge_page_size(void) +{ + unsigned long hps = 0; + char *line = NULL; + size_t linelen = 0; + FILE *f = fopen("/proc/meminfo", "r"); + + if (!f) + return 0; + while (getline(&line, &linelen, f) > 0) { + if (sscanf(line, "Hugepagesize: %lu kB", &hps) == 1) { + hps <<= 10; + break; + } + } + + free(line); + fclose(f); + return hps; +} + int main(int argc, char **argv) { void *addr; -- 2.39.5

7 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] mm/slab/kvfree_rcu: Switch to WQ_MEM_RECLAIM wq" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x dfd3df31c9db752234d7d2e09bef2aeabb643ce4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025030914-turtle-tattered-27c6@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dfd3df31c9db752234d7d2e09bef2aeabb643ce4 Mon Sep 17 00:00:00 2001 From: "Uladzislau Rezki (Sony)" <urezki(a)gmail.com> Date: Fri, 28 Feb 2025 13:13:56 +0100 Subject: [PATCH] mm/slab/kvfree_rcu: Switch to WQ_MEM_RECLAIM wq Currently kvfree_rcu() APIs use a system workqueue which is "system_unbound_wq" to driver RCU machinery to reclaim a memory. Recently, it has been noted that the following kernel warning can be observed: <snip> workqueue: WQ_MEM_RECLAIM nvme-wq:nvme_scan_work is flushing !WQ_MEM_RECLAIM events_unbound:kfree_rcu_work WARNING: CPU: 21 PID: 330 at kernel/workqueue.c:3719 check_flush_dependency+0x112/0x120 Modules linked in: intel_uncore_frequency(E) intel_uncore_frequency_common(E) skx_edac(E) ... CPU: 21 UID: 0 PID: 330 Comm: kworker/u144:6 Tainted: G E 6.13.2-0_g925d379822da #1 Hardware name: Wiwynn Twin Lakes MP/Twin Lakes Passive MP, BIOS YMM20 02/01/2023 Workqueue: nvme-wq nvme_scan_work RIP: 0010:check_flush_dependency+0x112/0x120 Code: 05 9a 40 14 02 01 48 81 c6 c0 00 00 00 48 8b 50 18 48 81 c7 c0 00 00 00 48 89 f9 48 ... RSP: 0018:ffffc90000df7bd8 EFLAGS: 00010082 RAX: 000000000000006a RBX: ffffffff81622390 RCX: 0000000000000027 RDX: 00000000fffeffff RSI: 000000000057ffa8 RDI: ffff88907f960c88 RBP: 0000000000000000 R08: ffffffff83068e50 R09: 000000000002fffd R10: 0000000000000004 R11: 0000000000000000 R12: ffff8881001a4400 R13: 0000000000000000 R14: ffff88907f420fb8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88907f940000(0000) knlGS:0000000000000000 CR2: 00007f60c3001000 CR3: 000000107d010005 CR4: 00000000007726f0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xa4/0x140 ? check_flush_dependency+0x112/0x120 ? report_bug+0xe1/0x140 ? check_flush_dependency+0x112/0x120 ? handle_bug+0x5e/0x90 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? timer_recalc_next_expiry+0x190/0x190 ? check_flush_dependency+0x112/0x120 ? check_flush_dependency+0x112/0x120 __flush_work.llvm.1643880146586177030+0x174/0x2c0 flush_rcu_work+0x28/0x30 kvfree_rcu_barrier+0x12f/0x160 kmem_cache_destroy+0x18/0x120 bioset_exit+0x10c/0x150 disk_release.llvm.6740012984264378178+0x61/0xd0 device_release+0x4f/0x90 kobject_put+0x95/0x180 nvme_put_ns+0x23/0xc0 nvme_remove_invalid_namespaces+0xb3/0xd0 nvme_scan_work+0x342/0x490 process_scheduled_works+0x1a2/0x370 worker_thread+0x2ff/0x390 ? pwq_release_workfn+0x1e0/0x1e0 kthread+0xb1/0xe0 ? __kthread_parkme+0x70/0x70 ret_from_fork+0x30/0x40 ? __kthread_parkme+0x70/0x70 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- <snip> To address this switch to use of independent WQ_MEM_RECLAIM workqueue, so the rules are not violated from workqueue framework point of view. Apart of that, since kvfree_rcu() does reclaim memory it is worth to go with WQ_MEM_RECLAIM type of wq because it is designed for this purpose. Fixes: 6c6c47b063b5 ("mm, slab: call kvfree_rcu_barrier() from kmem_cache_destroy()"), Reported-by: Keith Busch <kbusch(a)kernel.org> Closes: https://lore.kernel.org/all/Z7iqJtCjHKfo8Kho@kbusch-mbp/ Cc: stable(a)vger.kernel.org Signed-off-by: Uladzislau Rezki (Sony) <urezki(a)gmail.com> Reviewed-by: Joel Fernandes <joelagnelf(a)nvidia.com> Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> diff --git a/mm/slab_common.c b/mm/slab_common.c index 4030907b6b7d..4c9f0a87f733 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1304,6 +1304,8 @@ module_param(rcu_min_cached_objs, int, 0444); static int rcu_delay_page_cache_fill_msec = 5000; module_param(rcu_delay_page_cache_fill_msec, int, 0444); +static struct workqueue_struct *rcu_reclaim_wq; + /* Maximum number of jiffies to wait before draining a batch. */ #define KFREE_DRAIN_JIFFIES (5 * HZ) #define KFREE_N_BATCHES 2 @@ -1632,10 +1634,10 @@ __schedule_delayed_monitor_work(struct kfree_rcu_cpu *krcp) if (delayed_work_pending(&krcp->monitor_work)) { delay_left = krcp->monitor_work.timer.expires - jiffies; if (delay < delay_left) - mod_delayed_work(system_unbound_wq, &krcp->monitor_work, delay); + mod_delayed_work(rcu_reclaim_wq, &krcp->monitor_work, delay); return; } - queue_delayed_work(system_unbound_wq, &krcp->monitor_work, delay); + queue_delayed_work(rcu_reclaim_wq, &krcp->monitor_work, delay); } static void @@ -1733,7 +1735,7 @@ kvfree_rcu_queue_batch(struct kfree_rcu_cpu *krcp) // "free channels", the batch can handle. Break // the loop since it is done with this CPU thus // queuing an RCU work is _always_ success here. - queued = queue_rcu_work(system_unbound_wq, &krwp->rcu_work); + queued = queue_rcu_work(rcu_reclaim_wq, &krwp->rcu_work); WARN_ON_ONCE(!queued); break; } @@ -1883,7 +1885,7 @@ run_page_cache_worker(struct kfree_rcu_cpu *krcp) if (rcu_scheduler_active == RCU_SCHEDULER_RUNNING && !atomic_xchg(&krcp->work_in_progress, 1)) { if (atomic_read(&krcp->backoff_page_cache_fill)) { - queue_delayed_work(system_unbound_wq, + queue_delayed_work(rcu_reclaim_wq, &krcp->page_cache_work, msecs_to_jiffies(rcu_delay_page_cache_fill_msec)); } else { @@ -2120,6 +2122,10 @@ void __init kvfree_rcu_init(void) int i, j; struct shrinker *kfree_rcu_shrinker; + rcu_reclaim_wq = alloc_workqueue("kvfree_rcu_reclaim", + WQ_UNBOUND | WQ_MEM_RECLAIM, 0); + WARN_ON(!rcu_reclaim_wq); + /* Clamp it to [0:100] seconds interval. */ if (rcu_delay_page_cache_fill_msec < 0 || rcu_delay_page_cache_fill_msec > 100 * MSEC_PER_SEC) {

7 months, 4 weeks

3
2
0 0

[PATCH] mmc: sdhci-brcmstb: add cqhci suspend/resume to PM ops

by Kamal Dasu

cqhci timeouts observed on brcmstb platforms during suspend: ... [ 164.832853] mmc0: cqhci: timeout for tag 18 ... Adding cqhci_suspend()/resume() calls to disable cqe in sdhci_brcmstb_suspend()/resume() respectively to fix CQE timeouts seen on PM suspend. Fixes: d46ba2d17f90 ("mmc: sdhci-brcmstb: Add support for Command Queuing (CQE)") Cc: stable(a)vger.kernel.org Signed-off-by: Kamal Dasu <kamal.dasu(a)broadcom.com> --- drivers/mmc/host/sdhci-brcmstb.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c index 0ef4d578ade8..bf55a9185eb6 100644 --- a/drivers/mmc/host/sdhci-brcmstb.c +++ b/drivers/mmc/host/sdhci-brcmstb.c @@ -505,6 +505,12 @@ static int sdhci_brcmstb_suspend(struct device *dev) struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host); clk_disable_unprepare(priv->base_clk); + if (host->mmc->caps2 & MMC_CAP2_CQE) { + ret = cqhci_suspend(host->mmc); + if (ret) + return ret; + } + return sdhci_pltfm_suspend(dev); } @@ -529,6 +535,9 @@ static int sdhci_brcmstb_resume(struct device *dev) ret = clk_set_rate(priv->base_clk, priv->base_freq_hz); } + if (host->mmc->caps2 & MMC_CAP2_CQE) + ret = cqhci_resume(host->mmc); + return ret; } #endif -- 2.17.1

7 months, 4 weeks

2
2
0 0

[PATCH] fpga: bridge: incorrect set to clear freeze_illegal_request register

by Tanmay Kathpalia

A Partial Region Controller can be connected to one or more Freeze Bridge. Each Freeze Bridge has an illegal_request bit represented in the freeze_illegal_request register. Thus, instead of just set to clear the illegal_request bit for first Freeze Bridge, we need to ensure the set to clear action is applied to which ever Freeze Bridge that has occurrence of illegal request. Fixes: ca24a648f535 ("fpga: add altera freeze bridge support") Signed-off-by: Chiau Ee Chew <chiau.ee.chew(a)intel.com> Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia(a)altera.com> --- drivers/fpga/altera-freeze-bridge.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fpga/altera-freeze-bridge.c b/drivers/fpga/altera-freeze-bridge.c index 594693ff786e..23e8b2b54355 100644 --- a/drivers/fpga/altera-freeze-bridge.c +++ b/drivers/fpga/altera-freeze-bridge.c @@ -52,7 +52,7 @@ static int altera_freeze_br_req_ack(struct altera_freeze_br_data *priv, if (illegal) { dev_err(dev, "illegal request detected 0x%x", illegal); - writel(1, csr_illegal_req_addr); + writel(illegal, csr_illegal_req_addr); illegal = readl(csr_illegal_req_addr); if (illegal) -- 2.19.0

7 months, 4 weeks

2
1
0 0

[PATCH net v3] qlcnic: fix memory leak issues in qlcnic_sriov_common.c

by Haoxiang Li

Add qlcnic_sriov_free_vlans() in qlcnic_sriov_alloc_vlans() if any sriov_vlans fails to be allocated. Add qlcnic_sriov_free_vlans() to free the memory allocated by qlcnic_sriov_alloc_vlans() if "sriov->allowed_vlans" fails to be allocated. Fixes: 91b7282b613d ("qlcnic: Support VLAN id config.") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- Changes in v3: - Handle allocation errors in qlcnic_sriov_alloc_vlans() - Modify the patch title and description. There's one more thing I'm confused about: I'm not sure if the fixes-tag is correct, because I noticed that the two modifications correspond to different commits. Should I split them into two separate patch submissions? Thanks, Paolo! Changes in v2: - Add qlcnic_sriov_free_vlans() if qlcnic_sriov_alloc_vlans() fails. - Modify the patch description. vf_info was allocated by kcalloc, no need to do more checks cause kfree(NULL) is safe. Thanks, Paolo! --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c index f9dd50152b1e..28d24d59efb8 100644 --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c @@ -454,8 +454,10 @@ static int qlcnic_sriov_set_guest_vlan_mode(struct qlcnic_adapter *adapter, num_vlans = sriov->num_allowed_vlans; sriov->allowed_vlans = kcalloc(num_vlans, sizeof(u16), GFP_KERNEL); - if (!sriov->allowed_vlans) + if (!sriov->allowed_vlans) { + qlcnic_sriov_free_vlans(adapter); return -ENOMEM; + } vlans = (u16 *)&cmd->rsp.arg[3]; for (i = 0; i < num_vlans; i++) @@ -2167,8 +2169,10 @@ int qlcnic_sriov_alloc_vlans(struct qlcnic_adapter *adapter) vf = &sriov->vf_info[i]; vf->sriov_vlans = kcalloc(sriov->num_allowed_vlans, sizeof(*vf->sriov_vlans), GFP_KERNEL); - if (!vf->sriov_vlans) + if (!vf->sriov_vlans) { + qlcnic_sriov_free_vlans(adapter); return -ENOMEM; + } } return 0; -- 2.25.1

7 months, 4 weeks

2
1
0 0

[REGRESSION] stable-rc/linux-5.10.y: (build) in vmlinux (Makefile:1212) [logspec:kbuild,kbuild.other]

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: --- in vmlinux (Makefile:1212) [logspec:kbuild,kbuild.other] --- - dashboard: https://d.kernelci.org/issue/maestro:d5c2be698989c7de46471109aae8df0339b713… - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: a0e8dfa03993fda7b4d4b696c50f69726522abba Log excerpt: ===================================================== .lds In file included from ./include/linux/kernel.h:15, net/ipv6/udp.c: In function ‘udp_v6_send_skb’: ./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast ./include/linux/minmax.h:26:18: note: in expansion of macro ‘__typecheck’ ./include/linux/minmax.h:36:31: note: in expansion of macro ‘__safe_cmp’ ./include/linux/minmax.h:45:25: note: in expansion of macro ‘__careful_cmp’ net/ipv6/udp.c:1213:28: note: in expansion of macro ‘min’ In file included from ./include/linux/uaccess.h:7, net/ipv4/udp.c: In function ‘udp_send_skb’: ./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast ./include/linux/minmax.h:26:18: note: in expansion of macro ‘__typecheck’ ./include/linux/minmax.h:36:31: note: in expansion of macro ‘__safe_cmp’ ./include/linux/minmax.h:45:25: note: in expansion of macro ‘__careful_cmp’ net/ipv4/udp.c:926:28: note: in expansion of macro ‘min’ FAILED unresolved symbol filp_close ===================================================== # Builds where the incident occurred: ## cros://chromeos-5.10/x86_64/chromeos-amd-stoneyridge.flavour.config+lab-setup+x86-board+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y on (x86_64): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:67ceffea18018371957ebdc0 #kernelci issue maestro:d5c2be698989c7de46471109aae8df0339b713c1 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

7 months, 4 weeks

2
1
0 0

queue-5.10: Panic on shutdown at platform_shutdown+0x9

by Chuck Lever

Hi - For the past 3-4 days, NFSD CI runs on queue-5.10.y have been failing. I looked into it today, and the test guest fails to reboot because it panics during a reboot shutdown: [ 146.793087] BUG: unable to handle page fault for address: ffffffffffffffe8 [ 146.793918] #PF: supervisor read access in kernel mode [ 146.794544] #PF: error_code(0x0000) - not-present page [ 146.795172] PGD 3d5c14067 P4D 3d5c15067 PUD 3d5c17067 PMD 0 [ 146.795865] Oops: 0000 [#1] SMP NOPTI [ 146.796326] CPU: 3 PID: 1 Comm: systemd-shutdow Not tainted 5.10.234-g99349f441fe1 #1 [ 146.797256] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 146.798267] RIP: 0010:platform_shutdown+0x9/0x20 [ 146.798838] Code: b7 46 08 c3 cc cc cc cc 31 c0 83 bf a8 02 00 00 ff 75 ec c3 cc cc cc cc 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 68 <48> 8b 40 e8 48 85 c0 74 09 48 83 ef 10 ff e0 0f 1f 00 c3 cc cc cc [ 146.801012] RSP: 0018:ff7f86f440013de0 EFLAGS: 00010246 [ 146.801651] RAX: 0000000000000000 RBX: ff4f0637469df418 RCX: 0000000000000000 [ 146.802500] RDX: 0000000000000001 RSI: ff4f0637469df418 RDI: ff4f0637469df410 [ 146.803350] RBP: ffffffffb2e79220 R08: ff4f0637469dd808 R09: ffffffffb2c5c698 [ 146.804203] R10: 0000000000000000 R11: 0000000000000000 R12: ff4f0637469df410 [ 146.805059] R13: ff4f0637469df490 R14: 00000000fee1dead R15: 0000000000000000 [ 146.805909] FS: 00007f4e7ecc6b80(0000) GS:ff4f063aafd80000(0000) knlGS:0000000000000000 [ 146.806866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 146.807558] CR2: ffffffffffffffe8 CR3: 000000010ecb2001 CR4: 0000000000771ee0 [ 146.808412] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 146.809262] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 146.810109] PKRU: 55555554 [ 146.810460] Call Trace: [ 146.810791] ? __die_body.cold+0x1a/0x1f [ 146.811282] ? no_context.constprop.0+0xf8/0x2f0 [ 146.811854] ? exc_page_fault+0xc5/0x150 [ 146.812342] ? asm_exc_page_fault+0x1e/0x30 [ 146.812862] ? platform_shutdown+0x9/0x20 [ 146.813362] device_shutdown+0x158/0x1c0 [ 146.813853] __do_sys_reboot.cold+0x2f/0x5b [ 146.814370] ? vfs_writev+0x9b/0x110 [ 146.814824] ? do_writev+0x57/0xf0 [ 146.815254] do_syscall_64+0x30/0x40 [ 146.815708] entry_SYSCALL_64_after_hwframe+0x67/0xd1 Let me know how to further assist. -- Chuck Lever

7 months, 4 weeks

3
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2025