LWN:BPF 里新的共享內(nèi)存方案!

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

A proposal for shared memory in BPF programs

By Daroc Alden
February 21, 2024
Gemini translation
https://lwn.net/Articles/961941/

2021 年 2 月 6 日，Alexei Starovoitov 提交了一系列的補?。╬atch series）給 Linux 內(nèi)核，以添加 bpf_arena ，這是一種新的共享內(nèi)存類型，用于 BPF 程序與用戶空間之間的通信。Starovoitov 期望這種 arena 對于用戶空間和 BPF 程序之間的雙向通信以及作為 BPF 程序的額外堆空間將會非常有用。這有助于直接實現(xiàn)復(fù)雜數(shù)據(jù)結(jié)構(gòu)而不依賴于內(nèi)核提供的 BPF 程序。Starovoitov 以 Google的ghOSt項目為例，這個項目是他的工作的一個例子和靈感來源。

BPF 程序已經(jīng)有幾種與用戶空間通信的方式，包括環(huán)形緩沖區(qū)、哈希映射和數(shù)組映射。然而，每種方法都存在一些問題。環(huán)形緩沖區(qū)（ring buffer）可以用于將性能測量或跟蹤事件發(fā)送到用戶空間進程，但不能從用戶空間接收數(shù)據(jù)。哈希映射（hash map）可以用于此目的，但從用戶空間訪問它們需要進行bpf()系統(tǒng)調(diào)用。數(shù)組映射（array map）可以使用mmap()將它們映射到用戶空間進程的地址空間中，但 Starovoitov 指出它們的“缺點是數(shù)組的整個內(nèi)存在開始時就被預(yù)留下來”。數(shù)組映射（以及新的 arena）存儲在不可分頁的內(nèi)核內(nèi)存中，所以未使用的頁面會產(chǎn)生明顯的資源利用效率上的浪費。

他的補丁系列允許 BPF 程序創(chuàng)建最多 4GB 大小的 arena。與數(shù)組映射不同，這些 arena 不會預(yù)先分配頁面。BPF 程序可以使用 bpf_arena_alloc_pages() 向 arena 添加頁面，并且當(dāng)用戶空間程序在 arena 內(nèi)觸發(fā)頁面錯誤（page fault）時，頁面將被自動添加進來。

無縫指針（seamless pointers）

該補丁系列以一種不尋常的方式處理 arena 內(nèi)的指針，確保 arena 內(nèi)部的結(jié)構(gòu)可以指向 arena 的其他區(qū)域，并且這對用戶空間程序和 BPF 程序都可以無縫地工作，而不需要意識到存在隱式的轉(zhuǎn)換。盡管這兩種程序完全有不同的指針表示，但它們都不需要意識到存在隱式轉(zhuǎn)換。BPF 程序?qū)?arena 內(nèi)的指針表示為 32 位指針，處于單獨的地址空間中（驗證器 BPF verifier 會確保其不用作普通指針，反之也一樣），但用戶空間程序?qū)⒅羔樢暈槠潴w系結(jié)構(gòu)的普通指針。用戶空間表示實際存儲在 arena 內(nèi)存中。內(nèi)核映射 arena 空間時，保證用戶空間指針的低 32 位始終與 BPF 指針匹配，以加快兩種表示之間的轉(zhuǎn)換。

例如，這個系列包括一個程序作為測試套件的一部分，在 BPF 中實現(xiàn)了一個哈希表，使用鏈表來把屬于同一類的項目串起來。可以在內(nèi)核中完成哈希表的生成，然后從用戶空間訪問，反之亦然，兩者都能夠跟隨數(shù)據(jù)結(jié)構(gòu)中的指針。

該補丁系列引入了兩個函數(shù) bpf_cast_kern() 和 bpf_cast_user() ，用于在內(nèi)核表示的指針和用戶空間表示的指針之間進行轉(zhuǎn)換。有一個相關(guān)的補丁來為LLVM的BPF 后端自動插入正確的轉(zhuǎn)換動作，以確保用戶空間版本是存儲在 arena 內(nèi)存中的版本。該補丁系列引入了一個新的標(biāo)志（ BPF_F_NO_USER_CONV ），以允許 BPF 程序關(guān)閉此行為。未執(zhí)行指針轉(zhuǎn)換的 arena 仍然可以映射到用戶空間，但用戶空間程序?qū)o法跟隨其中包含的指針。

審查意見

Barret Rhoden指出了這種轉(zhuǎn)換實現(xiàn)的一個細節(jié)問題。補丁系列的初始版本在 arena 中留下了一個空洞（取決于 arena 在用戶空間的映射位置），以便 BPF 不會生成以 0x00000000 結(jié)尾的指針。這樣的對象在轉(zhuǎn)換為 32 位指針時，在 BPF 程序中具有全零表示，這可能與空指針混淆并引發(fā)問題。Rhoden 指出，如果 BPF 程序嘗試訪問缺失的頁面，將會引發(fā)頁面錯誤并終止程序，他指出如果有人意外使用了這個零頁面，我們將遇到更嚴(yán)重的問題。Starovoitov 同意了這一觀點，并表示他將在系列的第二版中刪除缺失的頁面，因為該邏輯“在帶來更多傷害而不是好處”。移除 arena 中的空洞后，BPF 程序需要避免將對象放在 0 地址處然后嘗試獲取指向它的指針，這可以通過在 arena 開頭添加一些填充來輕松實現(xiàn)。

