Thema: Adressraum für Kernel und Prozesse

[kevin]

Exceptions sind nicht grundsätzlich Fehler, die können auch eingeplant sein. Klassisches Beispiel ist der Page Fault beim Swapping.

[erik.vikinger]

Hallo,

Aber Du bist doch so sehr für einen unterbrechbaren Kernel eingetreten und wenn Du HW-IRQs im Kernel willst dann sind Exceptions auch nicht mehr schlimm.

Das sind für mich 2 Paar Schuhe.

Aber NMI benutzen, das nenne ich konsequent!

Letztere möchte ich nicht im Kernel behandeln, denn Exception könnte bedeuten das ich den Fehler nicht behandeln kann und das Programm muss gekillt werden, versuch das mal mit deinem Kernel

Klar will man den Kernel nicht killen aber gerade bei diesem speziellen Fehler "verbogene Segmentregister" ist es eindeutig das nicht der Kernel sondern ein User-Mode-Prozess gekillt werden muss. Ich bin schon der Meinung das es sich hierbei um eine spezielle Situation handelt für die man auch mal eine Ausnahme von der Regel machen kann (bekommst ja auch etwas Performance dafür geschenkt), aber wenn Du das anders siehst dann ist das Okay für mich.

Eine Exception im Kernel heißt bei mir grundsätzlich PANIC().

Bei mir auch, das ist sogar von der HW so vorgegeben.


Grüße
Erik

[FlashBurn]

Aber NMI benutzen, das nenne ich konsequent! Wink

Ich überlege immer nebenher, wie ich diesen NMI wieder loswerden kann

Denn das Problem ist, wie kann ich zw. nem richtigen NMI und ner IPI-Nachricht unterscheiden?

aber gerade bei diesem speziellen Fehler "verbogene Segmentregister" ist es eindeutig das nicht der Kernel sondern ein User-Mode-Prozess gekillt werden muss.

Ich bin gerade zu faul in den Intel Manuals nachzugucken, aber wie bekommt man eigentlich raus das eins (und vorallem welches es dann ist) falsch war?

Eine andere Situation, wäre wenn man bei mir einfach den Wert aus fs (ist fürs TLS) in ds oder es schreibt. Eigentlich müsste man da ja auch ne Exception bekommen, wenn man außerhalb des Segments zugreifen will, oder?

[Jidder]

Ich bin gerade zu faul in den Intel Manuals nachzugucken, aber wie bekommt man eigentlich raus das eins (und vorallem welches es dann ist) falsch war?

Dass eins falsch war, bekommt man mit einem General Protection Fault mit. Welches das ist, nur durch den nachfolgenden Einsatz eines Disassemblers. Aber man muss eh alle Register mit korrekten Werten neuladen, wenn ein GPF auftritt, siehe unten.

Man benutzt eben ein architektur-spezifisches Feature um ein architektur-spezifisches Problem zu lösen.

Es gab kein Problem, also wurde auch keines nicht gelöst. Wenn man hingegen deine Idee einmal weiterdenkt, dann stößt man auf Probleme.

- Der GPF-Handler muss ein Sonderfall werden, weil der ja nicht wieder über die sabotierten Segment Register stolpern soll. Also muss er immer die Segment Register neuladen.

- Wenn man den Virtual-8086 Mode unterstützen will, dann muss man auch in allen IRQ-Handlern und in den meisten Exception-Handlern die Register neuladen, weil alle Exceptions und Interrupts aus dem Virtual-8086 Mode mit genullten Segment Registern im Kernel ankommen.

- Man muss weiterhin darauf aufpassen, dass kein Interrupt-Handler Locks annimmt. Weil diese Exception könnte auftreten, während ein Lock gehalten wird. Da lässt der Dead Lock dann nicht lange auf sich warten.

- Ich nehme mal an, dass es im Kernel sowas wie eine globale (cpu-lokale) Variable "current_task" gibt, und dass das die einzige Möglichkeit ist, im Exception Handler festzustellen, welcher Task der Verursacher der Exception war. Man muss jetzt aufpassen, dass diese Exception nicht auftritt, nachdem ein Kontext Wechsel stattgefunden hat, also current_task geändert wurde. Sonst würde der falsche Task gekillt werden. Ich sehe keine Möglichkeit das zu garantieren, außer durch Neuladen der Segment Register.

Ich finde eriks Idee immer besser.

[FlashBurn]

Exceptions sind nicht grundsätzlich Fehler, die können auch eingeplant sein. Klassisches Beispiel ist der Page Fault beim Swapping.

Swapping habe ich noch nicht, aber recht hast du trotzdem, hatte mal mit dem Gedanken gespielt lazy mapping im Kernel zuzulassen.
Aber Swapping möchte ich im Kernel sowieso nicht haben.

Dass eins falsch war, bekommt man mit einem General Protection Fault mit.

Das ist mir schon klar, aber nen GPF wird ja nicht nur deswegen, sondern auch noch aus anderen Gründen geworfen. Du müsstest also erstmal rausfinden das ein fehlerhaftes Segment Register der Grund war und dann musst du noch unterscheiden ob es einfach "nur" ein Zugriff über Segmentgrenzen hinaus war (ist bei mir bei TLS möglich).

Welches das ist, nur durch den nachfolgenden Einsatz eines Disassemblers.

Wenn man davon ausgeht, das es eh nur ds, es, fs oder gs sein können die falsch sind, dann wäre es doch einfacher, sie entweder mit Standardwerten zu laden oder einfach die 4 zu überprüfen, aber ich glaube nicht das man einen Disassembler dafür bräuchte.

Ich finde eriks Idee immer besser.

Ich bin mir gerade nicht sicher ob du das ironisch oder ernst meinst

[kevin]

Swapping habe ich noch nicht, aber recht hast du trotzdem, hatte mal mit dem Gedanken gespielt lazy mapping im Kernel zuzulassen.
Aber Swapping möchte ich im Kernel sowieso nicht haben.

Ich sage ja nicht, dass du das im Kernel benutzen willst. Ich widerspreche nur der Behauptung, dass eine Exception immer ein Fehler ist. tyndur plant Exceptions an ein paar Stellen fest ein, aber die sind auch alle nur für Userspace.

Ich finde eriks Idee immer besser.

Ich bin mir gerade nicht sicher ob du das ironisch oder ernst meinst

Hm, der Smiley verunsichert mich. Meinst du das jetzt ironisch oder ernst?

[FlashBurn]

Ich widerspreche nur der Behauptung, dass eine Exception immer ein Fehler ist.

Doch

Eine Exception tritt nur auf wenn auch ein Fehler vorliegt (ob das nun ist, weil eine Page nicht vorhanden ist und aus dem Swapp-Speicher geholt werden muss oder eine Division durch 0)!

[kevin]

Wenn man sich die Definitionen zurechtbiegt, kann man natürlich alles beweisen. Für mich ist etwas kein Fehler, wenn es normaler Teil des Programmablaufs ist.

[erik.vikinger]

Hallo,

Denn das Problem ist, wie kann ich zw. nem richtigen NMI und ner IPI-Nachricht unterscheiden?

Sollte man im local APIC nicht rausbekommen ob er den NMI ausgelöst hat?

Also muss er immer die Segment Register neuladen.

Das sollten vielleicht alle Expection-Handler (Vectoren 0x00...0x1F) machen. Bremst ja nicht die Performance vom Syscall und dem Context-Switch-IRQ aus und um die geht es doch.

weil alle Exceptions und Interrupts aus dem Virtual-8086 Mode mit genullten Segment Registern im Kernel ankommen.

Hm, das wusste ich nicht, ich hab mich auch nie mit dem VM86 beschäftigt. Das ist schon eine gewisse Einschränkung.

Weil diese Exception könnte auftreten, während ein Lock gehalten wird.

Nicht wenn man dafür sorgt das noch relativ am Anfang der Assembler-Interrupt-Stubs DS und ES verwendet werden (einfach bei 2 Speicherzugriffen passende Präfixe benutzen) , FS und GS sind erst mal egal weil der vom Compiler erzeugte Kernel-Code die wohl nie benutzen wird.

und dass das die einzige Möglichkeit ist, im Exception Handler festzustellen, welcher Task der Verursacher der Exception war.

Die selbe Lösung wie zuvor.

Ich finde eriks Idee immer besser.

Meinst Du das ernst? (ja, ich meine meine Frage ernst und benutze hier absichtlich kein Smiley)


Grüße
Erik