January 2025 - Linux-stable-mirror

[PATCH] media: lirc: Fix error handling in lirc_register()

by Ma Ke

When cdev_device_add() failed, calling put_device() to explicitly release dev->lirc_dev. Otherwise, it could cause the fault of the reference count. Found by code review. Cc: stable(a)vger.kernel.org Fixes: a6ddd4fecbb0 ("media: lirc: remove last remnants of lirc kapi") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/media/rc/lirc_dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c index a2257dc2f25d..ed839e15fa16 100644 --- a/drivers/media/rc/lirc_dev.c +++ b/drivers/media/rc/lirc_dev.c @@ -765,6 +765,7 @@ int lirc_register(struct rc_dev *dev) return 0; out_ida: + put_device(&dev->lirc_dev); ida_free(&lirc_ida, minor); return err; } -- 2.25.1

1 month

2
3
0 0

[PATCH] [SCSI] raid class: Fix error handling in raid_component_add

by Ma Ke

The reference count of the device incremented in device_initialize() is not decremented when device_add() fails. Add a put_device() and delete kfree() before returning from the function to decrement reference count for cleanup. Or it could cause memory leak. As comment of device_add() says, if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count. Found by code review. Cc: stable(a)vger.kernel.org Fixes: ed542bed126c ("[SCSI] raid class: handle component-add errors") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/scsi/raid_class.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/raid_class.c b/drivers/scsi/raid_class.c index 898a0bdf8df6..77c91dbf3b77 100644 --- a/drivers/scsi/raid_class.c +++ b/drivers/scsi/raid_class.c @@ -251,7 +251,7 @@ int raid_component_add(struct raid_template *r,struct device *raid_dev, list_del(&rc->node); rd->component_count--; put_device(component_dev); - kfree(rc); + put_device(&rc->dev); return err; } EXPORT_SYMBOL(raid_component_add); -- 2.25.1

1 month

1
0
0 0

[PATCH] zram: fix potential UAF of zram table

by Kairui Song

From: Kairui Song <kasong(a)tencent.com> If zram_meta_alloc failed early, it frees allocated zram->table without setting it NULL. Which will potentially cause zram_meta_free to access the table if user reset an failed and uninitialized device. Fixes: 74363ec674cb ("zram: fix uninitialized ZRAM not releasing backing device") Cc: <stable(a)vger.kernel.org> Signed-off-by: Kairui Song <kasong(a)tencent.com> --- drivers/block/zram/zram_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index 5b8e4f4171ab..70ecaee25c20 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -1465,6 +1465,7 @@ static bool zram_meta_alloc(struct zram *zram, u64 disksize) zram->mem_pool = zs_create_pool(zram->disk->disk_name); if (!zram->mem_pool) { vfree(zram->table); + zram->table = NULL; return false; } -- 2.47.1

1 month

2
1
0 0

[PATCH v3] arm64: mm: Populate vmemmap at the page level for hotplugged sections

by Zhenhua Huang

