On Thu, Mar 28, 2019 at 01:50:29PM +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. > > On Thu, Mar 28, 2019 at 08:05:31AM +0200, Pekka Enberg wrote: > > > 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. > > On 28/03/2019 12.30, Catalin Marinas wrote:> 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). > > Right. > > I think SLUB already supports delaying object freeing because of KASAN (see > the slab_free_freelist_hook() function) so the issue with metadata outliving > object is solvable (although will consume more memory). Thanks. That's definitely an area to investigate. > I can't say I remember enough details from kmemleak to comment on the > locking complications you point out, though. They are not too bad, I'd just need some quiet couple of days to go through them (which I don't have at the moment). -- Catalin
