Followup to: <Pine.LNX.4.44.0301051040020.11848-100000@home.transmeta.com>
By author: Linus Torvalds <torvalds@transmeta.com>
In newsgroup: linux.dev.kernel
>
> Now, that SYSENTER_CS thing is very rare indeed, and by keeping track of
> what the previous value was (ie just caching the SYSENTER_CS value in the
> thread_struct), we could get rid of it with a conditional jump instead.
> Want to try it?
>
This seems like the first thing to do.
Dealing with the SYSENTER_ESP issue is a lot tricker. It seems that
it can be done with a magic EIP range test in the #DB handler, the
range is the part that finds the top of the real kernel stack and
pushfl's to it; the #DB handler if it receives a trap in this region
could emulate this piece of code (including pushing the pre-exception
flags onto the stack) and then invoke the instruction immediately
after the pushf..
Yes, it's ugly, but it should be relatively straightforward, and since
this particular chunk is assembly code by necessity it shouldn't be
brittle.
The other variant (which I have suggested) is to simply state "TF set
in user space is not honoured." This would require a system call to
set TF -> 1. That way the kernel already has the TF state for all
processes.
Again, it's ugly.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> - 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 : Tue Jan 07 2003 - 22:00:30 EST