☰

Linuxで/ procがオーバーレイfsになることができないのはなぜですか？

tag-icon • tag-icon linux mount proc overlayfs
Linuxで/ procがオーバーレイfsになることができないのはなぜですか？

Linuxで次のコマンドを実行すると（4.4.59および4.9.8でテスト済み）、失敗します。

mkdir -p /tmp/proc
mount -t overlay overlay -o lowerdir=/proc:/tmp/proc /tmp/proc

エラーメッセージがありますdmesg。

overlayfs: maximum fs stacking depth exceeded

/procファイルシステムを覆うレイヤーにできないのはなぜですか？に
交換するか、問題なくインストールすると、次のようになります。/proc/dev/sys/proc

PSユースケースは、より安全なchroot環境を作成することですが、これを/dev実行しようとしています。既知の解決策は2つあります。/sys/procchroot

  1. 読み取り専用バインドマウント。制限は必須コマンドではなく、2 つのコマンドです。
  2. 読み取り専用特殊マウント：mount -t proc -o ro none /tmp/proc制限は、サブマウントが自動的にマップされないことです。

/devとにかく、なぜオーバーレイが/sys正しく機能するのかはまだ疑問に思っていますが、うまく/procいきません。

問題が移行されました。スタックオーバーフローで。

答え1

https://github.com/torvalds/linux/commit/e54ad7f1ee263ffa5a2de9c609d58dfa27b21cd9

    /*
     * procfs isn't actually a stacking filesystem; however, there is
     * too much magic going on inside it to permit stacking things on
     * top of it
     */
s->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH;

これは有益な答えではないかもしれませんが、カーネル開発者は特にサポートしていません。

答え2

Greppingの「深さ」の発見は、/usr/src/linux/fs/overlayfs現在のスタック深さの簡単なチェックですFILESYSTEM_MAX_STACK_DEPTH。インクルードファイルを検索すると、FILESYSTEM_MAX_STACK_DEPTH2に定義されていることがわかりました/usr/src/linux/include/linux/fs.h。コメントは言う

fs スタックの最大レイヤ数。カーネルスタックのオーバーフローを防ぐために必要な制限

-filesystem は、または他のレベルの間接参照を追加するため、明らかにprocスタックの深さを超えました。より深く積み重ねることができない明確な理由がないので、カーネルを増やして再コンパイルして動作することを確認してください。これにより、カーネルはより多くのスタックを使用するため、通常はより多くのメモリが必要になり、速度が遅くなる可能性があります。実装の詳細はわかりません。devsysFILESYSTEM_MAX_STACK_DEPTH

編集するコメントに返信する

私の考えは、procファイルシステムが各モジュールのファイルを追跡し、モジュールが削除されたときにそのファイルを削除できるようにする必要があることです。デフォルトでは、すべてのモジュールのオーバーレイファイルシステムです。ところで、これを検証するためにはソースコードを詳しく読まなければなりませんでした（ソースコードも読むことができます。 :-)。

スタックの深さはstack_depthスーパーブロック構造の範囲内にあるため、それを表示するにはカーネルデータ構造にアクセスする方法が必要です。いくつかのカーネルデバッグツールがこれを行うことができると思います（または常に表示するためにカーネル拡張/モジュールを書くことができます）。しかし、具体的な方法はわかりません。

関連情報