Eine kurze Analyse des asynchronen Signalhandles unter Linux

Linux-System ist ein Betriebssystem, das die gleichzeitige Ausführung mehrerer Aufgaben unterstützt. Es kann mehrere Prozesse gleichzeitig ausführen und dadurch die Systemauslastung und -effizienz verbessern. Wenn jedoch Datenaustausch und Zusammenarbeit zwischen diesen Prozessen erforderlich sind, müssen einige IPC-Methoden (Inter-Process Communication) verwendet werden, z. B. Nachrichtenwarteschlangen, gemeinsam genutzter Speicher, Semaphore usw. Unter diesen ist Signal eine relativ einfache und flexible IPC-Methode, die es einem Prozess ermöglicht, eine kurze Nachricht an einen anderen Prozess zu senden, um ihn darüber zu informieren, dass ein Ereignis oder eine Ausnahme aufgetreten ist. In Linux-Systemen gibt es zwei Arten von Signalen, nämlich synchrone Signale und asynchrone Signale. In diesem Artikel wird die asynchrone Signalverarbeitungsmethode von Linux kurz analysiert, einschließlich der Bedeutung, Erzeugung, Sendung, Empfang, Verarbeitung und Ignorierung asynchroner Signale.

Als ich zum ersten Mal die Linux-Programmierung lernte, hatte ich immer das Gefühl, dass das asynchrone Signalhandle eine sehr magische Sache ist. Benutzerprogramme können Systemaufrufe wie Singal verwenden, um eine Signalverarbeitungsfunktion (Handle-Funktion) für ein bestimmtes Signal zu registrieren.
Der Binärcode des Programms hat einen bestimmten Ausführungsfluss im Speicher. Warum wird das Programm nach dem Empfang eines asynchronen Signals „unterbrochen“ und springt dann zur Ausführung in die Handle-Funktion? Wie kann der Kernel das Programm zu einem solchen Sprung veranlassen? Es ist unmöglich, den ausführbaren Code des Programms vorübergehend zu ändern, oder?

Nachdem ich einige Kernel-Kenntnisse erlernt hatte, wurde mir klar, dass ein Prozess, nachdem er ein Signal empfangen hat, nicht sofort „unterbrochen“ wird, sondern zunächst den Empfang eines bestimmten Signals in der Kontrollstruktur des Prozesses (task_struct) aufzeichnet und dann wartet, bis das Wenn der Prozess vom Kernelmodus in den Benutzermodus zurückkehren soll, wird der Prozess „unterbrochen“ und die Handle-Funktion aufgerufen.
Wann kehrt der Benutzerprozess vom Kernelmodus in den Benutzermodus zurück? Im Allgemeinen gibt es drei Hauptsituationen: Systemaufruf (der Benutzerprozess betritt aktiv den Kernel), Unterbrechung (der Benutzerprozess betritt passiv den Kernel) und geplante Ausführung (der Benutzerprozess wechselt vom Warten auf die Ausführung zur Ausführung).
Es dauert eine gewisse Zeit, bis der Prozess nach dem Empfang des Signals vom Kernel-Status in den Benutzerstatus zurückkehrt. Diese Zeit ist jedoch im Allgemeinen sehr kurz, zumindest bringt der Taktinterrupt den Benutzerprozess mit relativ hoher Frequenz (z. B. einmal alle 1 Millisekunde) in den Kernel (natürlich nur für den ausführenden Prozess).

Wenn der Prozess vom Kernelmodus in den Benutzermodus zurückkehrt und ein Signal vorhanden ist, das verarbeitet werden muss, wird die entsprechende Handle-Funktion aufgerufen (natürlich ist das Handle möglicherweise nicht registriert, der Kernel jedoch). verarbeitet das Signal standardmäßig). Beachten Sie, dass sich der Prozess noch im Kernelmodus befindet. Wie ruft der Kernel die Handle-Funktion im Benutzermodus auf?
Kann ich es direkt anrufen? Natürlich nicht. Der Kernelcode wird unter einer hohen CPU-Berechtigungsstufe ausgeführt. Wenn die Handle-Funktion direkt aufgerufen wird, wird die Handle-Funktion auch unter derselben CPU-Berechtigung ausgeführt. Dann kann der Benutzer in der Handle-Funktion tun, was er will.
Daher muss das aufrufende Handle zunächst in den Benutzermodus zurückkehren. Nach der Rückkehr in den Benutzermodus wird der Programmablauf jedoch nicht mehr vom Kernel gesteuert. Ist es möglich, dass der Kernel tatsächlich vorübergehend den ausführbaren Code des Benutzerprozesses ändert?

Der eigentliche Ansatz des Kernels ist ziemlich clever. Nachdem ein Benutzerprozess den Kernel betreten hat, hinterlässt er eine Rücksprungadresse auf dem entsprechenden Kernel-Stack, damit der Prozess zurückkehren kann. Die Art und Weise, wie der Kernel die Handle-Funktion aufruft, besteht darin, die Rücksprungadresse auf dem Stapel vorübergehend zu ändern und dann entsprechend dem ursprünglichen Prozess der Rückkehr in den Benutzermodus zurückzukehren. Infolgedessen geht diese Rückgabe an die Handle-Funktion. (Natürlich muss nicht nur die Absenderadresse geändert werden, sondern der gesamte Aufrufstapel.)
Obwohl die Absenderadresse vorübergehend geändert wurde, kehrt der Benutzerprozess schließlich zur ursprünglichen Absenderadresse zurück. Wo sollten also die ursprüngliche Rücksendeadresse und ihr Aufrufstapel gespeichert werden? Der Kernel-Stack-Speicherplatz des Prozesses ist begrenzt und er muss sich auch mit Systemaufrufen befassen, die in der Handle-Funktion auftreten können. Daher ist es für den Kernel unrealistisch, diese Informationen auf dem Kernel-Stack abzulegen und sie nur an den Benutzer weiterzugeben Stapel.

