Thread (5 messages) flat view 5 messages, 3 authors, 2018-05-09

Re: [PATCH] powerpc/64s/radix: reset mm_cpumask for single thread process when possible

From: Nicholas Piggin <npiggin@gmail.com>
Date: 2018-05-09 11:53:17

On Wed, 09 May 2018 18:31:55 +1000
Benjamin Herrenschmidt [off-list ref] wrote:
On Wed, 2018-05-09 at 16:56 +1000, Nicholas Piggin wrote:
quoted
When a single-threaded process has a non-local mm_cpumask and requires
a full PID tlbie invalidation, use that as an opportunity to reset the
cpumask back to the current CPU we're running on.

No other thread can concurrently switch to this mm, because it must
have had a reference on mm_users before it could use_mm. mm_users can
be asynchronously incremented e.g., by mmget_not_zero, but those users
must not be doing use_mm.  
What do you mean ? I don't fully understand how this isn't racy with
another thread being created, switching to that mm, and then having its
bit cleared by us ?
We are the single thread, so nothing else can call clone on our mm.
Also why not use_mm ? what prevents it ?
I'm not sure if it has an assertion (it probably should), but existing
convention. Such things would be broken there are already other
architectures doing similar things with TLB flushing for example, alpha,
ia64, mips, sh... sparc does something very similar resetting its cpumask
by the look.

I grepped mmget_not_zero callers too, couldn't see any obvious use_mm
cases.

Thanks,
Nick
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help