問題タブ [fxsave]

厄介な問題が発生し、デバッグしようとしている会社の多くのエンジニアが一時的に困惑しました。

C++ プログラムは通常、MPI を備えたマルチコア コンピューターのクラスターで実行されます。

非常に長い時間 (おそらく数日) 実行された後、突然失敗します。

それに取り組んでいるほとんどのエンジニアは、プログラム自体にバグがある可能性を排除したため、ハードウェアの問題の可能性を非難し始めていますが、Linux カーネル モジュールまたはデバイスのいずれかにソフトウェアの問題があるに違いないと思います。運転者。

疑わしいのは、カーネル モジュールまたはデバイス ドライバーが、いくつかの浮動小数点計算を行うために、SMP システムでは安全でない方法で FXSAVE/FXRSTOR を実行していることです。これは、再入可能にする必要があるカーネル ルーチンの静的バッファに対して FXSAVE を実行するのと同じくらい簡単なことかもしれません。これにより、競合状態のバグが発生し、スレッドの浮動小数点コンテキストがほとんど破損しなくなります。

アプリケーション レベルでは、FXSAVE/FXRSTOR コンテキストの一部である MXCSR の 1 つまたは複数のビットが突然変更されているように見えますが、それを変更するアプリケーション コードはありません。

何年も前に Windows で似たようなことがありましたが、最終的にはビデオ ドライバーのバグであることが判明しました。アプリケーション コードがオペレーティング システムによってプリエンプトされたときに、そのスレッドのコンテキストの一部の MXCSR ビットが破損していました。

私は Linux カーネルのハッキングやデバイス ドライバーの開発の専門家ではありませんが、再入可能性の規則が大幅に変更されていることを読んでいます。非 SMP システムと SMP (マルチコア) システムの間。カーネル バージョン間。など。したがって、競合状態のバグの可能性は妥当と思われます。

私の質問は次のとおりです。その説明に当てはまる既知の Linux ドライバー (またはカーネル) のバグはありますか?

同様の症状があった場合、私が引用できる前例があれば参考になります。この時点で、関係者の多くは (IMHO) 「私のコードにはバグがないので、ハードウェアが悪いに違いない」と考えて時間を無駄にしています。それを超えて、本当の原因である可能性が高いものを探したいと思います.

これはこの質問に関連して います。

私は Linux デバイス ドライバーやカーネル モジュールの専門家ではありませんが、Rubini & Corbet による「Linux Device Drivers」[O'Reilly] や多数のオンライン ソースを読んでいますが、見つけることができませんでした。この特定の問題についてはまだ何もありません。

カーネルまたはドライバー モジュールが浮動小数点レジスタを使用できるのはいつですか?
もしそうなら、誰がその内容を保存して復元する責任がありますか?
(x86-64 アーキテクチャを想定)

私の理解が正しければ、KM が実行されているときは常に、何らかのアプリケーション スレッドからプリエンプトされたハードウェア コンテキスト (またはハードウェア スレッドまたはレジスタ セット - 任意の名前) を使用しています。KM を c で記述した場合、コンパイラは汎用レジスタが適切に保存および復元されることを (アプリケーションと同様に) 正しく保証しますが、浮動小数点レジスタではそれが自動的に行われません。さらに言えば、多くの KM は、プロセッサに浮動小数点機能があると想定することさえできません。

浮動小数点を使用したい KM は、浮動小数点の状態を慎重に保存して復元する必要があると推測するのは正しいですか? これを行うための標準のカーネル関数はありますか?

このためのコーディング規約はどこかに明記されていますか?
それらは SMP 非 SMP ドライバーとは異なりますか?
古い非プリエンプティブ カーネルと新しいプリエンプティブ カーネルで違いはありますか?