alan@redhat.com said:
> We add
> sys_switchmm(address);
> This switches to the altmm (creating one if it doesnt exist as a copy
> of the current mm), flushes the tlb and jumps to the address given.
You didn't explicitly say (and so I had to ask :-) that this is intended
to be the mechanism by which UML returns to userspace, rather than the
normal sigreturn you'd get by just returning from the handler.
So, this would make the entry to userspace look like:
restore registers
.
.
.
sys_switchmm(ip);
The problem with this is that it needs to be atomic wrt signals. There
can't be an interrupt in the middle of that sequence. So, sys_switchmm
would also have to restore the old signal mask, which you'd have to pass
in unless you're going to read it off the signal frame. Also, it would
have to be open coded because you've already restored the stack pointer.
So, the entry to userspace starts looking like:
block signals
restore registers
sys_switchmm(ip, new_sigmask);
Well, except for the blocking signals part, this is sigreturn under a
different name and partly moved into userspace.
Your objection to returning through sigreturn was performance. Is performance
a veto of adding an mm switch to sigreturn, or it is possible to make it
acceptible?
Also, is a new sigreturn_mm() reasonable? This would be close to sys_switchmm,
except that it would restore registers and would be a plug replacement for
sigreturn[_rt]. I don't favor this because it would probably have to choose
whether to be an _rt return or not, and I'd like the option of having UML
register some signals as SA_INFO (currently, they are all non SA_INFO).
Comments, brickbats, spanners?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:18 EST