archive mirror
 help / color / mirror / Atom feed
From: Rustam Kovhaev <>
To: Dmitry Vyukov <>
Cc: Catalin Marinas <>,
	Andrew Morton <>,
	Linux-MM <>,
	LKML <>,
	Greg Kroah-Hartman <>
Subject: Re: kmemleak memory scanning
Date: Wed, 16 Jun 2021 11:25:22 -0700	[thread overview]
Message-ID: <YMpCEu9yM5Ppj5jj@nuc10> (raw)
In-Reply-To: <>

On Tue, Jun 15, 2021 at 07:15:24AM +0200, Dmitry Vyukov wrote:
> On Mon, Jun 14, 2021 at 10:31 PM Rustam Kovhaev <> wrote:
> >
> > hello Catalin, Andrew!
> >
> > while troubleshooting a false positive syzbot kmemleak report i have
> > noticed an interesting behavior in kmemleak and i wonder whether it is
> > behavior by design and should be documented, or maybe something to
> > improve.
> > apologies if some of the questions do not make sense, i am still going
> > through kmemleak code..
> >
> > a) kmemleak scans struct page (kmemleak.c:1462), but it does not scan
> > the actual contents (page_address(page)) of the page.
> > if we allocate an object with kmalloc(), then allocate page with
> > alloc_page(), and if we put kmalloc pointer somewhere inside that page,
> > kmemleak will report kmalloc pointer as a false positive.
> > should we improve kmemleak and make it scan page contents?
> > or will this bring too many false negatives?
> Hi Rustam,
> Nice debugging!
> I assume lots of pages are allocated for slab and we don't want to
> scan the whole page if only a few slab objects are alive on the page.
> However alloc_pages() can be called by end kernel code as well.
> I grepped for any kmemleak annotations around existing calls to
> alloc_pages, but did not find any...
> Does it require an explicit kmemleak_alloc() after allocating the page
> and kmemleak_free () before freeing the page?

hi Dmitry, thank you!
yes, as Catalin has pointed out, there are a few places where we call
kmemleak_alloc()/kmemleak_free() explicitly in order for the pages to be
scanned, like in blk_mq_alloc_rqs()

> If there are more than one use case for this, I guess we could add
> some GFP flag for this maybe.

and this way kernel users won't have to use kmemleak fuctions mentioned
above including some or most kmemleak_not_leak() calls and basically
kmemleak will be kind of "transparent" to them? and they will only need
to use the GFP flag to instruct kmemleak to scan the page contents?
it sounds like a good idea to me..

  reply	other threads:[~2021-06-16 18:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14 20:31 kmemleak memory scanning Rustam Kovhaev
2021-06-15  5:15 ` Dmitry Vyukov
2021-06-16 18:25   ` Rustam Kovhaev [this message]
2021-06-24 17:36     ` Rustam Kovhaev
2021-06-25 15:01       ` Catalin Marinas
2021-06-25 15:27         ` Rustam Kovhaev
2021-06-25 15:36           ` Dmitry Vyukov
2021-06-15  8:12 ` David Hildenbrand
2021-06-16 18:27   ` Rustam Kovhaev
2021-06-15 10:15 ` Catalin Marinas
2021-06-16 18:36   ` Rustam Kovhaev

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YMpCEu9yM5Ppj5jj@nuc10 \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).