linux-kernel - Re: [PATCH 1/2] trace_events_filter: use rcu_assign_pointer() when setting ftrace_event

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:	Mon, 28 Nov 2011 08:49:01 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Jiri Olsa <jolsa@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] trace_events_filter: use rcu_assign_pointer() when
 setting ftrace_event_call->filter

On Wed, Nov 23, 2011 at 09:33:13AM -0800, Tejun Heo wrote:
> Hello, Steven.
> 
> On Wed, Nov 23, 2011 at 12:06:40PM -0500, Steven Rostedt wrote:
> > > So, synchronized_sched() being called after isn't relevant.  We want
> > > smp_wmb() between data structure initialization and assignment of the
> > > new pointer.
> > 
> > Ah, you're saying that we need to guarantee that the allocated filter is
> > seen before we update the call->filter to point to it. OK, fair enough,
> > this does look like a bug fix.
> > 
> > Is it big enough to be considered for stable?
> 
> It's unlikely to happen for x86 or arm and that probably is the
> biggest reason there hasn't already been a bug report.  It isn't very
> urgent but at the same time the change is almost trivial, so marking
> it for stable is a pretty safe bet.  I lean toward marking it for
> stable but the leaning isn't too strong. :)

I believe that marking it for stable makes sense, especially since
reasonably common compiler optimizations can rearrange the update side.
This can be especially painful for PREEMPT=y kernels, which could in
some cases preempt the task after the rearrangement, leaving readers
vulnerable to seeing uninitialized data for an extended time period.
Please note that this can happen even on arbitrarily strongly ordered
CPUs -- it is the compiler that is toying with us here.

							Thanx, Paul

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