--2006934960-1804928587-904044729=:24870
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 24 Aug 1998, Linus Torvalds wrote:
> Yes, the reason this didn't show up before was that we had interrupts
> effectively disabled for the whole context switch (simply because we did
> it with a single instruction and thus the CPU wouldn't accept interrupts
> until it was all done..)
>
> > - make the switch_to() code safe wrt segment saves without
> > disabling IRQs, by zeroing out segment registers. (zeroing
> > segment registers takes exactly 1 cycle on my PII)
>
> This looks like a reasonable solution, especially as we only need to do
> this when we reload the LDT. However...
>
> > is there any other place in the kernel where segment registers might hold
> > invalid contents?
>
> There are cases where a user can force a bad segment into %fs and %gs by
> loading a new LDT - the kernel won't care. It has the logic to cleanly
> reload zero segments in the normal paths.
Indeed.
>
> I would suggest that instead of your patch to __switch_to(), the APM code
> should probably re-load %fs and %gs with
>
> loadsegment(fs, value);
> loadsegment(gs, value);
>
> which correctly takes the GP trap and loads a zero if the value was bad
> using the normal exception mechanism (ie no overhead at all except for the
> case where it actually traps).
Except for one thing, saving %fs and %gs should be done _before_ loading
the new ldt, otherwise %fs and/or %gs can be automagically zeroed in an
APM interrupt (or any other which happens to use these segment
registers) and saved as such in task struct (with interesting side
effects on Wine and friends ;)). Ingo's patch is right in this respect.
> That will work correctly for both the case where a interrupt happened
> while the segments hadn't yet been updated, AND for the case (which can be
> synchronous) where a user had invalidated the segment pointed to by
> %fs/%gs.
>
But this was not my main point, now that all segment register loads and
even the iret is protected from exceptions, it might be time to remove
the bogus checks for selectors in restore_sigcontext. Hence the attached
patch (perhaps to aggressive, I'll admit). It will hopefully make
signal return faster and some thread libraries happier.
Gabriel.
--2006934960-1804928587-904044729=:24870
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="signal.c.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.HPP.3.96.980825133209.24870B@gra-ux1.iram.es>
Content-Description: Faster restore_sigcontext by removing useless checks.
LS0tIGxpbnV4LTIuMS4xMTctdmFuaWxsYS9hcmNoL2kzODYva2VybmVsL3Np
Z25hbC5jCU1vbiBBdWcgMjQgMTA6NTY6MDEgMTk5OA0KKysrIGxpbnV4LTIu
MS4xMTcvYXJjaC9pMzg2L2tlcm5lbC9zaWduYWwuYwlUdWUgQXVnIDI1IDA5
OjUyOjE0IDE5OTgNCkBAIC0xODQsMjYgKzE4NCwxNyBAQA0KIA0KICNkZWZp
bmUgQ09QWV9TRUcoc2VnKQkJCQkJCQlcDQogCXsgdW5zaWduZWQgc2hvcnQg
dG1wOwkJCQkJCVwNCi0JICAgZXJyIHw9IF9fZ2V0X3VzZXIodG1wLCAmc2Mt
PnNlZyk7CQkJCVwNCi0JICBpZiAoKHRtcCAmIDB4ZmZmYykJCS8qIG5vdCBh
IE5VTEwgc2VsZWN0b3JzICovCVwNCi0JICAgICAgJiYgKHRtcCAmIDB4NCkg
IT0gMHg0CS8qIG5vdCBhIExEVCBzZWxlY3RvciAqLwlcDQotCSAgICAgICYm
ICh0bXAgJiAzKSAhPSAzKQkvKiBub3QgYSBSUEwzIEdEVCBzZWxlY3RvciAq
LwlcDQotCQkgIGdvdG8gYmFkZnJhbWU7CQkJCQlcDQorCSAgZXJyIHw9IF9f
Z2V0X3VzZXIodG1wLCAmc2MtPnNlZyk7CQkJCVwNCiAJICByZWdzLT54IyNz
ZWcgPSB0bXA7IH0NCiANCiAjZGVmaW5lIENPUFlfU0VHX1NUUklDVChzZWcp
CQkJCQkJXA0KIAl7IHVuc2lnbmVkIHNob3J0IHRtcDsJCQkJCQlcDQogCSAg
ZXJyIHw9IF9fZ2V0X3VzZXIodG1wLCAmc2MtPnNlZyk7CQkJCVwNCi0JICBp
ZiAoKHRtcCAmIDB4ZmZmYykgJiYgKHRtcCAmIDMpICE9IDMpIGdvdG8gYmFk
ZnJhbWU7CQlcDQotCSAgcmVncy0+eCMjc2VnID0gdG1wOyB9DQorCSAgcmVn
cy0+eCMjc2VnID0gdG1wfDM7IH0NCiANCiAjZGVmaW5lIEdFVF9TRUcoc2Vn
KQkJCQkJCQlcDQogCXsgdW5zaWduZWQgc2hvcnQgdG1wOwkJCQkJCVwNCiAJ
ICBlcnIgfD0gX19nZXRfdXNlcih0bXAsICZzYy0+c2VnKTsJCQkJXA0KLQkg
IGlmICgodG1wICYgMHhmZmZjKQkJLyogbm90IGEgTlVMTCBzZWxlY3RvcnMg
Ki8JXA0KLQkgICAgICAmJiAodG1wICYgMHg0KSAhPSAweDQJLyogbm90IGEg
TERUIHNlbGVjdG9yICovCVwNCi0JICAgICAgJiYgKHRtcCAmIDMpICE9IDMp
CS8qIG5vdCBhIFJQTDMgR0RUIHNlbGVjdG9yICovCVwNCi0JCSAgZ290byBi
YWRmcmFtZTsJCQkJCVwNCiAJICBsb2Fkc2VnbWVudChzZWcsdG1wKTsgfQ0K
IA0KIAlHRVRfU0VHKGdzKTsNCg==
--2006934960-1804928587-904044729=:24870--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html