私が理解したところ、Linuxカーネルは各プロセスが開始される前に各プロセスにスタックを割り当て、この初期サイズは設定可能です。プロセスは、PUSHＣＰＵ命令を介してデータをスタックに直接転送することができる。つまり、オペレーティングシステムはこれらの各ステップには関与しません。
ただし、ある時点でPUSH作業が中断される可能性があります。超過割り当てられたスタックサイズとカーネルが大きなスタックサイズを割り当てることができるかどうかに応じて、さまざまなことが発生する可能性があります。
私の質問は：初期化後にどうなりますかPUSH？システムは「スタックオーバーフロー」をどのように検出してそれを要求しますか？育つ最後までスタック履歴書プロセスの実行？
役に立つ場合は、x86アーキテクチャに集中できます。
私の考えには、次の当事者が関係しています。
- CPU
- メモリ管理ユニット
- コア
- プロセス
たとえば、「スタックオーバーフロー、CPUですか？MMUですか？これで問題が発生しますか？」を誰が検出しますか？ハードウェア割り込み？他にはありませんか？それでは、ここでは誰が処理しますか？ （スタックが最終的に拡張され、プロセスが次のCPU命令を再開できるまで？）
ベストアンサー1
ハードウェアまたはソフトウェアでスタックオーバーフローを検出しますか？
MMUは、スタックの予想サイズの後に無効なメモリアドレスを含むいくつかのパディングを残します。スタックを増やしすぎると、逆参照と無効なメモリアドレスが発生し、MMUでエラーが発生します。セグフォルト。
また、使用することができますカナリア値スタックにありますが、入ることはありません。
通常、コンパイラはコードの静的分析を実行し、スタックのサイズ変更を防ぐために必要なスタックサイズを見つけようとします。-fstack-usage は、gcc が実行する操作に関する洞察を提供します。
C標準は、Cスタックが大きくなる必要がある場合に暗黙的にmremapを呼び出すと定義します。これは、Linuxカーネルがこれらすべての操作を独自に処理することを意味します。
一つ過度の単純化タイムラインは次のとおりです。
プッシュ->MMU分割エラー->Linuxはそれを検出します->Linux リマップメモリ->挿入された値->ショーは続く
私は専門家ではないので、これを明確な答えとして受け入れるのではなく、そのトピックについてもっと読むことを強くお勧めします。