linux-kernel - Re: [PATCH RESEND 0/3] tracing/mm: Fix suspicious rcu_dereference

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]

Message-ID: <5553017A.2080905@linux.vnet.ibm.com>
Date:	Wed, 13 May 2015 13:17:06 +0530
From:	Shreyas B Prabhu <shreyas@...ux.vnet.ibm.com>
To:	Steven Rostedt <rostedt@...dmis.org>,
	Andrew Morton <akpm@...ux-foundation.org>
CC:	linux-kernel@...r.kernel.org, mingo@...hat.com,
	aneesh.kumar@...ux.vnet.ibm.com, paulmck@...ux.vnet.ibm.com,
	preeti@...ux.vnet.ibm.com, mgorman@...e.de, namhyung@...nel.org,
	lizf@...fujitsu.com, acme@...hat.com
Subject: Re: [PATCH RESEND 0/3] tracing/mm: Fix suspicious rcu_dereference_check()
 usage warnings



On Wednesday 13 May 2015 02:24 AM, Steven Rostedt wrote:
> On Tue, 12 May 2015 13:36:01 -0700
> Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
>> On Tue, 12 May 2015 16:03:51 -0400 Steven Rostedt <rostedt@...dmis.org> wrote:
>>
>>> On Tue, 12 May 2015 12:59:26 +0530
>>> Shreyas B Prabhu <shreyas@...ux.vnet.ibm.com> wrote:
>>>
>>>> Hi Steven,
>>>> On closer look, there is no particular maintainer who picks changes to
>>>> this file. Can you please pick these up?
>>>
>>> Perhaps Andrew Morton?
>>>
>>> No problem, I can take these too.
>>>
>>
>> I grabbed them, thanks.
>>

Thanks Andrew.

>>> +	TP_CONDITION(cpu_online(smp_processor_id())),
>>
>> Are we sure these can't generate check_preemption_disabled() warnings? 
>> Is there some reason why all these calls always occur with preemption
>> disabled?
> 
> Good catch. I don't think the code does.
> 
> Now, I'm not sure if we should just add a raw_smp_processor_id(). The
> idea is just to make sure that the CPU we are running on is online,
> because it is possible to call theses trace points when the CPU is
> going offline. If that happens, then there's a race with RCU.
> 
> Since a task can not be migrated to an offline CPU, we don't need to
> worry about the cpu_online(smp_processor_id()) returning a false
> positive. A false negative would just skip a tracepoint, but I'm not
> sure that is possible either.
> 
> In any case, comments should also be added to why the condition is
> there.
> 
I'll send a patch adding the comments.

Thanks,
Shreyas

--
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/