Messages in this thread | | | From | Dmitry Vyukov <> | Date | Tue, 30 Jul 2019 11:16:43 +0200 | Subject | Re: 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.
| |