オペレーティング システムの概念 (Silberschatz、Galvin、Gagne)、第 6 版、第 20 章を読んでいます。Linux カーネル コードはプリエンプティブルではないことを理解しています (2.6 バージョンより前)。ただし、ハードウェア割り込みによって中断される可能性があります。カーネルがクリティカル セクションの途中で割り込みが発生し、カーネルもクリティカル セクションを実行した場合はどうなりますか?
私が本で読んだことから：
Linux が使用する 2 番目の保護方式は、割り込みサービス ルーチンで発生するクリティカル セクションに適用されます。基本的なツールは、プロセッサの割り込み制御ハードウェアです...
このスキームは、ISR にクリティカル セクションがある場合に使用されます。ただし、それ以上の割り込みを無効にするだけです。そもそも、この割り込みによって中断されたカーネル コードはどうなるのでしょうか?
ただし、それ以上の割り込みを無効にするだけです。そもそも、この割り込みによって中断されたカーネル コードはどうなるのでしょうか。
割り込みハンドラと他のカーネル コードが同じデータにアクセスする必要がある場合は、通常はスピンロックによって保護する必要があります。細心の注意を払う必要があり、デッドロックを導入したくないため、このようなスピンロックは長時間保持されません。ハードウェア割り込みハンドラーで使用されるスピンロックの場合、ロックを保持している間、そのプロセッサの割り込みを無効にする必要があります。これは、Linux では関数 spin_lock_irqsave() で行われます。
(少し時代遅れですが、概念についてはこちらで読むことができます)
そもそもこの割り込みによって割り込まれたカーネルコードが割り込まれます。
これが、割り込みハンドラーの作成が非常に骨の折れる作業である理由です。割り込みハンドラーは、実行のメインストリームの正確さを危険にさらすようなことは何もできません。
たとえば、Appleのxnuカーネルがほとんどの種類のデバイス割り込みを処理する方法は、割り込み内の情報をメモリ内のレコードにキャプチャし、そのレコードをキューに追加してから、通常の実行を再開することです。次に、カーネルはしばらくしてからキューから割り込みを取得します（スケジューラーのメインループで、私は推測します）。このように、割り込みハンドラーは、割り込みキューを介してシステムの他の部分とのみ対話し、問題を引き起こす危険性はほとんどありません。
少し妥協点があります。多くのアーキテクチャ（x86を含む）では、特権コードが割り込みをマスクして、割り込みが発生しないようにすることができます。これは、実際には中断されるべきではないコードのパッセージを保護するために使用できます。ただし、これらのアーキテクチャには通常、マスク不可割り込みもあり、マスキングを無視するため、割り込みを考慮する必要があります。