Re: [BUG] kmemleak on __radix_tree_preload

[Catalin Marinas <catalin.marinas@arm.com>]

On 8 May 2014, at 18:52, Johannes Weiner <hannes@cmpxchg.org> wrote:
> On Thu, May 08, 2014 at 08:53:30AM -0700, Paul E. McKenney wrote:
>> On Thu, May 08, 2014 at 04:29:48PM +0100, Catalin Marinas wrote:
>>> On Thu, May 08, 2014 at 04:00:27PM +0100, Paul E. McKenney wrote:
>>>> On Thu, May 08, 2014 at 11:24:36AM +0100, Catalin Marinas wrote:
>>>>> My summary so far:
>>>>> 
>>>>> - radix_tree_node reported by kmemleak as it cannot find any trace of it
>>>>>  when scanning the memory
>>>>> - at allocation time, radix_tree_node is memzero'ed by
>>>>>  radix_tree_node_ctor(). Given that node->rcu_head.func ==
>>>>>  radix_tree_node_rcu_free, my guess is that radix_tree_node_free() has
>>>>>  been called
> 
> The constructor is called once when the slab is initially allocated,
> not on every object allocation.  The user is expected to return
> objects in a pristine form or overwrite fields on reallocation, so
> it's possible that the RCU values are left over from the previous
> allocation.

You are right, I missed this one.

>>>>> - some time later, kmemleak still hasn't received any callback for
>>>>>  kmem_cache_free(node). Possibly radix_tree_node_rcu_free() hasn't been
>>>>>  called either since node->count is not NULL.
>>>>> 
>>>>> For RCU queued objects, kmemleak should still track references to them
>>>>> via rcu_sched_state and rcu_head members. But even if this went wrong, I
>>>>> would expect the object to be freed eventually and kmemleak notified (so
>>>>> just a temporary leak report which doesn't seem to be the case here).

[…]

>>>> Of course, if the value of node->count is preventing call_rcu() from
>>>> being invoked in the first place, then the needed grace period won't
>>>> start, much less finish.  ;-)
>>> 
>>> Given the rcu_head.func value, my assumption is that call_rcu() has
>>> already been called.
>> 
>> Fair point -- given that it is a union, you would expect this field to
>> be overwritten upon reuse.
> 
> .parent is overwritten immediately on reuse, but .private_data is
> actually unlikely to be used during the lifetime of the node.
> 
> This could explain why .rcu.head.next is NULL like parent, and
> .private_data/.rcu.head.func is untouched and retains RCU stuff: to me
> it doesn't look like the node is lost in RCU-freeing, rather it was
> previously RCU freed and then lost somewhere after reallocation.

This would be a simpler explanation, and even simpler to test, just
reset rcu_head.func in radix_tree_node_rcu_free() before being returned
to the slab allocator.

Does the negative count give us any clue? This one is reset before
freeing the object.

Thanks,

Catalin