「memfd」を「ファイルを所有するプロセス」に説明されていると考えるのは間違っていますか？
https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/ 理論的には、次のmemfd_create()ような新しいsyscallを導入せずに[ ]動作を実現できます。 int fd = open("/tmp", O_RDWR | O_TMPFILE | O_EXCL, S_IRWXU); （ここでtmpfsをより移植可能に保証するには、「/dev/shm」の代わりに「/tmp」を使用できます）。 したがって、最も重要な質問は、なぜ地獄には第三の方法が必要なのかということです。 [...] バッキングメモリは、ファイルを所有するプロセスに割り当てられ、mount-quotasの影響を受けません。 ^この文の最初の部分は信頼できないと思うのは正しいですか？ memfd_create（）コードは、文字通り「として実装されているカーネル内部でなければならない[A] TMPFSにリンクされていないファイル・リビング」。コードをトレースすると、LSMチェックを実装していない点が異なることを理解しています。また、ブログ投稿で説明しているように、「シール」をサポートするためにmemfdsも作成されています。ただし、memfdsが原則としてtmpfileとは異なる方法で説明されることは非常に懐疑的です。 具体的には、OOM-killerがノッキングを起こすと、memfdsが保持しているメモリを考慮しないと思います。これは、RAMの最大50％（tmpfsのsize =オプションの値）になります。カーネルは内部tmpfsに異なる値を設定しないため、デフォルトサイズの50％を使用します。 したがって、一般に、大きなmemfdを保持するプロセスを期待できるが、他の重要なメモリ割り当てはOOMで強制終了されないでしょう。あれは正しいですか？