linux-kernel - Re: [PATCH v2 2/5] sched, numa: Document usages of mm->numa_scan

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: <1430428387.2475.47.camel@j-VirtualBox>
Date:	Thu, 30 Apr 2015 14:13:07 -0700
From:	Jason Low <jason.low2@...com>
To:	Waiman Long <waiman.long@...com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	Davidlohr Bueso <dave@...olabs.net>,
	Aswin Chandramouleeswaran <aswin@...com>,
	Scott J Norton <scott.norton@...com>, jason.low2@...com
Subject: Re: [PATCH v2 2/5] sched, numa: Document usages of mm->numa_scan_seq

On Thu, 2015-04-30 at 14:42 -0400, Waiman Long wrote:

> I do have a question of what kind of tearing you are talking about. Do 
> you mean the tearing due to mm being changed in the middle of the 
> access? The reason why I don't like this kind of construct is that I am 
> not sure if
> the address translation p->mm->numa_scan_seq is being done once or 
> twice. I looked at the compiled code and the translation is done only once.
> 
> Anyway, the purpose of READ_ONCE and WRITE_ONCE is not for eliminating 
> data tearing. They are to make sure that the compiler won't compile away 
> data access and they are done in the order they appear in the program. I 
> don't think it is a good idea to associate tearing elimination with 
> those macros. So I would suggest removing the last sentence in your comment.

Yes, I can remove the last sentence in the comment since the main goal
was to document that we're access this field without exclusive access.

In terms of data tearing, an example would be the write operation gets
split into multiple stores (though this is architecture dependent). The
idea was that since we're modifying a seq variable without the write
lock, we want to remove any forms of optimizations as mentioned above or
unpredictable behavior, since READ_ONCE/WRITE_ONCE adds no overhead.

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