On Wed, Jun 16, 2021 at 11:25:22AM -0700, Rustam Kovhaev wrote:

On Tue, Jun 15, 2021 at 07:15:24AM +0200, Dmitry Vyukov wrote:

quoted

On Mon, Jun 14, 2021 at 10:31 PM Rustam Kovhaev [off-list ref] wrote:

quoted

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()

quoted

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..

i've been thinking about this and it seems like in the scenario where we
want kmemleak to scan only some part of the page, we will have to either
do separate alloc_page() calls with different flags or use 
kmemleak_scan_area() to limit the memory scan area. maybe this approach
won't simplify things and will produce more code instead of reducing it