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: <20150512165446.6daf5a4a@gandalf.local.home>
Date:	Tue, 12 May 2015 16:54:46 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Shreyas B Prabhu <shreyas@...ux.vnet.ibm.com>,
	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 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.
> 
> > +	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.

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