Messages in this thread | | | Date | Wed, 01 Oct 2014 15:45:59 +0400 | From | Andrey Ryabinin <> | Subject | Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak |
| |
On 10/01/2014 02:39 PM, Catalin Marinas wrote: > On Mon, Sep 29, 2014 at 03:10:01PM +0100, Dmitry Vyukov wrote: >> On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin <ryabinin.a.a@gmail.com> wrote: >>> 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov <dvyukov@google.com>: >>>> Looks good to me. >>>> >>>> We can disable kasan instrumentation of this file as well. >>> >>> Yes, but why? I don't think we need that. >> >> Just gut feeling. Such tools usually don't play well together. For >> example, due to asan quarantine lots of leaks will be missed (if we >> pretend that tools work together, end users will use them together and >> miss bugs). I won't be surprised if leak detector touches freed >> objects under some circumstances as well. >> We can do this if/when discover actual compatibility issues, of course. > > I think it's worth testing them together first. >
I did test them together. With this patch applied both tools works without problems.
> One issue, as mentioned in the patch log, is that the size information > that kmemleak gets is the one from the kmem_cache object rather than the > original allocation size, so this would be rounded up. > > Kmemleak should not touch freed objects (if an object is freed during a > scan, it is protected by some lock until the scan completes). There is a > bug however which I haven't got to fixing it yet, if kmemleak fails for > some reason (cannot allocate memory) and disables itself, it may access > some freed object (though usually hard to trigger). >
| |