Firstly I want to say that if I remember Linus's opinion on this
matter from some time ago this sort of change is not going into the
kernel, in fact you essentially have to allow any data segment to be
executable. If you break this all sorts of "fun" things happen,
crashme stops working (bad bad bad), certain high performance
scheme/lisp interpreters stop working, and you break our current
signal returning mechanism which is used on all platforms.
> AFAIK, they will cause some overhead for maintaining L1 code and data caches
> coherency, since the stack frame is usually in the data cache -- resulting in
> bad performance.
We're talking about some hundred cycles or more ...
Care to propose another way to handle signal dispatch in a clone()
safe way? We used to do signals stupidly via a libc static signal
dispatch vector on the Sparc (this is the way SunOS did it), then I
considered the clone() threaded signal problem, man did I change over
to the way the Intel and Alpha always did it but fast, I'll eat the
instruction cache flush any day compared to the alternative.
---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><