LWN：pidfdfs 帶來的另一個意外！

關(guān)注了就能看到更多這么棒的文章哦～

One more pidfdfs surprise

By Jonathan Corbet
May 31, 2024
Gemini-1.5-flash translation
https://lwn.net/Articles/976125/

“pidfdfs” 虛擬文件系統(tǒng) (virtual filesystem) 在 6.9 內(nèi)核版本中被添加，其目的是為了向用戶空間 (user space) 提供關(guān)于運行進程 (running processes) 更完善的信息。它取代了之前的一個實現(xiàn)，表面上是完全兼容的，同時還增加了一些新的功能。這個過渡原本意圖對現(xiàn)有的應(yīng)用程序 (applications) 完全透明，但早在今年三月就 遇到了問題，當(dāng)時 SELinux 的一個誤解導(dǎo)致了安裝了 pidfdfs 的系統(tǒng)無法正常啟動 (boot)。這個問題很快就被解決了，但事實證明，還有一個驚喜在等著我們，它表明 ABI 兼容性有時是多么難以實現(xiàn)。

pidfd 是一個標(biāo)識運行進程的文件描述符 (file descriptor)。在內(nèi)核 (kernel) 中，它必須包含所有與文件描述符相關(guān)的正常數(shù)據(jù)結(jié)構(gòu)，這樣內(nèi)核子系統(tǒng)才能知道如何處理它。從 2007 年的 2.6.22 版本開始，內(nèi)核就有一個小型的輔助機制，為那些沒有實際文件支持的虛擬文件系統(tǒng)上的文件描述符提供匿名 inode (anonymous inodes)。當(dāng) pidfd 抽象 被添加到 5.1 內(nèi)核時，它自然地使用了匿名 inode，并且一切如預(yù)期地工作。

然而，最終，這種實現(xiàn)的局限性開始顯現(xiàn)。為了解決這個問題，Christian Brauner 重構(gòu)了實現(xiàn)，不再使用匿名 inode，而是創(chuàng)建了獨立的 pidfdfs 文件系統(tǒng)。新文件系統(tǒng)支持在 pidfd 上使用 statx()；這反過來又讓用戶空間能夠獲得真正的 inode 編號，可以用它們來比較兩個 pidfd 是否相等。新的功能（比如當(dāng)引用某個進程的最后一個 pidfd 被關(guān)閉時殺死該進程）成為可能。新實現(xiàn)也讓安全模塊 (security modules) 參與了 pidfd 操作；這是第一組問題的根源，但從長遠來看，它將幫助管理員更好地控制他們的系統(tǒng)。

當(dāng)安全模塊問題解決后，似乎 pidfdfs 的問題已經(jīng)解決了。但隨后，Jiri Slaby 報告說，安裝了 pidfdfs 的內(nèi)核破壞了 util-linux 測試套件和 lsof 實用程序。Brauner 回答說 util-linux 的問題已經(jīng)在上游被修復(fù)了，但 lsof 卻是一個意外。事實證明，有兩個問題需要解決，其中一個比另一個更容易預(yù)先想到。

在 6.9 之前的系統(tǒng)中，"ls -l" 或 lstat() 會將 pidfd 顯示為指向字符串 "anon_inode:[pidfd]" 的符號鏈接 (symbolic link)。從 6.9 開始，結(jié)果變成了 "pidfd:[=/=inode=/=]", 顯示了分配給 pidfd 的 inode 編號。由于 lsof 在尋找 6.9 之前的字符串版本，因此它無法識別或正確處理 pidfd。

但事實證明，還有更多問題。當(dāng)匿名 inode 代碼被添加時，作者從未費心 (或者只是忘記了) 在創(chuàng)建每個 inode 時設(shè)置其中的文件類型字段。因此，像 stat() 這樣的系統(tǒng)調(diào)用會報告文件類型為零，而這實際上并非定義好的文件類型。這會導(dǎo)致像 stat 這樣的命令行工具將結(jié)果描述為“奇怪的文件”(weird file)，這客觀上是正確的。這個小問題從未對真正使用匿名 inode 支持的文件的工具造成過麻煩，因此它從未被修復(fù)。

但它還是被注意到了。某個正在開發(fā) lsof 的人巧妙地意識到，文件類型為零是一種識別匿名 inode 文件的方便方法。因此， lsof 獲得了一個針對此條件的測試，利用了從未被預(yù)期，更不用說記錄的 ABI 特性。一旦對 pidfd 的 stat() 調(diào)用開始返回正確的文件類型， lsof 便不再識別該文件，并變得不知所措。當(dāng)這一切查清楚時，Linus Torvalds 并不高興：

真是糟糕。太可怕了，我們顯然從未注意到 anon_inode 有多糟糕，因為沒有人真正關(guān)心。但隨后 lsof 似乎做了 相反 的事情，只是 (出于難以理解的原因) 說“這不可能是一個正常的普通文件”。

也就是說，他也承認，“我們可能不得不睡在我們自己做的床上（意思是自食其果）”；破壞 lsof 是一個需要修復(fù)的用戶空間 (user-space) 回歸問題。

Brauner 編寫了一個補丁，該補丁在 6.10-rc1 版本發(fā)布之前被 合并；它尚未進入 6.9 穩(wěn)定更新。該補丁恢復(fù)了 pidfd 的舊輸出格式，并使文件類型字段被顯式地屏蔽為零，恢復(fù)了之前行為。有了這個修復(fù)， lsof 再次工作，人們大多很滿意。

當(dāng)他 發(fā)送補丁 時，Brauner 說他“希望在不久的將來嘗試擺脫目前這種瘋狂的行為”。他希望 lsof 能被修復(fù)，以便能夠處理新的輸出格式，并且能夠刪除這個兼容性 hack。Torvalds 似乎愿意嘗試，但他指出，一些用戶 (及其發(fā)行版) 更新用戶空間工具的速度可能非常慢，因此可能要很長時間才能不再需要這個更改。

總而言之：Hyrum's law 再次證明了它的適用性。在類型字段中留零從未被設(shè)計為匿名 inode 的 ABI 部分；它只是一個錯誤，一個工作沒有完全完成的產(chǎn)物。但由于這種行為是可見的，代碼開始依賴它，而這個錯誤無法再被修復(fù)。這一事件再次暗示，內(nèi)核接口在發(fā)布到內(nèi)核版本之前可能需要比通常更高的審查級別。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

歡迎分享、轉(zhuǎn)載及基于現(xiàn)有協(xié)議再創(chuàng)作～

長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～