On Wed, Sep 7, 2022 at 6:00 PM Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > On Fri, Sep 02, 2022 at 06:59:07PM +0800, zhaoyang.huang wrote: > > From: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx> > > > > 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. Sure, it could be done as you suggested. However, I would like to have all memory related things wrapped together and leaving the user a simple entrance. Besides, some drivers are designed in Producer/Consumer mode where pages are got and freed by different peers, which may lead to unpair kmemleak operation. > > 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
