lkml.org 
[lkml]   [2020]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Kmemleak infrastructure improvement for task_struct leaks and call_rcu()
    On Thu, May 07, 2020 at 01:29:04PM -0400, Qian Cai wrote:
    > On May 7, 2020, at 1:16 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
    > > I don't mind adding additional tracking info if it helps with debugging.
    > > But if it's for improving false positives, I'd prefer to look deeper
    > > into figure out why the pointer reference graph tracking failed.
    >
    > No, the task struct leaks are real leaks. It is just painful to figure
    > out the missing or misplaced put_task_struct() from the kmemleak
    > reports at the moment.

    We could log the callers to get_task_struct() and put_task_struct(),
    something like __builtin_return_address(0) (how does this work if the
    function is inlined?). If it's not the full backtrace, it shouldn't slow
    down kmemleak considerably. I don't think it's worth logging only the
    first/last calls to get/put. You'd hope that put is called in reverse
    order to get.

    I think it may be better if this is added as a new allocation pointed to
    from kmemleak_object rather than increasing this structure since it will
    be added on a case by case basis. When dumping the leak information, it
    would also dump the get/put calls, in the order they were called. We
    could add some simple refcount tracking (++ for get, -- for put) to
    easily notice any imbalance.

    I'm pretty busy next week but happy to review if you have a patch ;).

    --
    Catalin

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