Commit c1cc1552616d ("arm64: MMU initialisation") optimizes the vmemmap to populate at the PMD section level which was suitable initially since hotplugging granule is always 128M. However, commit ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") which added 2M hotplugging granule disrupted the arm64 assumptions. Considering the vmemmap_free -> unmap_hotplug_pmd_range path, when pmd_sect() is true, the entire PMD section is cleared, even if there is other effective subsection. For example pagemap1 and pagemap2 are part of a single PMD entry and they are hot-added sequentially. Then pagemap1 is removed, vmemmap_free() will clear the entire PMD entry freeing the struct page metadata for the whole section, even though pagemap2 is still active. To address the issue, we need to prevent PMD/PUD/CONT mappings for both linear and vmemmap for non-boot sections if the size exceeds 2MB (considering sub-section is 2MB). We only permit 2MB blocks in a 4KB page configuration. Cc: stable(a)vger.kernel.org # v5.4+ Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") Signed-off-by: Zhenhua Huang <quic_zhenhuah(a)quicinc.com> --- Hi Catalin and Anshuman, Based on your review comments, I concluded below patch and tested with my setup. I have not folded patchset #2 since this patch seems to be enough for backporting.. Please see if you have further suggestions. arch/arm64/mm/mmu.c | 33 +++++++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index e2739b69e11b..2b4d23f01d85 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -42,9 +42,11 @@ #include <asm/pgalloc.h> #include <asm/kfence.h> -#define NO_BLOCK_MAPPINGS BIT(0) +#define NO_PMD_BLOCK_MAPPINGS BIT(0) #define NO_CONT_MAPPINGS BIT(1) #define NO_EXEC_MAPPINGS BIT(2) /* assumes FEAT_HPDS is not used */ +#define NO_PUD_BLOCK_MAPPINGS BIT(3) /* Hotplug case: do not want block mapping for PUD */ +#define NO_BLOCK_MAPPINGS (NO_PMD_BLOCK_MAPPINGS | NO_PUD_BLOCK_MAPPINGS) u64 kimage_voffset __ro_after_init; EXPORT_SYMBOL(kimage_voffset); @@ -254,7 +256,7 @@ static void init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end, /* try section mapping first */ if (((addr | next | phys) & ~PMD_MASK) == 0 && - (flags & NO_BLOCK_MAPPINGS) == 0) { + (flags & NO_PMD_BLOCK_MAPPINGS) == 0) { pmd_set_huge(pmdp, phys, prot); /* @@ -356,10 +358,11 @@ static void alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end, /* * For 4K granule only, attempt to put down a 1GB block + * Hotplug case: do not attempt 1GB block */ if (pud_sect_supported() && ((addr | next | phys) & ~PUD_MASK) == 0 && - (flags & NO_BLOCK_MAPPINGS) == 0) { + (flags & NO_PUD_BLOCK_MAPPINGS) == 0) { pud_set_huge(pudp, phys, prot); /* @@ -1175,9 +1178,16 @@ int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node, int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, struct vmem_altmap *altmap) { + unsigned long start_pfn; + struct mem_section *ms; + WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END)); - if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES)) + start_pfn = page_to_pfn((struct page *)start); + ms = __pfn_to_section(start_pfn); + + /* Hotplugged section not support hugepages */ + if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES) || !early_section(ms)) return vmemmap_populate_basepages(start, end, node, altmap); else return vmemmap_populate_hugepages(start, end, node, altmap); @@ -1339,9 +1349,24 @@ int arch_add_memory(int nid, u64 start, u64 size, struct mhp_params *params) { int ret, flags = NO_EXEC_MAPPINGS; + unsigned long start_pfn = page_to_pfn((struct page *)start); + struct mem_section *ms = __pfn_to_section(start_pfn); VM_BUG_ON(!mhp_range_allowed(start, size, true)); + /* Should not be invoked by early section */ + WARN_ON(early_section(ms)); + + if (IS_ENABLED(CONFIG_ARM64_4K_PAGES)) + /* + * As per subsection granule is 2M, allow PMD block mapping in + * case 4K PAGES. + * Other cases forbid section mapping. + */ + flags |= NO_PUD_BLOCK_MAPPINGS | NO_CONT_MAPPINGS; + else + flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS; + if (can_set_direct_map()) flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS; -- 2.25.1

1 month

2
2
0 0

