March 2025 - Linux-stable-mirror

[PATCH v2] kbuild: exclude .rodata.(cst|str)* when building ranges

by Kris Van Hees

The .rodata.(cst|str)* sections are often resized during the final linking and since these sections do not cover actual symbols there is no need to include them in the modules.builtin.ranges data. When these sections were included in processing and resizing occurred, modules were reported with ranges that extended beyond their true end, causing subsequent symbols (in address order) to be associated with the wrong module. Fixes: 5f5e7344322f ("kbuild: generate offset range data for builtin modules") Cc: stable(a)vger.kernel.org Signed-off-by: Kris Van Hees <kris.van.hees(a)oracle.com> Reviewed-by: Jack Vogel <jack.vogel(a)oracle.com> --- scripts/generate_builtin_ranges.awk | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/scripts/generate_builtin_ranges.awk b/scripts/generate_builtin_ranges.awk index b9ec761b3bef..d4bd5c2b998c 100755 --- a/scripts/generate_builtin_ranges.awk +++ b/scripts/generate_builtin_ranges.awk @@ -282,6 +282,11 @@ ARGIND == 2 && !anchor && NF == 2 && $1 ~ /^0x/ && $2 !~ /^0x/ { # section. # ARGIND == 2 && sect && NF == 4 && /^ [^ \*]/ && !($1 in sect_addend) { + # There are a few sections with constant data (without symbols) that + # can get resized during linking, so it is best to ignore them. + if ($1 ~ /^\.rodata\.(cst|str)[0-9]/) + next; + if (!($1 in sect_base)) { sect_base[$1] = base; -- 2.45.2

6 months

2
1
0 0

[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

6 months

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

6 months

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

6 months

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

6 months

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) {

6 months

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

6 months

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

6 months

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

6 months

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

6 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2025