On Tue, Mar 26, 2019 at 11:43:38AM -0400, Qian Cai wrote: > Kmemleak could quickly fail to allocate an object structure and then > disable itself in a low-memory situation. For example, running a mmap() > workload triggering swapping and OOM. This is especially problematic for > running things like LTP testsuite where one OOM test case would disable > the whole kmemleak and render the rest of test cases without kmemleak > watching for leaking. > > Kmemleak allocation could fail even though the tracked memory is > succeeded. Hence, it could still try to start a direct reclaim if it is > not executed in an atomic context (spinlock, irq-handler etc), or a > high-priority allocation in an atomic context as a last-ditch effort. > Since kmemleak is a debug feature, it is unlikely to be used in > production that memory resources is scarce where direct reclaim or > high-priority atomic allocations should not be granted lightly. > > Unless there is a brave soul to reimplement the kmemleak to embed it's > metadata into the tracked memory itself in a foreseeable future, this > provides a good balance between enabling kmemleak in a low-memory > situation and not introducing too much hackiness into the existing > code for now. Embedding the metadata would help with the slab allocations (though not with vmalloc) but it comes with its own potential issues. There are some bits of kmemleak that rely on deferred freeing of metadata for RCU traversal, so this wouldn't go well with embedding it. I wonder whether we'd be better off to replace the metadata allocator with gen_pool. This way we'd also get rid of early logging/replaying of the memory allocations since we can populate the gen_pool early with a static buffer. -- Catalin
