On Mon, Jun 04, 2018 at 02:42:10PM +0200, Michal Hocko wrote: > On Mon 04-06-18 10:41:39, Dmitry Vyukov wrote: > [...] > > FWIW this problem is traditionally solved in dynamic analysis tools by > > embedding meta info right in headers of heap blocks. All of KASAN, > > KMSAN, slub debug, LeakSanitizer, asan, valgrind work this way. Then > > an object is either allocated or not. If caller has something to > > prevent allocations from failing in any context, then the same will be > > true for KMEMLEAK meta data. > > This makes much more sense, of course. I thought there were some > fundamental reasons why kmemleak needs to have an off-object tracking > which makes the whole thing much more complicated of course. Kmemleak needs to track all memory blocks that may contain pointers (otherwise the dependency graph cannot be correctly tracked leading to lots of false positives). Not all these objects come from the slab allocator, for example it tracks certain alloc_pages() blocks, all of memblock_alloc(). An option would be to use separate metadata only for non-slab objects, though I'd have to see how intrusive this is for mm/sl*b.c. Also there is RCU freeing for the kmemleak metadata to avoid locking when traversing the internal lists. If the metadata is in the slab object itself, we'd have to either defer its freeing or add some bigger lock to kmemleak. -- Catalin
