lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 8 May 2014 22:40:22 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Johannes Weiner <hannes@...xchg.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Jaegeuk Kim <jaegeuk.kim@...sung.com>,
	"Linux Kernel, Mailing List" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [BUG] kmemleak on __radix_tree_preload

On 8 May 2014, at 18:52, Johannes Weiner <hannes@...xchg.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--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists