On 08/30/2017 06:09 PM, David Miller wrote:

From: Khalid Aziz <redacted>
Date: Wed, 30 Aug 2017 17:23:37 -0600

quoted

That is an interesting idea. This would enable TSTATE_MCDE on all
threads of a process as soon as one thread enables it. If we consider
the case where the parent creates a shared memory area and spawns a
bunch of threads. These threads access the shared memory without ADI
enabled. Now one of the threads decides to enable ADI on the shared
memory. As soon as it does that, we enable TSTATE_MCDE across all
threads and since threads are all using the same TTE for the shared
memory, every thread becomes subject to ADI verification. If one of
the other threads was in the middle of accessing the shared memory, it
will get a sigsegv. If we did not enable TSTATE_MCDE across all
threads, it could have continued execution without fault. In other
words, updating TSTATE_MCDE across all threads will eliminate the
option of running some threads with ADI enabled and some not while
accessing the same shared memory. This could be necessary at least for
short periods of time before threads can communicate with each other
and all switch to accessing shared memory with ADI enabled using same
tag. Does that sound like a valid use case or am I off in the weeds
here?

A threaded application needs to synchronize and properly orchestrate
access to shared memory.

When a change is made to a mappping, in this case setting ADI
attributes, it's being done for the address space not the thread.

And the address space is shared amongst threads.

Therefore ADI is not really a per-thread property but rather
a per-address-space property.

That does make sense.

Thanks,
Khalid

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>