On Thu, Mar 28, 2019 at 08:05:31AM +0200, Pekka Enberg wrote: > On 27/03/2019 2.59, Qian Cai wrote: > > 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. > > Unfortunately I am not that brave soul, but I'm wondering what the > complication here is? It shouldn't be too hard to teach calculate_sizes() in > SLUB about a new SLAB_KMEMLEAK flag that reserves spaces for the metadata. I don't think it's the calculate_sizes() that's the hard part. The way kmemleak is designed assumes that the metadata has a longer lifespan than the slab object it is tracking (and refcounted via get_object/put_object()). We'd have to replace some of the rcu_read_(un)lock() regions with a full kmemleak_lock together with a few more tweaks to allow the release of kmemleak_lock during memory scanning (which can take minutes; so it needs to be safe w.r.t. metadata freeing, currently relying on a deferred RCU freeing). Anyway, I think it is possible, just not straight forward. -- Catalin