確保內(nèi)核和用戶空間就 arena 指針的低 32 位達成一致是有必要的，因為這可以使 BPF 即時（JIT）編譯器生成的代碼更簡單，因此更快。如果用戶空間可以將 arena 映射到任意地址，就像這個補丁系列的初始版本中的情況一樣，這將使得內(nèi)核中 arena 的表示相對復(fù)雜一些，并且可能需要額外的邏輯來清晰地處理 arena 地址的環(huán)繞。Rhoden 和 Starovoitov 繼續(xù)討論這個細節(jié)，并最終得出結(jié)論：沒有理由支持將 arenas 真正映射到任意地址。Rhoden評論說：“將 4GB 映射對齊到 4GB 邊界的限制非常合理?！?br>

Lorenzo Stoakes對補丁系列中的分配頁方式提出了異議，因為它使用vmap_pages_range()來為 arena 分配頁面，而這是內(nèi)核虛擬內(nèi)存分配器的一個內(nèi)部函數(shù)。 Stoakes 說：“我在 Vmap()中看到很多檢查，而 vmap_pages_range()中并沒有?！彼麊枴拔覀兪欠窨梢詫⑵涔_給你以及其他核心內(nèi)核用戶？”

Johannes Weiner 回應(yīng)說“vmap API 通常是公開的”，并且“新的 BPF 代碼需要 vmap_pages_range()的功能，以便將分別管理的頁面數(shù)組逐步映射到其 vmap 區(qū)域”。他接著指出，在其他外部使用該函數(shù)的代碼消失后，該函數(shù)從原來的公開改成了私有。Christoph Hellwig在對話的另一部分表示不滿：“我們需要保持 vmalloc 內(nèi)部細節(jié)只在內(nèi)部，并且不要在我們將其大致形成之后破壞這些抽象?！?br>

在審查 BPF 代碼的內(nèi)部更改時，Andrii Nakryiko對新的arenas如何計算其大小提出了關(guān)切?，F(xiàn)有的 BPF 映射記錄鍵的大小、值的大小和可以容納在映射中的總條目數(shù)。這對于哈希映射和數(shù)組映射效果很好，但對于新的 arenas 來說不太合適。Starovoitov 決定將 arenas 表示為具有 8 字節(jié)鍵和值大小的形式，“以便將來能夠擴展它并允許 map_lookup/update/delete 執(zhí)行一些有用的操作”。Nakryiko 斷言他們“應(yīng)該可能使 bpf_map_mmap_sz()意識到特定的 map 類型，并根據(jù)此進行不同的計算”，并指出 arenas 不太可能使用正常的 BPF 接口來進行 map 條目的查找。

Donald Hunter 質(zhì)疑為什么在代碼中將 arenas 表示為一種新的 map 類型，問是否“這是唯一可以重用內(nèi)核/用戶空間連接的方式？”Starovoitov 回答說，現(xiàn)有的 BPF 程序可用的許多映射都不支持某些映射操作。尤其是布隆過濾器（bloom filter）和環(huán)形緩沖區(qū)（兩種現(xiàn)有的映射類型，在某些方面與新的 arenas 相似）不支持查找、更新或刪除操作。他繼續(xù)說，arenas“可能是我們將添加的最后一種映射，因為幾乎任何算法都可以在 arena 中實現(xiàn)”。

Starovoitov 迅速吸收了這些反饋意見，并發(fā)布了補丁系列的第二版。然而，他沒有解決 Hellwig 對暴露虛擬內(nèi)存分配代碼底層細節(jié)的擔(dān)憂。Hellwig重申他的立場，稱：“vmap 區(qū)域不能隨意被調(diào)用者濫用”。Starovoitov回應(yīng)說，如果暴露 vmap_pages_range() 函數(shù)是無法接受的，Hellwig 應(yīng)該提出一個替代方案。Linus Torvalds 插話說，提出可接受的解決方案不是維護人員的責(zé)任；“需要提出新需求的人才需要尋找一個可接受的解決方案”。

對于這個版本的補丁系列的討論仍在進行中，但除了 Hellwig 關(guān)于暴露虛擬內(nèi)存分配代碼的底層細節(jié)的擔(dān)憂之外，其他大部分問題都相對較小，或已經(jīng)得到解決。在 BPF 程序和用戶空間代碼之間能夠無縫共享內(nèi)存是一個有吸引力的前景，因此很可能這項工作最終會完成實現(xiàn)，即便需要找到一種新的方式來按需為 BPF arena 分配頁面。

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

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