linux-kernel - Re: [RFC][PATCH v2] sched/rt: Use IPI to trigger RT task push migration instead of pulling

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, 26 Feb 2015 14:47:54 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Clark Williams <williams@...hat.com>,
	linux-rt-users <linux-rt-users@...r.kernel.org>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Jörn Engel <joern@...estorage.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: [RFC][PATCH v2] sched/rt: Use IPI to trigger RT task push
 migration instead of pulling

On Thu, Feb 26, 2015 at 07:43:01AM -0500, Steven Rostedt wrote:
> On Thu, 26 Feb 2015 08:45:59 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:
> 
> > On Wed, Feb 25, 2015 at 12:50:15PM -0500, Steven Rostedt wrote:
> > > It can't be used for state?
> > > 
> > > If one CPU writes "zero", and the other CPU wants to decide if the
> > > system is in the state to do something, isn't a rmb() fine to use?
> > > 
> > > 
> > > CPU 1:
> > > 
> > > 	x = 0;
> > > 	/* Tell other CPUs they can now do something */
> > > 	smp_wmb();
> > > 
> > > CPU 2:
> > > 	/* Make sure we see current state of x */
> > > 	smp_rmb();
> > > 	if (x == 0)
> > > 		do_something();
> > > 
> > > The above situation is not acceptable?
> > 
> > Acceptable is just not the word. It plain doesn't work that way.
> 
> Thinking about this more, is it because a wmb just forces the CPU to
> write everything before this before it writes anything after it. That
> is, the writes themselves can happen at a much later time. Does a plain
> mb() work the same way if there are no reads required?

No, neither smp_wmb nor smp_mb are required to flush the store buffers.

The only thing barriers do is guarantee order, this can be done by
flushing store buffers but it can also be done by making sure store
buffers flush writes in the 'right' order.

Nor does an rmb help anything with ordering against a possible store
buffer flush. Again rmb only guarantees two loads are issued in that
particular order, it doesn't disallow the CPU speculating the load at
all.

So that load of X could come out of thin air, or a year ago, or
whatever, definitely before any store buffers were, or were not, flushed
on another cpu.

> > > Otherwise, we fail to be able to do_something() when it is perfectly
> > > fine to do so.
> > 
> > Can't be helped.
> 
> What about using atomic_t?
> 
> Note, my latest code doesn't have any of this, but I just want to
> understand the semantics of these operations a bit better.

Nope, atomic_t doesn't help here either. Atomics only make sure the RmW
cycle is atomic.

Note that even if wmb or mb did flush the store buffer, you would still
have a race here.
--
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/