linux-kernel - Re: [regression] tracing: kmemleak warning in allocate_cmdlines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87mss3njvj.fsf@kernel.org>
Date: Wed, 14 Feb 2024 17:30:40 +0200
From: Kalle Valo <kvalo@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: regressions@...ts.linux.dev,  linux-kernel@...r.kernel.org,
  linux-trace-kernel@...r.kernel.org,  Jeff Johnson
 <quic_jjohnson@...cinc.com>
Subject: Re: [regression] tracing: kmemleak warning in
 allocate_cmdlines_buffer()

Steven Rostedt <rostedt@...dmis.org> writes:

> On Wed, 14 Feb 2024 14:50:56 +0200
> Kalle Valo <kvalo@...nel.org> wrote:
>
>> Hi Steven,
>> 
>> I upgraded our ath11k test setup to v6.8-rc4 and noticed a new kmemleak
>> warning in the log:
>
> Thanks for the report.
>
>> 
>> unreferenced object 0xffff8881010c8000 (size 32760):
>>   comm "swapper", pid 0, jiffies 4294667296
>>   hex dump (first 32 bytes):
>>     ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
>>     ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
>>   backtrace (crc ae6ec1b9):
>>     [<ffffffff86722405>] kmemleak_alloc+0x45/0x80
>>     [<ffffffff8414028d>] __kmalloc_large_node+0x10d/0x190
>>     [<ffffffff84146ab1>] __kmalloc+0x3b1/0x4c0
>>     [<ffffffff83ed7103>] allocate_cmdlines_buffer+0x113/0x230
>>     [<ffffffff88649c34>] tracer_alloc_buffers.isra.0+0x124/0x460
>>     [<ffffffff8864a174>] early_trace_init+0x14/0xa0
>>     [<ffffffff885dd5ae>] start_kernel+0x12e/0x3c0
>>     [<ffffffff885f5758>] x86_64_start_reservations+0x18/0x30
>>     [<ffffffff885f582b>] x86_64_start_kernel+0x7b/0x80
>>     [<ffffffff83a001c3>] secondary_startup_64_no_verify+0x15e/0x16b
>> 
>> I don't see this warning in v6.8-rc3 and also reverting commit
>> 44dc5c41b5b1 ("tracing: Fix wasted memory in saved_cmdlines logic")
>> makes the warning go away. Let me know if you need more info or help
>> with testing, I see the warning every time so it's easy to reproduce.
>> 
>
> Hmm, I changed the code a bit and I wonder if this is a false positive?
>
> Instead of allocating the structure via kmalloc() I now use it as part of a
> page.
>
> That is, the old code had:
>
>         s = kmalloc(sizeof(*s), GFP_KERNEL);
> 	s->saved_cmdlines = kmalloc_array(TASK_COMM_LEN, val, GFP_KERNEL);
>
> Where as the new code has:
>
> 	orig_size = sizeof(*s) + val * TASK_COMM_LEN;
> 	order = get_order(orig_size);
> 	size = 1 << (order + PAGE_SHIFT);
> 	page = alloc_pages(GFP_KERNEL, order);
> 	if (!page)
> 		return NULL;
>
> 	s = page_address(page);
> 	memset(s, 0, sizeof(*s));
>
> 	s->saved_cmdlines = kmalloc_array(TASK_COMM_LEN, val, GFP_KERNEL);
>
>
> Does kmemleak handle structures that are assigned to alloc_pages()
> allocations? I don't think it does.
>
> I think we need to inform kmemleak about this. Does the following patch fix
> this for you?

It does, thank you!

Tested-by: Kalle Valo <kvalo@...nel.org>

> diff --git a/kernel/trace/trace_sched_switch.c b/kernel/trace/trace_sched_switch.c
> index e4fbcc3bede5..de4182224ea2 100644
> --- a/kernel/trace/trace_sched_switch.c
> +++ b/kernel/trace/trace_sched_switch.c

Although the patch didn't apply for me as in my tree the functions are
in kernel/trace/trace.c. I don't know what happened so as a quick hack I
just manually added the three lines to my version of trace.c. Let me
know if there's a git tree or branch you would like me to test, I can do
that easily.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches