Messages in this thread | | | Date | Wed, 7 Sep 2022 11:00:20 +0100 | From | Catalin Marinas <> | Subject | Re: [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
| |