linux-kernel - Re: crazy idea: big percpu lock (Re: task isolation)

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] [day] [month] [year] [list]

Message-ID: <5641FCD7.7040902@redhat.com>
Date:	Tue, 10 Nov 2015 09:19:03 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>,
	Chris Metcalf <cmetcalf@...hip.com>
CC:	Luiz Capitulino <lcapitulino@...hat.com>,
	Gilad Ben Yossef <giladb@...hip.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Christoph Lameter <cl@...ux.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: crazy idea: big percpu lock (Re: task isolation)

On 10/28/2015 02:45 PM, Andy Lutomirski wrote:

>> The model I chose is to have a per-cpu state that indicates whether
>> the core is in kernel space, in user space, or in user space with
>> a TLB flush pending.  On entry to user space with task isolation
>> in effect we just set the state to "user".  When doing a remote
>> TLB flush we decide whether or not to actually issue the flush by
>> doing a cmpxchg() from "user" to "user pending", and if the
>> old state was either "user" or "user pending", we don't issue the
>> flush.  Finally, on entry to the kernel for a task-isolation task we
>> do an atomic xchg() to set the state to "kernel", and if we discover
>> a flush was pending, we just globally flush the kernel's full VA range
>> (no real reason to optimize for this case).
> 
> This sounds like it belongs in the generic context tracking code, or
> at least the tracking part and the option to handle deferred work
> should go there.

I wonder if your whole idea could also piggyback on the
context tracking code.

If the remote CPU is in a quiescent state, have the per-cpu
thing done by the calling CPU, instead of interrupting the
quiescent CPU.

In the unlikely event quiescent CPU wakes up (or returns to
kernel space) while some per-cpu thing is done remotely, it
can wait for completion before it continues into the kernel.

The amount of time it waits will, at worst, be as much as
it would have spent doing that per-cpu thing itself.

-- 
All rights reversed
--
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/