[merged] revert-vmstat-disable-vmstat_work-on-vmstat_cpu_down_prep.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: revert "vmstat: disable vmstat_work on vmstat_cpu_down_prep()" has been removed from the -mm tree. Its filename was revert-vmstat-disable-vmstat_work-on-vmstat_cpu_down_prep.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Andrew Morton <akpm(a)linux-foundation.org> Subject: revert "vmstat: disable vmstat_work on vmstat_cpu_down_prep()" Date: Mon Jan 6 06:24:12 PM PST 2025 Revert adcfb264c3ed ("vmstat: disable vmstat_work on vmstat_cpu_down_prep()") due to "workqueue: work disable count underflowed" WARNings. Fixes: adcfb264c3ed ("vmstat: disable vmstat_work on vmstat_cpu_down_prep()") Reported-by: Borislav Petkov <bp(a)alien8.de> Reported-by: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Greg KH <greg(a)kroah.com> Cc: Koichiro Den <koichiro.den(a)canonical.com> Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmstat.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/mm/vmstat.c~revert-vmstat-disable-vmstat_work-on-vmstat_cpu_down_prep +++ a/mm/vmstat.c @@ -2148,14 +2148,13 @@ static int vmstat_cpu_online(unsigned in if (!node_state(cpu_to_node(cpu), N_CPU)) { node_set_state(cpu_to_node(cpu), N_CPU); } - enable_delayed_work(&per_cpu(vmstat_work, cpu)); return 0; } static int vmstat_cpu_down_prep(unsigned int cpu) { - disable_delayed_work_sync(&per_cpu(vmstat_work, cpu)); + cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu)); return 0; } _ Patches currently in -mm which might be from akpm(a)linux-foundation.org are mm-swap_cgroup-allocate-swap_cgroup-map-using-vcalloc-fix.patch mm-page_alloc-add-some-detailed-comments-in-can_steal_fallback-fix.patch mm-introduce-mmap_lock_speculate_try_beginretry-fix.patch mm-damon-tests-vaddr-kunith-reduce-stack-consumption.patch mm-damon-tests-vaddr-kunith-reduce-stack-consumption-fix.patch mm-remove-an-avoidable-load-of-page-refcount-in-page_ref_add_unless-fix.patch mm-fix-outdated-incorrect-code-comments-for-handle_mm_fault-fix.patch mm-huge_memoryc-rename-shadowed-local.patch replace-free-hugepage-folios-after-migration-fix.patch xarray-port-tests-to-kunit-fix.patch checkpatch-check-return-of-git_commit_info-fix.patch fault-inject-use-prandom-where-cryptographically-secure-randomness-is-not-needed-fix.patch

1 month

1
0
0 0

Re: Linux 6.13-rc6

by Borislav Petkov

