From: "chenjun (AM)" <chenjun102@huawei.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"Xiangrui (Euler)" <rui.xiang@huawei.com>
Subject: Re: [PATCH] trace: Fix a kmemleak noise
Date: Thu, 25 Nov 2021 01:48:20 +0000 [thread overview]
Message-ID: <c02fa0f22fc94a8d8efb374ceb19e5c2@huawei.com> (raw)
In-Reply-To: 20211124101616.618ee8f2@gandalf.local.home
在 2021/11/24 23:16, Steven Rostedt 写道:
Hi
> On Wed, 24 Nov 2021 14:08:01 +0000
> Chen Jun <chenjun102@huawei.com> wrote:
>
>> The reason is elts->pages[i] is alloced by get_zeroed_page.
>> and kmemleak will not scan the area alloced by get_zeroed_page.
>> The address stored in elts->pages will be regarded as leaked.
>
> Why doesn't kmemleak scan get_zeroed_page? And if that's the case, how does
> all the other locations in the kernel that call get_zeroed_page handle this?
> I think in most cases, the page do not contain pointers. But I am not
sure. Maybe we should better ask Catalin.
In block/blk-mq.c
blk_mq_alloc_rqs
.
page = alloc_pages_node(node,..
.
p = page_address(page);
/*$
* Allow kmemleak to scan these pages as they contain pointers
* to additional allocations like via ops->init_request().
*/$
kmemleak_alloc(p, order_to_size(this_order), 1, GFP_NOIO);
In lib/scatterlist.c
static struct scatterlist *sg_kmalloc(unsigned int nents, gfp_t gfp_mask)
{
if (nents == SG_MAX_SINGLE_ALLOC) {
/*
* Kmemleak doesn't track page allocations as they are not
* commonly used (in a raw form) for kernel data structures.
* As we chain together a list of pages and then a normal
* kmalloc (tracked by kmemleak), in order to for that last
* allocation not to become decoupled (and thus a
* false-positive) we need to inform kmemleak of all the
* intermediate allocations.
*/
void *ptr = (void *) __get_free_page(gfp_mask);
kmemleak_alloc(ptr, PAGE_SIZE, 1, gfp_mask);
return ptr;
.
> -- Steve
>
--
Regards
Chen Jun
prev parent reply other threads:[~2021-11-25 1:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-24 14:08 [PATCH] trace: Fix a kmemleak noise Chen Jun
2021-11-24 15:16 ` Steven Rostedt
2021-11-25 1:48 ` chenjun (AM) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c02fa0f22fc94a8d8efb374ceb19e5c2@huawei.com \
--to=chenjun102@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=rui.xiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.