Commit 84193c07105c ("workqueue: Generalize unbound CPU pods")
inadvertently introduced another call to alloc_workqueue_attrs()
overriding the pointer returned by a previous alloc_workqueue_attrs() a
few lines up in workqueue_init_early(). This leads to a kmemleak report:

unreferenced object 0xffff000040015000 (size 96):
  comm "swapper/0", pid 0, jiffies 4294892296 (age 163.956s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<000000004cec0d50>] __kmem_cache_alloc_node+0x1c4/0x288
    [<0000000083361c2a>] kmalloc_trace+0x20/0x2c
    [<000000005ca61f11>] workqueue_init_early+0xe4/0x538
    [<000000004e6ea358>] start_kernel+0x23c/0x5ec
    [<00000000aea9761e>] __primary_switched+0xbc/0xc4

Remove the first allocation.

Fixes: 84193c07105c ("workqueue: Generalize unbound CPU pods")
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Tejun Heo <tj@kernel.org>
---

I've seen this mentioned by Sandeep as well but I couldn't find a patch,
so here it is.

https://lore.kernel.org/r/CAB=BE-S=cxewXu7nqJY1DC5w9Bapar_C0cTjpZOQ-Qd5GGwYyw@mail.gmail.com/

 kernel/workqueue.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c85825e17df8..43ab8399b72b 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -6524,9 +6524,6 @@ void __init workqueue_init_early(void)
 
 	pwq_cache = KMEM_CACHE(pool_workqueue, SLAB_PANIC);
 
-	wq_update_pod_attrs_buf = alloc_workqueue_attrs();
-	BUG_ON(!wq_update_pod_attrs_buf);
-
 	/* initialize WQ_AFFN_SYSTEM pods */
 	pt->pod_cpus = kcalloc(1, sizeof(pt->pod_cpus[0]), GFP_KERNEL);
 	pt->pod_node = kcalloc(1, sizeof(pt->pod_node[0]), GFP_KERNEL);

On Wed, Sep 06, 2023 at 06:39:04PM +0100, Catalin Marinas wrote:
> Commit 84193c07105c ("workqueue: Generalize unbound CPU pods")
> inadvertently introduced another call to alloc_workqueue_attrs()
> overriding the pointer returned by a previous alloc_workqueue_attrs() a
> few lines up in workqueue_init_early(). This leads to a kmemleak report:
> 
> unreferenced object 0xffff000040015000 (size 96):
>   comm "swapper/0", pid 0, jiffies 4294892296 (age 163.956s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00  ................
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<000000004cec0d50>] __kmem_cache_alloc_node+0x1c4/0x288
>     [<0000000083361c2a>] kmalloc_trace+0x20/0x2c
>     [<000000005ca61f11>] workqueue_init_early+0xe4/0x538
>     [<000000004e6ea358>] start_kernel+0x23c/0x5ec
>     [<00000000aea9761e>] __primary_switched+0xbc/0xc4
> 
> Remove the first allocation.
> 
> Fixes: 84193c07105c ("workqueue: Generalize unbound CPU pods")
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Tejun Heo <tj@kernel.org>

Another version of this patch has been applied to wq/for-6.6-fixes.

Thanks.

-- 
tejun

Hi Catalin,

On 06/09/2023 19:39, Catalin Marinas wrote:
> Commit 84193c07105c ("workqueue: Generalize unbound CPU pods")
> inadvertently introduced another call to alloc_workqueue_attrs()
> overriding the pointer returned by a previous alloc_workqueue_attrs() a
> few lines up in workqueue_init_early(). This leads to a kmemleak report:
> 
> unreferenced object 0xffff000040015000 (size 96):
>   comm "swapper/0", pid 0, jiffies 4294892296 (age 163.956s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00  ................
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<000000004cec0d50>] __kmem_cache_alloc_node+0x1c4/0x288
>     [<0000000083361c2a>] kmalloc_trace+0x20/0x2c
>     [<000000005ca61f11>] workqueue_init_early+0xe4/0x538
>     [<000000004e6ea358>] start_kernel+0x23c/0x5ec
>     [<00000000aea9761e>] __primary_switched+0xbc/0xc4
> 
> Remove the first allocation.

Thank you for having shared this patch!

We had the same issue when validating MPTCP tree and your patch fixes
the problem on our side:

Tested-by: Matthieu Baerts <matthieu.baerts@tessares.net>

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Thank you Catalin for following up!

Reviewed-by: Sandeep Dhavale <dhavale@google.com>

Thanks,
Sandeep.