Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal
[off-list ref] wrote:

On Mon, 13 Mar 2017, Andy Lutomirski wrote:

quoted

This sounds rather complicated.  Getting TLB flushing right seems
tricky.  Why not just map the same thing into multiple mms?

This is exactly what happens at the end. The memory region that is descri=

bed by the

VAS segment will be mapped in the ASes that use the segment.

So why is this kernel feature better than just doing MAP_SHARED
manually in userspace?

quoted

Ick.  Please don't do this.  Can we please keep an mm as just an mm
and not make it look magically different depending on which process
maps it?  If you need a trampoline (which you do, of course), just
write a trampoline in regular user code and map it manually.

Did I understand you correctly that you are proposing that the switching =

thread

should make sure by itself that its code, stack, =E2=80=A6 memory regions=

 are properly setup

in the new AS before/after switching into it? I think, this would make us=

ing first

class virtual address spaces much more difficult for user applications to=

 the extend

that I am not even sure if they can be used at all. At the moment, switch=

ing into a

VAS is a very simple operation for an application because the kernel will=

 just simply

do the right thing.

Yes.  I think that having the same mm_struct look different from
different tasks is problematic.  Getting it right in the arch code is
going to be nasty.  The heuristics of what to share are also tough --
why would text + data + stack or whatever you're doing be adequate?
What if you're in a thread?  What if two tasks have their stacks in
the same place?

I could imagine something like a sigaltstack() mode that lets you set
a signal up to also switch mm could be useful.