lkml.org 
[lkml]   [2019]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: syzbot bisection analysis
On Mon, Jul 29, 2019 at 3:36 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> 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?

Bisection of leaks uses the common scheme which is just "crashed"/"not
crashed" (black/white, no further classification) for reasons outlined
here:
https://groups.google.com/forum/#!msg/syzkaller/sR8aAXaWEF4/tTWYRgvmAwAJ
Consider object size changes across revisions, or the function is
renamed, or code changes. Even if we take just leaks, I am not sure if
it's possible to understand if it's the same leak or not.

\
 
 \ /
  Last update: 2019-07-30 11:17    [W:0.036 / U:0.964 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site