[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGWkznF_B10YkQ0jeS_O6z3bfeLk7aQZH6AVS9znFmJwa6spHQ@mail.gmail.com>
Date: Mon, 12 Sep 2022 10:23:25 +0800
From: Zhaoyang Huang <huangzhaoyang@...il.com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: "zhaoyang.huang" <zhaoyang.huang@...soc.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>, Ke Wang <ke.wang@...soc.com>
Subject: Re: [Resend RFC PATCH] mm: introduce __GFP_TRACKLEAK to track
in-kernel allocation
On Wed, Sep 7, 2022 at 6:00 PM Catalin Marinas <catalin.marinas@....com> wrote:
>
> On Fri, Sep 02, 2022 at 06:59:07PM +0800, zhaoyang.huang wrote:
> > From: Zhaoyang Huang <zhaoyang.huang@...soc.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.
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
Powered by blists - more mailing lists