lkml.org 
[lkml]   [2022]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Resend RFC PATCH] mm: introduce __GFP_TRACKLEAK to track in-kernel allocation
On Fri, Sep 02, 2022 at 06:59:07PM +0800, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>
> Kthread and drivers could fetch memory via alloc_pages directly which make them
> hard to debug when leaking. Solve this by introducing __GFP_TRACELEAK and reuse
> kmemleak mechanism which unified most of kernel cosuming pages into kmemleak.

This may be helpful for debugging individual drivers but they could as
well call kmemleak_alloc/free() directly and not bother with new GFP and
page flags.

I wonder whether we could go the other way around. Add a
__GFP_NOLEAKTRACE (we have SLAB_NOLEAKTRACE for example) and pass it in
the places where we don't want pages to be scanned/tracked: page cache
pages (too many and they don't store pointers to other kernel objects),
sl*b, CMA etc. allocations (basically in all places where you have
kmemleak_alloc() calls, otherwise the pointers overlap and confuse
kmemleak).

--
Catalin

\
 
 \ /
  Last update: 2022-09-07 12:02    [W:0.263 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site