On Sun, Jan 05, 2025 at 02:20:54PM -0800, Linus Torvalds wrote: > So we had a slight pickup in commits this last week, but as expected > and hoped for, things were still pretty quiet. About twice as many > commits as the holiday week, but that's still not all that many. > > I expect things will start becoming more normal now that people are > back from the holidays and are starting to recover and wake up from > their food comas. > > In the meantime, below is the shortlog for the last week. Nothing > particularly stands out, the changes are dominated by various driver > updates (gpu, rdma and networking), with a random smattering of fixes > elsewhere. Something not well baked managed to sneak in and it is tagged for stable: adcfb264c3ed ("vmstat: disable vmstat_work on vmstat_cpu_down_prep()") Reverting it fixes the warn splat below. [ 0.310373] smpboot: x86: Booting SMP configuration: [ 0.311074] .... node #0, CPUs: #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 [ 0.313798] ------------[ cut here ]------------ [ 0.317530] workqueue: work disable count underflowed [ 0.317530] WARNING: CPU: 1 PID: 21 at kernel/workqueue.c:4317 enable_work+0xa4/0xb0 [ 0.317530] Modules linked in: [ 0.317530] CPU: 1 UID: 0 PID: 21 Comm: cpuhp/1 Not tainted 6.13.0-rc6 #11 [ 0.317530] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2023.11-8 02/21/2024 [ 0.317530] RIP: 0010:enable_work+0xa4/0xb0 [ 0.317530] Code: c0 48 83 c4 18 5b 5d e9 ca 25 9f 00 80 3d 0a c7 48 08 00 75 b3 c6 05 01 c7 48 08 01 90 48 c7 c7 c8 eb 1d 82 e8 5d 77 fd ff 90 <0f> 0b 90 90 eb 98 90 0f 0b 90 eb b1 90 90 90 90 90 90 90 90 90 90 [ 0.317530] RSP: 0018:ffffc90000137e18 EFLAGS: 00010082 [ 0.317530] RAX: 0000000000000029 RBX: ffff88807d66dda0 RCX: 00000000ffefffff [ 0.317530] RDX: 0000000000000001 RSI: ffffc90000137ce0 RDI: 0000000000000001 [ 0.317530] RBP: 0000000000000000 R08: 00000000ffefffff R09: 0000000000000058 [ 0.317530] R10: 0000000000000000 R11: ffffffff8244df00 R12: 0000000000000000 [ 0.317530] R13: ffff88807d6604e0 R14: ffffffff812439f0 R15: ffff88807d660508 [ 0.317530] FS: 0000000000000000(0000) GS:ffff88807d640000(0000) knlGS:0000000000000000 [ 0.317530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.317530] CR2: 0000000000000000 CR3: 0000000002c1a000 CR4: 00000000003506f0 [ 0.317530] Call Trace: [ 0.317530] <TASK> [ 0.317530] ? __warn+0xa0/0x160 [ 0.317530] ? enable_work+0xa4/0xb0 [ 0.317530] ? report_bug+0x18c/0x1c0 [ 0.317530] ? handle_bug+0x54/0x90 [ 0.317530] ? exc_invalid_op+0x1b/0x80 [ 0.317530] ? asm_exc_invalid_op+0x1a/0x20 [ 0.317530] ? __pfx_vmstat_cpu_online+0x10/0x10 [ 0.317530] ? enable_work+0xa4/0xb0 [ 0.317530] ? enable_work+0xa3/0xb0 [ 0.317530] vmstat_cpu_online+0x61/0x80 [ 0.317530] cpuhp_invoke_callback+0x10f/0x480 [ 0.317530] ? srso_return_thunk+0x5/0x5f [ 0.317530] cpuhp_thread_fun+0xd4/0x160 [ 0.317530] smpboot_thread_fn+0xdd/0x1f0 [ 0.317530] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 0.317530] kthread+0xca/0xf0 [ 0.317530] ? __pfx_kthread+0x10/0x10 [ 0.317530] ret_from_fork+0x50/0x60 [ 0.317530] ? __pfx_kthread+0x10/0x10 [ 0.317530] ret_from_fork_asm+0x1a/0x30 [ 0.317530] </TASK> [ 0.317530] ---[ end trace 0000000000000000 ]--- [ 0.377680] smp: Brought up 1 node, 16 CPUs [ 0.378345] smpboot: Total of 16 processors activated (118393.24 BogoMIPS) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

1 month

6
6
0 0

[merged] fs-proc-do_task_stat-fix-esp-not-readable-during-coredump.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: fs/proc: do_task_stat: fix ESP not readable during coredump has been removed from the -mm tree. Its filename was fs-proc-do_task_stat-fix-esp-not-readable-during-coredump.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Nam Cao <namcao(a)linutronix.de> Subject: fs/proc: do_task_stat: fix ESP not readable during coredump Date: Thu, 2 Jan 2025 09:22:56 +0100 The field "eip" (instruction pointer) and "esp" (stack pointer) of a task can be read from /proc/PID/stat. These fields can be interesting for coredump. However, these fields were disabled by commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in /proc/PID/stat"), because it is generally unsafe to do so. But it is safe for a coredumping process, and therefore exceptions were made: - for a coredumping thread by commit fd7d56270b52 ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping"). - for all other threads in a coredumping process by commit cb8f381f1613 ("fs/proc/array.c: allow reporting eip/esp for all coredumping threads"). The above two commits check the PF_DUMPCORE flag to determine a coredump thread and the PF_EXITING flag for the other threads. Unfortunately, commit 92307383082d ("coredump: Don't perform any cleanups before dumping core") moved coredump to happen earlier and before PF_EXITING is set. Thus, checking PF_EXITING is no longer the correct way to determine threads in a coredumping process. Instead of PF_EXITING, use PF_POSTCOREDUMP to determine the other threads. Checking of PF_EXITING was added for coredumping, so it probably can now be removed. But it doesn't hurt to keep. Link: https://lkml.kernel.org/r/d89af63d478d6c64cc46a01420b46fd6eb147d6f.17358057… Fixes: 92307383082d ("coredump: Don't perform any cleanups before dumping core") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Acked-by: Kees Cook <kees(a)kernel.org> Cc: Eric W. Biederman <ebiederm(a)xmission.com> Cc: Dylan Hatch <dylanbhatch(a)google.com> Cc: John Ogness <john.ogness(a)linutronix.de> Cc: Shuah Khan <shuah(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/proc/array.c~fs-proc-do_task_stat-fix-esp-not-readable-during-coredump +++ a/fs/proc/array.c @@ -500,7 +500,7 @@ static int do_task_stat(struct seq_file * a program is not able to use ptrace(2) in that case. It is * safe because the task has stopped executing permanently. */ - if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE))) { + if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE|PF_POSTCOREDUMP))) { if (try_get_task_stack(task)) { eip = KSTK_EIP(task); esp = KSTK_ESP(task); _ Patches currently in -mm which might be from namcao(a)linutronix.de are