Wenn die Handle-Funktion ausgeführt wird, kehrt der Ausführungsprozess zum Kernel zurück. Ebenso können Sie aufgrund unterschiedlicher CPU-Berechtigungsstufen nicht einfach die RET-Anweisung verwenden, um von der Handle-Funktion zum Kernel zurückzukehren. Es muss ein Systemaufruf ausgeführt werden.

Warum müssen wir nach der Ausführung des Handles zum Kernel zurückkehren und dann vom Kernel zur ursprünglichen Rücksprungadresse zurückkehren? Es wäre sehr praktisch, wenn Sie direkt zur ursprünglichen Rücksendeadresse zurückkehren würden. Und das ist nicht schwierig. Die ursprüngliche Rücksprungadresse und ihr Aufrufstapel wurden auf den Benutzerstapel verschoben. Der Kernel muss nur eine kleine Manipulation am Aufrufstapel der Handle-Funktion vornehmen.
1. Die Rückkehr zur ursprünglichen Absenderadresse bedeutet nicht nur die Rückkehr zu dieser Adresse. Sie müssen die gesamte Szene wiederherstellen (hauptsächlich Register usw.). Natürlich kann der Kernel auch Code auf den Benutzerstapel drücken, um diese Dinge abzuschließen;
2. Jetzt muss möglicherweise mehr als ein Signal verarbeitet werden. Es ist am besten, den Benutzer zum Kernel zurückkehren zu lassen und mit der Verarbeitung anderer Signale fortzufahren

Um zum Kernel zurückzukehren, schiebt der Kernel zunächst eine Rücksprungadresse auf den Benutzerstapel, bevor er zur Handle-Funktion zurückkehrt, damit er bei der Rückkehr vom Handle zur angegebenen Adresse zurückkehren kann. Diese angegebene Adresse befindet sich tatsächlich auch auf dem Benutzerstapel des Prozesses. Der Kernel platziert mehrere Anweisungen an dieser Adresse (platziert ausführbaren Code auf dem Stapel), damit der Prozess einen Systemaufruf namens sigreturn aufrufen kann.

Der Benutzerstapel vor der Rückkehr zur Handle-Funktion sieht ungefähr wie folgt aus:
Originaldaten -> Anweisung zum Aufruf von Sigreturn (seine Adresse sei a) -> Ursprüngliche Rücksprungadresse und ihr Aufrufstapel -> Rücksprungadresse (Wert ist a) -> Stapelvariable des Handles

Der Kernel platziert die sigreturn-Anweisung auf dem Aufrufstapel der Handle-Funktion, was in Linux 2.4 üblich ist. Jedes Mal, wenn die Handle-Funktion des Benutzers aufgerufen wird, müssen so viele Anweisungen in den Benutzerstapel kopiert werden, was nicht gut ist.
Linux 2.6 verfügt über eine Seite namens vsyscall page, die einige vom Kernel für Benutzerprogramme vorbereitete Anweisungen enthält, einschließlich des Aufrufs der sigreturn-Anweisung. Diese Vsyscall-Seite wird dem Ende des virtuellen Adressraums jedes Prozesses zugeordnet, wird von allen Benutzerprozessen gemeinsam genutzt und ist für Benutzerprozesse schreibgeschützt. Auf diese Weise ist es nicht erforderlich, die Sigreturn-Anweisung in den Aufrufstapel der Handle-Funktion einzufügen. Setzen Sie einfach die Rückgabeadresse der Handle-Funktion auf den entsprechenden Code auf der Vsyscall-Seite.

Um nach der Ausführung des Handles automatisch sigreturn aufzurufen und zum Kernel zurückzukehren, führt der Kernel viele Dinge aus. Können wir also zustimmen, dass Benutzer Sigreturn selbst aufrufen können?
Natürlich ist das möglich. Nur um den Signalverarbeitungsmechanismus zu einem vollständigen Mechanismus zu machen, hat der Kernel dies nicht getan. Andernfalls kann der Prozess aus unerklärlichen Gründen abstürzen, wenn der Benutzer vergisst, sigreturn in der Handle-Funktion aufzurufen. Und für den Compiler ist es schwierig, solche Fehler zu finden.

Nachdem der Prozess den Sigreturn-Systemaufruf aufruft und erneut in den Kernel eintritt, werden die ursprüngliche Rücksprungadresse und der auf den Benutzerstapel gedrückte Aufrufstapel abgerufen. Schließlich ändert der Kernel den Stapel, sodass der Prozess zur ursprünglichen Rücksprungadresse zurückkehrt, wenn er in den Benutzerbereich zurückkehrt.

In diesem Artikel wird kurz die asynchrone Signalverarbeitungsmethode von Linux analysiert, einschließlich der Bedeutung, Erzeugung, des Sendens, Empfangens, Verarbeitens und Ignorierens asynchroner Signale. Durch das Verständnis und die Beherrschung dieses Wissens können wir das Kernwissen der Linux-Signalverarbeitung beherrschen und dadurch die Stabilität und Effizienz des Systems verbessern. Natürlich verfügt das asynchrone Signalhandle von Linux über viele andere Funktionen und Verwendungsmöglichkeiten, die kontinuierliches Lernen und Forschung erfordern. Ich hoffe, dieser Artikel kann Ihnen Inspiration und Hilfe bringen.

Das obige ist der detaillierte Inhalt vonEine kurze Analyse des asynchronen Signalhandles unter Linux. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!