3.9-rc1 NULL pointer crash at find_pid_ns

Eric W. Biederman ebiederm at xmission.com
Thu Mar 7 18:05:34 UTC 2013


Sasha Levin <sasha.levin at oracle.com> writes:

> On 03/07/2013 12:46 PM, Eric Dumazet wrote:
>> On Thu, 2013-03-07 at 12:36 -0500, Sasha Levin wrote:
>> 
>>> Looks like the hlist change is probably the issue, though it specifically
>>> uses:
>>>
>>> 	#define hlist_entry_safe(ptr, type, member) \
>>>         	(ptr) ? hlist_entry(ptr, type, member) : NULL
>>>
>>> I'm still looking at the code in question and it's assembly, but I can't
>>> figure out what's going wrong. I was also trying to see what's so special
>>> about this loop in find_pid_ns as opposed to the rest of the kernel code
>>> that uses hlist_for_each_entry_rcu() but couldn't find out why.
>>>
>>> Is it somehow possible that if we rcu_dereference_raw() the same thing twice
>>> inside the same rcu_read_lock() section we'll get different results? That's
>>> really the only reason for this crash that comes to mind at the moment, very
>>> unlikely - but that's all I have right now.
>>>
>> 
>> Yep
>> 
>> #define hlist_entry_safe(ptr, type, member) \
>> 	(ptr) ? hlist_entry(ptr, type, member) : NULL
>> 
>> Is not safe, as ptr can be evaluated twice, and thats not good at all...
>
> ptr is being evaluated twice, but in this case this is an
> rcu_dereference_raw() value within the same rcu_read_lock() section.
>
> Is it still problematic?

Definitely.

Head in this instance the expression: &pid_hash[pid_hashfn(nr, ns)]

And the crash clearly shows that when hilst_entry is being evaluated the
HEAD is NULL.

Perhaps this shows up in proc because the hash chains are short and
frequently NULL?

Eric


More information about the Containers mailing list