1 month

1
0
0 0

+ hugetlb-fix-null-pointer-dereference-in-trace_hugetlbfs_alloc_inode.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: hugetlb: fix NULL pointer dereference in trace_hugetlbfs_alloc_inode has been added to the -mm mm-hotfixes-unstable branch. Its filename is hugetlb-fix-null-pointer-dereference-in-trace_hugetlbfs_alloc_inode.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Muchun Song <songmuchun(a)bytedance.com> Subject: hugetlb: fix NULL pointer dereference in trace_hugetlbfs_alloc_inode Date: Mon, 6 Jan 2025 11:31:17 +0800 hugetlb_file_setup() will pass a NULL @dir to hugetlbfs_get_inode(), so we will access a NULL pointer for @dir. Fix it and set __entry->dr to 0 if @dir is NULL. Because ->i_ino cannot be 0 (see get_next_ino()), there is no confusing if user sees a 0 inode number. Link: https://lkml.kernel.org/r/20250106033118.4640-1-songmuchun@bytedance.com Fixes: 318580ad7f28 ("hugetlbfs: support tracepoint") Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Reported-by: Cheung Wall <zzqq0103.hey(a)gmail.com> Closes: https://lore.kernel.org/linux-mm/02858D60-43C1-4863-A84F-3C76A8AF1F15@linux… Reviewed-by: Hongbo Li <lihongbo22(a)huawei.com> Cc: cheung wall <zzqq0103.hey(a)gmail.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/trace/events/hugetlbfs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/include/trace/events/hugetlbfs.h~hugetlb-fix-null-pointer-dereference-in-trace_hugetlbfs_alloc_inode +++ a/include/trace/events/hugetlbfs.h @@ -23,7 +23,7 @@ TRACE_EVENT(hugetlbfs_alloc_inode, TP_fast_assign( __entry->dev = inode->i_sb->s_dev; __entry->ino = inode->i_ino; - __entry->dir = dir->i_ino; + __entry->dir = dir ? dir->i_ino : 0; __entry->mode = mode; ), _ Patches currently in -mm which might be from songmuchun(a)bytedance.com are hugetlb-fix-null-pointer-dereference-in-trace_hugetlbfs_alloc_inode.patch

1 month

1
0
0 0

