[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190729133618.GG2368@arrakis.emea.arm.com>
Date: Mon, 29 Jul 2019 14:36:18 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: syzkaller <syzkaller@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Eric Biggers <ebiggers@...gle.com>,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: syzbot bisection analysis
Hi Dmitry,
On Mon, Jul 29, 2019 at 01:08:16PM +0200, Dmitry Vyukov wrote:
> The remaining 10 were all diverged due to other unrelated memory leaks
> and other non-leak bugs. It seems the main 2 reasons for this:
> 1. Lots of leaks are old (kernel is under-tested with KMEMLEAK).
> 2. Lots of unrelated bugs.
> It's unclear how much KMEMLEAK potential for false positives is in
> play. For example, lots of bisections are diverged by "memory leak in
> batadv_tvlv_handler_register", but this is a true bug reported at:
> https://syzkaller.appspot.com/bug?id=0654529ad3cc1d67a6d9812d8b75489c03dfb983
> However, some are diverged by e.g. "memory leak in __neigh_create" and
> "memory leak in copy_process" and these were not reported as separate
> leaks, so either false positives or true leaks fixed in previous
> releases.
Out of curiosity, when the tool tries to bisect a memory leak, does it
check for precisely that leak (e.g. by function name, object size) or
any other unrelated leak can confuse the bisection?
--
Catalin
Powered by blists - more mailing lists