Show Table of Contents
メモリーを保存するための
GFS2 の競合条件を原因とするカーネルの
kabi-whitelists コンポーネントが利用できない場合でも
第30章 カーネル
以前はクラッシュダンプ中に破損していた PT_NOTE エントリーが修正された
一部の HP サーバーでは、カーネルのコードに欠陥があったため、カーネルのクラッシュが発生すると、PT_NOTE エントリーが破損してしまう場合がありました。そのため、カーネルクラッシュダンプユーティリティーの初期化に失敗してしまいました。今回提供されたパッチにより、PT_NOTE エントリーが 1 つの物理ページ内に配置されるように割り当てが調整され、書き込みと読み取りのデータが全く同じになるようになったため、カーネルクラッシュダンプはこのような状況でも想定どおりに機能するようになりました (BZ#1073651)。
メモリーを保存するための slub_debug パラメーターが削除された
以前のリリースでは、
slub_debug パラメーターにより、各オブジェクトが追加のメモリーを使用できるようにする SLUB アロケーターのデバッグが有効化されていました。slub_debug カーネルパラメーターが使用されている場合には、128 GB システムで自動設定により kdump キャプチャーカーネルに割り当てられるメモリーは十分ではありませんでした。そのため、kdump init スクリプトのさまざまなタスクが Out Of Memory (OOM) のエラーメッセージで終了し、クラッシュダンプは保存されませんでした。今回のリリースでは、slub_debugパラメーターを削除するためのパッチが提供され、クラッシュダンプはこのようなシナリオで想定どおりにクラッシュダンプを保存するようになりました (BZ#1180246)。
新規 CPU のアタッチ時にデッドロックの原因となっていた競合条件が削除された
以前のリリースでは、新しい CPU がアタッチされると、CPU のホットプラグと stop_two_cpus() 関数の間で競合状態が発生する場合があり、その新しい CPU 上の移行スレッドがすでに
active にマークされていても enabled されていない状態の場合にはデッドロックの原因となっていました。今回のリリースではパッチセットが適用され、この競合条件は削除されたため、システムに新しい CPU をアタッチしても、意図したとおりに動作するようになりました (BZ#1252281)。
アップストリームからのヒュージページ移行のパッチでカーネルが更新された
以前のリリースでは、ヒュージページの移行で、カーネルパニックを含む複数のタイプのバグが発生することがありました。今回のリリースでは、アップストリームからのパッチセットがバックポートされ、それらのバグは修正されました。更新されたカーネルは、より安定し、ヒュージページの移行は AMD64 および Intel 64 以外のアーキテクチャーでは自動的に無効化されるようになりました (BZ#1287322)。
UEFI およびセキュアブートを有効化したカーネルのブート
以前のリリースでは、Unified Extensible Firmware Interface (UEFI) を使用している場合にセキュアブートを有効化すると、オペレーティングシステムは 3.10.0-327.3.1.el7.x86_64 以降の全カーネルでブートに失敗していました。今回のリリースではカーネルが 3.10.0-327.4.4.el7 以降のバージョンに更新され、システムは想定どおりにブートするようになりました (BZ#1290441)。
インストール済みの全カーネル向けの initramfs イメージに新規マイクロコードが追加された
以前のリリースでは、microcode_ctl パッケージがインストールされると、インストール後のスクリプトレットにより実行中のカーネル向けのみに initramfs ファイルが作成され、他のインストール済みカーネル向けには作成されませんでした。そのため、ビルドが完了すると、インストールもされていないカーネル向けの initramfs ファイルが作成されていました。今回の修正により、インストール済みの全カーネル向けの initramfs イメージに新たなマイクロコードが追加されるようになりました。その結果、不必要な initramfs ファイルは生成されなくなりました (BZ#1292158)。
GFS2 の競合条件を原因とするカーネルの slab エラーが発生しない
以前のリリースでは、GFS2 ファイルシステムで、ディレクトリーのルックアップに使用されるカーネルの
slab メモリーを 2 つのプロセスが同時に解放しようとして、競合状態が発生していました。そのため、両プロセスが同じメモリーを解放すると、カーネルで slab メモリーエラーが発生していました。今回のリリースでは、GFS2 ファイルシステムにパッチが適用されて競合状態が発生しないようになり、1 つのプロセスがすでに解放しているメモリーを別のプロセスが解放を試みることはできなくなりました。メモリーの解放を試みる際に各プロセスは、順番に処理を行うように強制されます。その結果、カーネルの slab エラーは発生しなくなりました (BZ#1276477)。
GFS2 がファイル内の正しい場所にデータを書き込む
以前のリリースでは、GFS2 ファイルシステムは、4 KB を超える場所で
O_DIRECT (Direct I/O) を使用して開いたファイルの書き込み時に、開始オフセットの計算を誤っていたため、データがファイル内の間違った場所に書き込まれていました。GFS2 にパッチが適用され、Direct I/O 書き込のファイルオフセットが正しく計算されるようになりました。その結果、GFS2 はファイル内の正しい場所にデータを書き込むようになりました (BZ#1289630)。
kdump のメカニズムでエラーが発生した場合に、ダンプキャプチャーカーネルのメモリーが解放される
以前のリリースでは、
,high および ,low の構文を使用してクラッシュカーネルのメモリー割り当てられる場合に、high の部分の予約は正常に処理されましたが、low の部分の予約で kdump のメカニズムが失敗する場合がありました。このエラーは特に大型のシステムで発生することがあり、それには複数の理由がありました。手動で指定したクラッシュカーネルの low メモリーが大き過ぎるため、適切な memblock リージョンが見つかりませんでした。kexec ユーティリティーはダンプキャプチャーカーネルを正常に読み込むことは可能でしたが、low メモリーがなかったため、ダンプキャプチャーカーネルのブートに失敗していました。今回のリリースではパッチセットが適用され、ダンプキャプチャーカーネル用の low メモリーは、high のメモリーが割り当てられた 後で 予約されるようになりました。その結果、kdump メカニズムでエラーが発生した場合には、ダンプキャプチャーカーネルのメモリーが解放されるようになり、ユーザーが適宜対策を取る機会が提供されるようになりました (BZ#1241236)。
kabi-whitelists コンポーネントが利用できない場合でも ksc ユーティリティーはバグの提出で失敗しない
以前の更新により、
kabi-whitelists コンポーネントは、 カーネルコンポーネントの kabi-whitelists サブコンポーネントに変更されて、kabi-whitelists コンポーネントの値が有効ではなかったため、ksc ユーティリティーがバグを提出することはできずに、以下のようなエラーメッセージが生成されていました。
Could not create bug.<Fault 32000:"The component value 'kabi-whitelists' is not active">
今回の更新により、カーネルコンポーネントの正しいサブコンポーネントが kabi-whitelist に含まれるようになり、ksc は想定どおりにバグを提出するようになりました (BZ#1328384)。
ksc が、必須の引数を指定せずに実行すると、クラッシュせずにエラーメッセージを返す
以前のリリースでは、必須の引数を指定せずに
ksc ツールを実行すると予期せず終了していました。今回の更新により、ksc は、このような状況ではエラーメッセージを返してから、正常に終了するようになりました (BZ#1272348)。
ext4 ファイルシステムが想定どおりにサイズ変更できる
以前のリリースでは、ext4 コードのバグが原因で、ブロックサイズが 1 キロバイトの、32 メガバイト未満の ext4 ファイルシステムはサイズ変更できませんでした。今回の更新で、このバグを修正するためのパッチが適用され、このような ext4 ファイルシステムにおけるサイズ変更が想定どおりにできるようになりました (BZ#1172496)。
qdisc を仮想デバイスにアタッチした時に予期しない動作が発生しない
以前のリリースでは、qdisc を仮想デバイスにアタッチすると、処理が完了する前にパケットが破棄されてしまったり、帯域幅が削減されるなどの予期せぬ動作が発生する場合がありました。今回の更新により、仮想デバイスには、
tx_queue_len がデフォルトで 1000 に設定され、それらのデバイスはデバイスフラグで示されるようになりました。仮想デバイスへの qdisc のアタッチは、デフォルトの設定でサポートされるようになり、tx_queue_len=0 を特別に処理する必要はなくなりました (BZ#1152231)。
udev デーモンが dracut よって停止されない
以前のリリースでは、
initramfs プロセス中に dracut スクリプトによって、udevadm control コマンドを使用して udev デーモンが停止され、udev デーモンは終了してしまっていましたが、systemd サービスのポリシーはこのデーモンを再起動するようになっていました。特定の状況では、この問題によりシステムがブートできませんでした。今回の更新により、udev デーモンを停止するコードは dracut スクリプトから削除されて、このような問題が発生しないようになりました (BZ#1276983)。
multi-fsb バッファーのロギングが修正された
以前のリリースでは、ブロックサイズが大きな XFS ファイルシステムでディレクトリーを変更するとカーネルパニックが発生し、マルチブロックバッファーのロギングでの問題が原因でサーバーがクラッシュする場合がありました。今回のリリースでは、パッチが適用されて multi-fsb バッファーのロギングが修正され、このシナリオではサーバーはクラッシュしなくなりました (BZ#1356009)。
第 6 世代 インテル Core プロセッサーの統合型グラフィックスを使用するラップトップで、画面のハードロックアップが発生しない
以前のリリースでは、第 6 世代 インテル Core プロセッサーの統合型グラフィックスを使用するラップトップで、以下のような場合に画面のハードロックアップが発生することがありました。
- モニターの端から端にカーソルを移動した場合
- 複数のモニター間でカーソルを移動した場合
- モニター設定のアスペクト比を変更した場合
- マシンをドッキングまたはドッキング解除した場合
- モニターを結線または抜線した場合
今回のリリースではこのバグは修正され、このような状況で画面のハードロックアップは発生しなくなりました (BZ#1341633)。
永続メモリーを使用するシステムで複数の問題が修正された
memmap=X!Y カーネルコマンドラインパラメーターを使用して実際の Non-Volatile Dual In-line Memory Modules (NVDIMM) またはエミュレーションされた NVDIMM のいずれかの永続メモリーを使用してシステムでブート中に複数の問題が発生する場合がありました。
永続メモリーをオンラインにすると、
pmem デバイスの全ブロック (128 MB) に対して以下のようなメッセージが表示されました。
Built 2 zonelists in Zone order, mobility grouping on. Total pages: 8126731 Policy zone: Normal
この結果、システムが応答しなくなりました。
また、以下の
BUG メッセージが表示されました。
BUG: unable to handle kernel paging request at ffff88007b7eef70
今回の更新でこのバグは修正されました (BZ#1367257)。
SUDO_USER および USER の変数が設定されていない場合に python エラーが表示されない
以前のリリースでは、
SUDO_USER または USER の環境変数が設定されていない予備の環境で操作を実行すると、多数の python エラーが表示されていました。今回の更新では、未定義の SUDO_USER および USER 変数が正しく処理されるようになり、エラーは表示されなくなりました (BZ#1312057)。
CIFS 匿名認証が失敗しない
以前のリリースでは、
cifs モジュールが匿名認証のための値を間違って設定していました。このバグは、samba ファイルサーバーに加えられた変更が原因でした。そのために匿名認証が失敗していました。今回の更新により、クライアントの動作が変更され、正しい auth 値が設定されるようになりました。その結果、CIFS の匿名認証は正常に操作するようになりました (BZ#1361407)。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.