+ revert-vmstat-disable-vmstat_work-on-vmstat_cpu_down_prep.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: revert "vmstat: disable vmstat_work on vmstat_cpu_down_prep()" has been added to the -mm mm-hotfixes-unstable branch. Its filename is revert-vmstat-disable-vmstat_work-on-vmstat_cpu_down_prep.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Andrew Morton <akpm(a)linux-foundation.org> Subject: revert "vmstat: disable vmstat_work on vmstat_cpu_down_prep()" Date: Mon Jan 6 06:24:12 PM PST 2025 Revert adcfb264c3ed ("vmstat: disable vmstat_work on vmstat_cpu_down_prep()") due to "workqueue: work disable count underflowed" WARNings. Fixes: adcfb264c3ed ("vmstat: disable vmstat_work on vmstat_cpu_down_prep()") Reported-by: Borislav Petkov <bp(a)alien8.de> Reported-by: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Greg KH <greg(a)kroah.com> Cc: Koichiro Den <koichiro.den(a)canonical.com> Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmstat.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/mm/vmstat.c~revert-vmstat-disable-vmstat_work-on-vmstat_cpu_down_prep +++ a/mm/vmstat.c @@ -2148,14 +2148,13 @@ static int vmstat_cpu_online(unsigned in if (!node_state(cpu_to_node(cpu), N_CPU)) { node_set_state(cpu_to_node(cpu), N_CPU); } - enable_delayed_work(&per_cpu(vmstat_work, cpu)); return 0; } static int vmstat_cpu_down_prep(unsigned int cpu) { - disable_delayed_work_sync(&per_cpu(vmstat_work, cpu)); + cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu)); return 0; } _ Patches currently in -mm which might be from akpm(a)linux-foundation.org are revert-vmstat-disable-vmstat_work-on-vmstat_cpu_down_prep.patch mm-swap_cgroup-allocate-swap_cgroup-map-using-vcalloc-fix.patch mm-page_alloc-add-some-detailed-comments-in-can_steal_fallback-fix.patch mm-introduce-mmap_lock_speculate_try_beginretry-fix.patch mm-damon-tests-vaddr-kunith-reduce-stack-consumption.patch mm-damon-tests-vaddr-kunith-reduce-stack-consumption-fix.patch mm-remove-an-avoidable-load-of-page-refcount-in-page_ref_add_unless-fix.patch mm-fix-outdated-incorrect-code-comments-for-handle_mm_fault-fix.patch mm-huge_memoryc-rename-shadowed-local.patch replace-free-hugepage-folios-after-migration-fix.patch xarray-port-tests-to-kunit-fix.patch checkpatch-check-return-of-git_commit_info-fix.patch fault-inject-use-prandom-where-cryptographically-secure-randomness-is-not-needed-fix.patch

1 month

1
0
0 0

[PATCH v2] misc: microchip: pci1xxxx: Fix possible double free in error handling path

by Ma Ke

When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), the callback function gp_auxiliary_device_release() calls kfree() to free memory. Do not call kfree() again in the error handling path. Fix this by skipping the redundant kfree(). Found by code review. Cc: stable(a)vger.kernel.org Fixes: 393fc2f5948f ("misc: microchip: pci1xxxx: load auxiliary bus driver for the PIO function in the multi-function endpoint of pci1xxxx device.") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - modified the patch omitted. --- drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c b/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c index 32af2b14ff34..de75d89ef53e 100644 --- a/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c +++ b/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c @@ -111,6 +111,7 @@ static int gp_aux_bus_probe(struct pci_dev *pdev, const struct pci_device_id *id err_aux_dev_add_1: auxiliary_device_uninit(&aux_bus->aux_device_wrapper[1]->aux_dev); + goto err_aux_dev_add_0; err_aux_dev_init_1: ida_free(&gp_client_ida, aux_bus->aux_device_wrapper[1]->aux_dev.id); @@ -120,6 +121,7 @@ static int gp_aux_bus_probe(struct pci_dev *pdev, const struct pci_device_id *id err_aux_dev_add_0: auxiliary_device_uninit(&aux_bus->aux_device_wrapper[0]->aux_dev); + goto err_ret; err_aux_dev_init_0: ida_free(&gp_client_ida, aux_bus->aux_device_wrapper[0]->aux_dev.id); @@ -127,6 +129,7 @@ static int gp_aux_bus_probe(struct pci_dev *pdev, const struct pci_device_id *id err_ida_alloc_0: kfree(aux_bus->aux_device_wrapper[0]); +err_ret: return retval; } -- 2.25.1

1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2025