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....@gmail.com> > wrote: > > 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov <dvyu...@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. 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). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
