Linux 核心版 Hazard Pointer：從 Nginx 效能瓶頸走向 RCU 替代方案
Linux Kernel Mailing List · 2026-02-23（v5 修訂）
Linux 核心開發者社群正在評估將 hazard pointer 納入核心基礎設施，作為部分場景下 RCU 的替代方案。這項提案最早由 Boqun Feng 於 2024 年 9 月在 LKML 提出，經過多輪 RFC 修訂，Mathieu Desnoyers 在 2026 年 2 月送出第五版（RFC PATCH v5 0/2）。討論的起點，是一個具體到能說服 Linus Torvalds 的效能問題：Nginx 搭配 AppArmor 時的 refcount 競爭。
背景：一個真實的效能瓶頸
Neeraj Upadhyay 在討論串中指出，AppArmor 對 label 物件使用 kref 做參照計數，在多核心 worker process 情境下，這個計數器成為 Nginx 吞吐量的競爭熱點。切換成 hazard pointer 後量到約 7% 的吞吐量提升。Linus Torvalds 對此的回應相當直白：「We don't just merge random infrastructure without a use-case and an argument for it」，要求先拿出實際數據，而不是理論上的優點。
核心改動：hazard pointer 如何運作
Hazard pointer 提供一組 per-CPU 的 slot，存放在一個 domain 結構裡。呼叫端透過 hp_allocate() 或 hp_dereference_allocate() 取得 slot 並發布指標，搭配記憶體屏障確保安全解參照；用完後呼叫 hp_retire() 釋放。與 RCU 最大的差異在於不需要等待 grace period，回收端呼叫 hp_scan() 逐一確認沒有任何 CPU 還持有目標位址的參照，就能立即釋放物件。
ptr = hp_dereference_allocate(domain, slot, &obj);
/* ... 安全存取 obj ... */
hp_retire(domain, slot);這種設計也允許使用者自訂 retire callback，必要時可用 inter-processor interrupt 強制立即回收 slot，而不必被動等待掃描週期。
影響範圍
目前提案仍停留在 RFC 階段，尚未進入 mainline。除了 AppArmor 的 refcount 場景，討論串也點名了行程記憶體追蹤、無鎖判斷物件是否存在、即時互斥鎖（real-time mutex）的鎖等待順序等潛在應用。由於條件式參照取得（conditional ref acquisition）一度緩解了 AppArmor 的原始問題，hazard pointer 是否真正合併，仍取決於後續是否有更多場景能提供類似 Nginx 案例的具體效能數據。
原始來源：LKML: RFC PATCH 0/4 Add hazard pointers to kernel、LKML: RFC PATCH v2 3/4 hp: Implement Hazard Pointers
GNU Binutils 2.47 發布：RISC-V 擴充指令大量到位，32-bit s390 走向淘汰
GNU Binutils 官方公告（info-gnu mailing list） · 2026-07-26
GNU 專案於 2026-07-26 發布 Binutils 2.47，同步釋出於 ftp.gnu.org 與 sourceware.org 鏡像站。這個版本除了新增大量 RISC-V 向量擴充指令支援之外，也在組譯器、連結器與反組譯工具上加入多個實用選項，同時正式宣告淘汰 32-bit s390 目標。
核心改動：反組譯與連結器工具
AArch64 反組譯器新增 -M annotate 選項，能在遇到未定義指令時直接標示對應符號，方便除錯；x86/x86_64 則有對應的 -M annotate-immediates，在立即值旁標示符號名稱。組譯器新增 --reloc-section-sym=[all|internal|none]，控制指向 local binding symbol 的重定位是否要改用 section symbol。
- 連結器新支援
--start-lib/--end-lib與LIBlinker script 語法，可把一批目的檔當成人造 archive 處理 - 新增
--link-mapless，讓不含符號索引的 archive 也能在各格式下正常連結 objdump、readelf新增--debug-dir=<DIR>，指定尋找獨立除錯檔的路徑objdump新增--map-global-vars，列出物件檔中全域變數的位置與型別- 連結器新增
-O 0最佳化等級，跳過 mergeable section 合併以加快連結速度
規格細節：RISC-V 擴充與 s390 淘汰
RISC-V 這次一口氣加入多組向量運算擴充，包括 zalasr、svrsw60t59b、zvabd、smpmpmt 以及一系列 zvq/zvf 系列擴充，還有 SpacemiT 廠商專屬的 xsmtvdot、xsmtvdotii。這反映 RISC-V 生態系向量指令集仍在快速擴張，工具鏈需要持續跟進才能支援新矽片。相對地，32-bit s390 目標在本版被正式標記為 deprecated，64-bit s390x 則不受影響，持續維護。
影響範圍
對於維護跨架構建置系統的團隊，升級到 2.47 前需要檢查是否仍依賴 32-bit s390 工具鏈；RISC-V 相關產品則可望受惠於新擴充指令的組譯與反組譯支援。新增的 --debug-dir、--map-global-vars 等除錯選項，對日常追蹤 crash 與符號對應也有直接幫助。
原始來源：GNU info-gnu: Release 2.47 of the GNU Binutils is now available
gccrs 挑戰編譯 Linux 核心：2026 上半年進度回顧，Rust-for-Linux 里程碑衝上 25%
gccrs Monthly Report（rust-gcc.github.io） · 2026-04-13（2026 年 3 月報告）
gccrs——GCC 的 Rust 前端專案——在 2026 上半年把「編譯 Linux 核心」當成主要測試目標，持續用核心裡實際的 Rust crate 來驗證編譯器正確性。根據專案 2026 年 3 月的月報，Rust-for-Linux 里程碑完成度從 16% 推進到 25%，是近幾個月單月增幅最大的一次。
核心改動：一個一個 crate 啃下去
3 月報告顯示，compiler_builtins 與 builder_error 兩個 crate 本月完整編譯通過，ffi crate 則完成約 40%，「只剩少數幾個問題待解」。剩下的 RfL macros、RfL uapi 與核心主要檔案這三塊完成度仍是 0%，是接下來的主要戰場。專案也提到，name resolution 相關程式碼需要對多個 visitor 進行重構，而 mutex 這類核心型別要正確支援 Rust 的 Drop 語意，也還需要額外工作。
規格細節：三層里程碑架構
gccrs 團隊把長期目標重新拆成三層：「embedded Rust compiler」「Rust-for-Linux compiler」「general purpose compiler」三個里程碑各自獨立推進，而不是單押在一次性「編譯出完整核心」上。3 月月報也記錄了 13 位貢獻者參與，其中 Mohamed Ali、Egas Ribeiro、Ahmed Said、Philipp Gesang、Hritam Shrivastava、Enes Çevik 六位是新加入的貢獻者。
影響範圍
gccrs 團隊已確認「Compiling the Linux kernel with gccrs」這個講題獲 RustConf 2026 接受，顯示專案把這個目標視為年度重點對外展示。對 Rust for Linux 生態而言，多一套獨立於 rustc 的編譯器實作，長期有助於降低單一編譯器依賴的風險，但目前仍停留在「讓核心相關 crate 逐步編譯通過」的階段，距離產出可運作的完整核心映像還有一段距離。