問題發現、修復與同儕審查

A · 學術同儕審查

• IEEE WF-PST 2026 — Technical Program Reviewer 受 2026 IEEE World Forum on Public Safety Technology（IEEE 公共安全科技世界論壇）一位議程委員邀請，審查投稿論文；這個會議錄取的論文收錄於 IEEE Xplore。
• JOSS Peer Review — Metaxy（anam-org/metaxy） Journal of Open Source Software 指派我審查一份投稿：Metaxy（anam-org/metaxy），一套替 GPU 加速的機器學習管線管理逐筆特徵 metadata 的工具。JOSS 的審查分兩階段，先在 #10141 初審，再到 #10449 正式審查。我照 JOSS 的評審項目把意見整理成三則，直接開在 metaxy 自己的 repo 讓作者追蹤：論文寫法與 metadata（#1191）、宣稱的佐證與軟體設計（#1192）、參考文獻要附封存的 DOI（#1193）。

B · 自報自修並合併 — 端到端（共 127 筆 Found & Fixed）

• kubernetes/kubernetes — Issue #141434 四支 Ubuntu 的 DRA node e2e job 還沒建 VM 就被 OOM 砍掉，原因是挑映像時把整份映像清單讀進記憶體。這四支 job 的記憶體上限先被提到 2Gi 才跑得起來。我查到 ubuntu-os-gke-cloud 有 12,558 個映像，清單的 JSON 有 283 MiB，測試程式光是挑映像，記憶體峰值就到 1,067 MiB。#141590 讓 gcloud 先依映像家族篩選，峰值降到 103 MiB，選到的映像不變，8/27 合併；test-infra #37770 把上限改回 1Gi，9/11 合併。之後這四支 job 在 1Gi 下每次都通過，直到被換成新版 containerd 的 job，我 11/9 關閉。
• kubernetes-sigs/kueue — Issue #18283 這是我提的新功能：Kueue 的 Workload 建立延遲指標，加上 LocalQueue 層級的版本。原本的指標帶 LocalQueue 的自訂 label，卻沒有 LocalQueue 的鍵，KEP-7066 的逐一清理刪不到它的 series。#18295 新增 kueue_local_queue_workload_creation_latency_seconds，11/5 合併。
• nephio-project/oai — Issue #17 Nephio 的 OAI operator repo 附了三份無效的 CRD，套用到叢集會失敗。三份 manifest 的 group 與版本名稱都是空的。#16 讓這些內嵌在 OAI 設定裡的型別不再產生 CRD，9/13 合併。v6.0.0 發佈版裡還是這三份，要不要補修另外記在 #20。
• open-telemetry/opentelemetry-collector-contrib — Issue #50337 OpenTelemetry Collector 從 Prometheus remote write 收進 native histogram 時，float 型別沒有照規格丟掉，Count 也不是由桶子加總而來。相容性規格要求 float 與 gauge 型別的 native histogram 一律丟棄，receiver 只擋了 gauge；float 型別的桶子數量直接轉成 uint64，1.5 變成 1，NaN、+Inf 與 2e19 在 linux/amd64 上都變成 2 的 63 次方，一個壞掉的桶子到了下游就是約 9.2×10¹⁸ 筆觀測值。Count 則是照抄 Prometheus 的值，再扣掉被丟棄的溢位桶，不夠扣就歸零；規格要的是 ZeroCount 加上各桶的總和。#50343 丟棄 float 型別，Count 改由轉出來的桶子重算，表示不了的 custom bucket histogram 也改成丟棄並以 error 等級記錄。dashpole 10/14 approve 時找了 krajorama，10/19 又說這支改寫了 krajorama 在 #50292 審過的函式，要等他看過；krajorama 指出 count 為 0 時 sum 也要是 0，10/29 approve，當天由 songy23 合併。丟掉 float 型別也一併解決我回報的 #50331：多個 span 的 float NHCB histogram，每一段都從頭讀桶子的值。
• lima-vm/lima — Issue #5645 Lima 在 macOS 上設定自動啟動時，路徑或名稱裡只要有 & 或 <，寫出來的 launchd plist 就不是合法的 XML。limactl autostart enable 用範本產生 plist，只有 PATH 做了 XML 跳脫，LIMA_HOME、VM 名稱、limactl 的路徑、工作目錄與 daemon 的使用者名稱都原樣寫進去；例如 LIMA_HOME 放在 R&D 底下，plutil -lint 就不接受這份 plist。#5641 給範本加上 xml 函式，兩份範本的動態值都經過它跳脫；XML 1.0 表示不了的值（無效的 UTF-8、控制字元）改成產生 plist 時就報錯，不再寫出壞掉的檔案。AkihiroSuda 審查時要我先開 issue 附上重現步驟，並實際經 launchd 啟動 VM 驗證；jandubois 的審查指出擋掉無效 UTF-8 的檢查沒有測試涵蓋：拿掉它，路徑會被悄悄換成 U+FFFD，卻沒有測試失敗，我補上直接的測試。jandubois 10/29 給了 LGTM，AkihiroSuda 同日 approve 並合併。
• containernetworking/plugins — Issue #1292 CNI 的 host-local 位址分配，範圍起點設在 IPv4 的最大位址時會讓 plugin 當掉。例如子網路 255.255.255.252/30、起點與 gateway 都設成 255.255.255.255：沒有設的終點預設成 255.255.255.254，比起點還小，但檢查起點的時候終點還沒有值，這份設定照樣被接受。分配時跳過等於 gateway 的起點，往下一個位址走，進位後多出一個位元組，換算時算出負的長度而 panic。#1293 讓位址換算先定下位址族的長度，算出來超出位址族就回傳 nil，並在起點與終點都確定之後擋掉起點大於終點的設定。同一個換算函式另外兩個錯誤也一起修：IPv6 的結果剛好只有四個有效位元組時被當成 IPv4 傳回，減到位址族最小值以下時傳回錯的位址而不是 nil（0.0.0.0 減一得到 0.0.0.1）。squeed 10/14 approve，10/26 合併。
• kubernetes-sigs/prow — Issue #1021 Prow 的整合測試可能還沒開始就失敗，因為 gangway 寫死的 NodePort 32000 有時已經被別的 Service 拿走。ingress-nginx、hook、deck 等 Service 比 gangway 早建立，NodePort 由系統自動指派，而 Kubernetes 自動指派時先用範圍的上段，32000 就在上段。fakepubsub 的 port 也是在整個範圍裡隨機挑。#1013 的整合測試就這樣在跑任何測試之前失敗。#1022 把 gangway 改用留給固定 port 的下段（預設 30000 到 30085）裡的 30000，主機的 32000 改接到它，測試照舊連 32000；fakepubsub 也改從下段挑，避開 30000。Prucek 與 petr-muller approve 後，10/22 合併。
• kubernetes-sigs/prow — Issue #1020 Prow 的 GitHub proxy 合併重疊的請求時只看網址，要 PR diff 的呼叫可能拿到 PR 的 JSON。同一個 token 的 GET 進到 ghproxy，如果同網址的前一個請求還沒拿到 GitHub 的回應，就不另外送出，兩者共用那一份。GitHub 的 PR 資料、diff 與 patch 用的是同一個網址，只靠 Accept header 區分。cherrypicker 每則留言各用一個 goroutine 處理，同一支 PR 上的兩則 /cherrypick 就可能同時讀 PR 和它的 patch。我附的測試在 main 上 5 次都失敗。#1023 把 Accept header 的值加進合併的依據，並用三個 Accept 不同、在同一網址上重疊的請求來測。petr-muller approve 後在 10/22 合併。
• kubernetes/kubernetes — Issue #141435 Kubernetes 1.34 的 DRA 測試 job 常在跑完之前就逾時，原因是記憶體不夠。7 月新的 job 映像把 kind 節點也算進 pod 的 6 GiB 限制；1.34 與 1.35 分支上有一個測試會發布 100 個最大尺寸的 ResourceSlice，kube-apiserver 的記憶體因此升到約 1.8 GiB（10 個時約 0.6 GiB），1.34 的 scheduler 還會在 V(5) 把整份 ResourceSlice 清單逐節點寫進 log。8/3 到 9/11 的 40 次執行有 22 次被 OOM kill，其中 21 次先撞上 90 分鐘的逾時。master 早已把這個測試減到 10 個，也拿掉了那行 log；我把這兩處回移到 1.35 的兩支 PR，pohly 以不符合 cherry-pick 規範關掉，決定改提高 job 的上限：我在 test-infra#37865 把兩個分支的 DRA kind job 提到 12 GiB，pohly 與 saschagrunert approve 後在 9/14 合併。之後 ci-kind-dra-1-34 的定期執行每天都通過，每次約 8 到 9 分鐘，我在 10/21 關掉這則。
• lima-vm/lima — Issue #5646 Lima 可能把這次開機才寫下的 PID 檔，當成上次開機留下的刪掉。Lima 在 PID 檔旁邊放一個記錄開機識別碼的標記檔，發現標記屬於上次開機，就清掉整個目錄的 PID 檔。PID 檔本身是先寫暫存檔再 rename，標記檔卻用 os.WriteFile 原地截斷後重寫，同時讀標記的一方可能讀到空檔，誤判成上次開機。我讓四個 goroutine 寫、四個讀，識別碼始終不變，跑一秒就有大約一半的讀取被判成過期；要真的刪掉執行中 VM 的 PID 檔，還得有兩次寫 PID 檔的呼叫同時落在同一個目錄。#5642 加上 fsutil.WriteFileAtomic，標記檔改成跟 PID 檔一樣先寫暫存檔再 rename，兩邊共用這一段程式。AkihiroSuda 審查時要我把原子寫入移進 pkg/fsutil 共用，並改用 os.CreateTemp 拿掉重試迴圈，approve 後在 10/21 合併。
• kubernetes-sigs/kernel-module-management — Issue #1331 Kernel Module Management 刪除 Module 時，沒有東西讓 Module 留到 DRA 的清理跑完，DeviceClass 和節點標籤會留下來。Module 上唯一的 finalizer 只看 NMC 是否還在用它，跟 DRA 無關；沒有 moduleLoader 的 DRA Module 根本沒有 NMC，刪除一開始 finalizer 就被拿掉。Module 一消失，DRA reconciler 拿到 NotFound 就不會再被呼叫，負責清理的那段程式永遠不會執行。留下的 DeviceClass 是 cluster 範圍的物件，namespaced 的 Module 不能當它的 owner，沒有別的機制會清掉；同名的新 Module 還會找到已經貼好標籤的節點。原本的修正拆成幾支：先合併的 #1343 讓寫 finalizer 時帶上樂觀鎖，#1344 再給 DRA reconciler 自己的 finalizer，DaemonSet 和 DeviceClass 都刪乾淨、節點標籤拿掉之後才放開 Module。yevgeny-shnaidman 要我把流程改成和其他 reconciler 一致後給了 lgtm，10/19 合併。device plugin 有一樣的缺口，由 TomerNewman 的 #1367 補上，同一天合併後關閉這則 issue。
• openwrt/procd — Issue #54 OpenWrt 的 procd 在看門狗驅動拒收新的逾時值時，仍回報已經設好。procd 把要求的值直接記下來，沒有檢查 WDIOC_SETTIMEOUT 的回傳值；驅動拒收時保留舊值，ubus call system watchdog 和開機訊息卻都顯示新值。我在 mt7620 的板子上碰到：rt2880_wdt 最多只接受 107 秒，procd 說是 120 秒，實際重開機的時間要等我改成 107 秒才跟著變。#55 在設定失敗時記下錯誤，並用 WDIOC_GETTIMEOUT 讀回驅動實際的值（20192e4 之前，procd 也會讀回）；我用 softdog 試過超出上限的值，procd 現在回報的是驅動保留的舊值。dangowrt 合併。
• kubernetes-sigs/kueue — Issue #14437 Kueue 的 TAS 在准入前做的最後檢查，比當初產生分配的那一步寬鬆，放不下的 Workload 也能過關。這個檢查不算 Pod slot：節點已經沒有 slot，它仍然回報有空間，只限制 Pod 數量的 ClusterQueue 反而永遠准入不了不請求任何資源的 PodSet。同一個 Workload 有兩個 PodSet 落在同一個網域時，它又把每個 PodSet 都拿去和完整的剩餘容量比，好像另一個不存在。#14443 讓檢查替每個 Pod 加上一個 slot，並在看下一個 PodSet 之前先扣掉前一個用掉的量。pajakd 審查時把整個函式重寫一遍給我，我原樣套用、測試照樣通過；mimowo 核准後 10/16 合併，我做的 0.19 回移 #17335 也在同一天合併。
• open-telemetry/opentelemetry-collector-contrib — Issue #50546 OpenTelemetry Collector 的 Prometheus Remote Write receiver，會把一個 exemplar 分給所有共用同一個 metric 名稱的 target 與 scope。它替 exemplar 建 key 時用的是轉換後的屬性，而轉換已經拿掉 job、instance 和 otel_scope_ 開頭的 label，所以兩個只差在 job 的 target 共用一把 key，一個送來的 exemplar 兩邊都拿到。#50341 改用整組原始 label 當 key，也就是 Prometheus 認定一個 series 的方式；同一支 PR 也修好我回報的 #50334 裡 histogram 的部分：帶一般 label 的 histogram 找不到自己的 exemplar。審查一度暫停，等 Prometheus 把只帶 exemplar 的 TimeSeries 寫進規格。我送的 prometheus/docs #3085 合併當天，ArthurSens 就核准，條件是原始碼註解的 prometheus #19530 也要合併；那支 10/2 合併，dashpole 10/13 核准後，這支隨後合併。
• openwrt/openwrt — Issue #25742 OpenWrt ramips 平台的乙太網路驅動，沒看核心的回覆就把中斷打開。收完一輪封包，驅動會呼叫 napi_complete_done()；它回傳 false，代表中斷要繼續關著，例如啟用了中斷延後、核心已經排好計時器要再輪詢一次。核心文件要求驅動看過回傳值再開中斷，主線的 mtk_eth_soc 也是這樣做，這個 mt7620、mt76x8 等五個平台共用的驅動卻沒有。#25744 改成回傳 true 才開中斷，mcprat 看過後由 jonasjelonek 合併。上游合併之前，以 OpenWrt 為基礎的韌體 X-WRT 已經先把它帶進 master；10/16 我送的 25.12 回移 #25853 也由 jonasjelonek 合併。這支只做過編譯測試；回報時，我的 MT7620A 板子在開啟中斷延後約 34 秒後重開機，只發生過一次，也沒有留下記錄，所以不能說這個修正擋得住它。
• zephyrproject-rtos/zephyr — Issue #119675 Zephyr 的 GPIO 模擬驅動讀取指定腳位的輸出時，忽略了遮罩，回傳的是整個 port 的值。函式先檢查遮罩合不合法，之後卻沒有套用。樹內唯一的呼叫端會自己再套一次，所以目前沒有東西讀錯；但測試一次讀回幾支腳位時，會連同一個控制器上其他的輸出一起讀到。#119679 補上遮罩並加了回歸測試，已合併。
• kubernetes-sigs/kernel-module-management — Issue #1328 Kernel Module Management 卸載核心模組時，靠這個模組運作的 DRA driver Pod 還留在已經 cordon 的節點上，兩邊互等。DaemonSet 的 Pod 會自動容忍 cordon，drain 也不會趕走它，只有 nodeSelector 不再符合時才會離開。device plugin 先前已經用一個專用的節點標籤解決同樣的問題，DRA 沒有：它的 Pod 只看模組就緒的標籤，這個標籤要等卸載成功才拿掉，卸載卻要等 driver 放掉模組才會成功。會不會卡住，要看兩個 controller 誰先處理同一次節點變更，這可能是它一直沒被發現的原因。我原本的 #1329 太大，維護者 TomerNewman 建議拆小並提出拆法。照這個拆法，先拆出 #1351，讓 DRA driver 也改看一個專用標籤，9/29 合併；#1329 縮成只在節點 cordon 或帶著不容忍的 taint 時拿掉這個標籤，10/4 合併。
• k8snetworkplumbingwg/dra-driver-sriov — Issue #175 dra-driver-sriov 把 container-device-interface 升到 v1.1.1 之後，開 race 偵測跑測試必定報競爭。競爭的兩端都在相依套件裡：新版拿掉了建立 cache 時的鎖，卻留著會同時刷新的監看器。鎖補回上游的部分是 container-device-interface 的 #365，修的是我回報的 #364；這個 driver 只用 cache 寫入與刪除設定檔、從不讀回，所以 #178 直接關掉用不到的自動刷新，SchSeba 審過後合併。
• cncf-tags/container-device-interface — Issue #364 container-device-interface 建立 cache 時，和它自己啟動的目錄監看器同時寫同一份資料。其他會刷新 cache 的路徑都先上鎖，只有建構的時候沒有，這是 v1.1.1 起才有的問題。我從 dra-driver-sriov 的 #175 一路追到這裡，#365 把鎖加回去。審查時 thaJeztah 直說競態是真的、實際影響大概不大，請我把測試改成只看對外的結果；bart0sh 再給了一個不靠時機、每次都抓得到競態的測試寫法，我採用了。
• kubernetes/kubernetes — Issue #141212 ResourceSlice 裡單一裝置的節點條件寫了好幾組時，會通過驗證，排程時卻讓整輪排程中止。API 規定每個裝置只能有一組條件，ResourceSlice 整體的節點條件有檢查，單一裝置的卻沒有。allocator 遇到這種裝置時回傳一般錯誤，scheduler 於是放棄搜尋其他節點；壞掉的 ResourceSlice 沒修好之前，每次重試都一樣。#141213 讓 API 在建立或修改時就拒絕有好幾組條件的裝置，和 ResourceSlice 整體的檢查一致。
• submariner-io/submariner-operator — Issue #4272 Submariner 更新 CoreDNS 設定時，可能把設定檔後半段整段刪掉。它在 Corefile 裡管理自己的一段，更新前先刪掉舊的那段；刪除的程式只要看到某一行提到開始標記，就一路刪到檔尾，所以一句碰巧寫到這個標記的註解，就足以讓後面的 DNS 設定消失。修正（#4273）要求標記單獨成一行才算數，前後對不起來時寧可不動檔案。
• kubernetes-sigs/kueue — Issue #13599 這是我提的新功能：讓 Kueue 接受 DRA 的 firstAvailable 請求。Kueue 原本直接拒絕這種請求，因為保留配額的時候，還不知道 scheduler 最後會選中哪一個備選。設計在 KEP-2941 的 #13601 討論了兩個月才定案：Alpha 階段只接受各個備選指向同一種資源、數量也相同的情況，配額只算一次。實作在 #14130。
• kubernetes/kubernetes — Issue #141635 Kubernetes 節點 e2e 測試在 GCE 上開機器時，就緒檢查可能在機器還沒就緒時照樣結束，也不回報錯誤。輪詢迴圈裡重新宣告了同名變數，「VM 沒進入執行狀態」與「runtime 服務不在」兩種錯誤都被丟掉，迴圈結束後檢查的是外層那個從沒被寫入的變數。修正在 #141639；審查中 harche 指出逾時只會結束直接的子行程，我據此改了逾時的處理，並把 harche 提出的情境寫成測試。
• zephyrproject-rtos/zephyr — Issue #115904 Zephyr 的 MIPI DBI 測試以為自己在測多個裝置，實際上只建了一個。測試設定裡的 MULTIPLE_INSTANCES=1 只是 CMake 變數，從沒傳到編譯器，那個情境於是只建一顆裝置，還帶著硬體撐不起的 9 與 16 bit 模式。照 JarmouniA 在 issue 上的建議，我把它改成測試用的 Kconfig 選項（#120476）；手上沒有 Pico 板，只做了建置驗證。
• cert-manager/cert-manager — Issue #9126 cert-manager 的憑證請求若標了失敗時間、卻沒有 Ready 狀態，發證會無聲地卡住。後續流程都要求先有 Ready 狀態，這種請求既不算失敗、不會退避重試，也不會被新的請求取代。wallrj 在審 #9118 時注意到，請我另開 issue。pujitha24 的 #9128（作者帳號已經不在，連結指向合併的 commit）先讓卡住的狀態看得見，但卡住本身還在，issue 因此重新打開；#9287 讓這種請求比照失敗處理，才真正解開。
• zephyrproject-rtos/zephyr — Issue #115251 Zephyr 的 MIPI DBI 驅動可能以為裝置有 GPIO 片選，拿到的卻是空的腳位設定。判斷有沒有 GPIO 片選看的是整個控制器，取腳位時卻照裝置自己的編號去找，編號超出範圍的裝置兩邊就對不上；先前兩次修正各只改到其中一半。#115254 把兩半修齊，並附上測試。
• zephyrproject-rtos/zephyr — Issue #115726 ESP32 的 DMA 停止後再啟動，會先送出上一筆傳輸的完成通知。停止時沒有清掉硬體記下的中斷狀態，重新啟動後硬體看到舊的位元，資料還沒到就先觸發一次回呼。#113311 讓停止前先重設 channel、清掉中斷狀態。
• Gthulhu/Gthulhu — Issue #150 把 Gthulhu 排程器一個檔案裡的四個小毛病，整理成給新手的 issue。例如組 /proc 路徑時多了一條斜線，今天只是靠 Linux 容忍雙斜線才沒出事；另外還有一個自訂函式蓋掉了 Go 的內建函式、一個錯誤讀了就丟、一個欄位寫了卻沒人讀。每一則都附驗收條件，不需要 eBPF 背景。最後我在 #149 順手整理掉了。
• open-telemetry/opentelemetry-cpp — Issue #4396 OpenTelemetry C++ 的 HTTP client 在回應的處理函式裡再送一次請求，會釋放掉仍在執行中的物件。同一個 session 送新請求時會換掉舊的操作物件，而回應的 callback 正是從那個物件裡呼叫出來的，回程還要再讀它一次；ASan 報 use-after-free。修正（#4431）規定一個 session 只送一個請求，第二次直接回報失敗。
• k8snetworkplumbingwg/dra-driver-sriov — Issue #170 SR-IOV 的 DRA driver 在一個 pod 有兩個 claim 時，第二個 claim 的資源永遠不會被釋放。kubelet 一次釋放一個 claim，driver 卻在處理第一個時就把整個 pod 的紀錄刪掉，第二個找不到紀錄就直接回報成功：VF 沒有還原，CDI 設定檔也留在節點上。我在虛擬叢集裡重現後，於 #169 改成只刪該 claim 的紀錄，寫入 checkpoint 失敗時也會把記憶體內的變更退回。
• zephyrproject-rtos/zephyr — Issue #114741 Zephyr 的 MIPI DBI api 測試在所有平台上都被跳過，因為篩選條件把裝置名稱拼錯了。篩選寫的是 mipi-dbi，devicetree 的名稱卻不能有連字號、實際是 mipi_dbi，連真的有這個裝置的板子也被濾掉。#115831 改正拼法，也讓這組測試能在模擬器上跑，收進 v4.5.0。
• zephyrproject-rtos/zephyr — Issue #119678 Raspberry Pi Pico 的 DMA 驅動裡，一個 channel 出錯，同一次中斷裡後面每個成功的 channel 也會收到錯誤。中斷處理程式把錯誤變數放在走訪 channel 的迴圈外面，沒出錯的路徑也不歸零。MIPI DBI 驅動一個裝置最多會用到四個 channel，這種情況實際碰得到。修正只改兩行（#119681）。
• zephyrproject-rtos/zephyr — Issue #119677 Pico 的 MIPI DBI 驅動會把 DMA 錯誤當成成功。出錯時它把 channel 號碼放進結果佇列，等待的一方卻把佇列裡的值當成傳輸結果：channel 0 的錯誤讀成 0，也就是成功；其他 channel 則回傳一個呼叫端預期不到的正數。channel 號碼由小到大分配，最常拿到的正好是 0。修正在 #119680。
• zephyrproject-rtos/zephyr — Issue #119676 Pico 的 MIPI DBI 驅動從沒初始化過它的鎖。沒有人搶鎖的時候碰巧能用，第一個真的要排隊等鎖的執行緒就會對空指標寫入。另一個 MIPI DBI 驅動先前修過同樣的遺漏。修正當天送出，和 #119677 同在 #119680，並標記回移到 v4.4 分支。
• kubernetes-sigs/kueue — Issue #14004 Kueue 處理 DRA 對應的 extended resource 時，會把同一資源上其他來源的用量一起刪掉。它把整個資源項刪掉、再用容器的請求重建，於是 pod 的額外開銷與其他轉換算出的用量一併消失；重建的數字本身也可能算錯，因為 sidecar 容器在兩處的算法不一致。#14154 改成只減掉容器自己的請求、sidecar 一律加總；release note 標為使用者需要留意的變更，也回移到 0.19 與 0.18。
• AcademySoftwareFoundation/rawtoaces — Issue #326 rawtoaces 在 Docker 預設的安全設定下，每次呼叫 exiftool 都被判成失敗。程式啟動子行程之後看系統錯誤碼決定成敗，但這個錯誤碼只在啟動失敗時才有意義；Docker 擋掉一個較新的系統呼叫，glibc 改用舊的照樣成功，錯誤碼卻留了下來，相關測試在 Docker 裡全紅。我附上三行 C 的重現，在 #328 改看實際的回傳值與結束狀態。soswow 審查時抓到被中斷後重試會丟掉半行輸出，讀取迴圈因此重寫。
• zephyrproject-rtos/zephyr — Issue #116336 ESP32-P4 的 AXI DMA channel 沒有等硬體確認就被重設，停止也沒有真的確認已停下。停止函式送出停止訊號就回報成功，其他重設路徑也跳過硬體要求的中止握手；而呼叫端是以停止成功為依據收回緩衝區的。我原以為沒有程式用到這種 channel，後來在測試裡找到一個，回報時自己更正。#113311 讓三處重設都改走同一個會做握手的函式。
• kubernetes-sigs/dra-driver-cpu — Issue #231 dra-driver-cpu 的 Helm chart 寫死了 kubelet 的目錄，kubelet 一換位置，driver 就永遠註冊不上。kubelet 只在自己的目錄下找 plugin，driver 卻把註冊用的 socket 建在寫死的路徑，DaemonSet 一直重啟。修正一開始就備好了，但維護者要我等另一支改同一套設定的 PR 先合併，之後拆成三支：前兩支加上目錄參數與 chart 設定，最後一支 #282 補上輸入檢查與 CI 測試。
• volcano-sh/volcano — Issue #5627 Volcano 的 scheduler 會被一個 Pod 卡死：在 DRA 請求裡填一個極大的裝置數量就夠了。容量是用迴圈一次加一個算出來的，次數直接取自使用者填的數量，API 只擋零與負數，一個巨大的數字就讓 scheduler 永遠算不完。我回報後也私下通報 Volcano 的安全團隊；有人先認領修正但沒能解決，JesseStutler 請我接回。修正在私有的 advisory 分支裡完成（改成一次乘法算完），再以 #5869 帶回 release-1.15。安全公告 GHSA-j38h-7pfq-cxmw 已發佈，我具名為發現者，修正隨 v1.15.2 出貨。
• kubernetes-sigs/kueue — Issue #14105 Kueue 的配額用量一旦加到上限值，就和「不限量」分不開，之後的帳會一路算錯，直到重啟。Kueue 用整數的最大值代表不限量，用量的乘法與加法卻在溢位時停在這個最大值，正好撞上這個特殊值：之後加進來的不算，離開的照減，帳面漂成負數。我先試的簡單修法只擋得住碰撞、擋不住漂移，就自己關掉了；mimowo 提議內部改用任意精度的整數，#15026 照這個方向讓數字放不下時自動轉換。mimowo 認為這修的是 workload 建立者能挾持配額的漏洞；回移在 #15653、#15654。
• k8snetworkplumbingwg/dra-driver-sriov — Issue #136 多個 DRA driver 共用一個 claim 時，SR-IOV driver 的重試會無聲地蓋掉別的 driver 寫入的狀態。claim 的裝置狀態清單由所有參與的 driver 共用，寫入衝突時最可能的對手正是另一個 driver；重試卻先存下整份舊清單，重新讀取後再整份寫回，對方的資料就被舊版覆蓋，而且重試成功、沒有人會發現。#137 改成在最新的 claim 上只重建自己的那幾筆。這是跨廠商 DRA driver 稽核裡「多 driver claim」那一類的問題之一。
• k8snetworkplumbingwg/dra-driver-sriov — Issue #138 SR-IOV driver 重試時只用名稱找回 claim，claim 若被刪掉再以同名重建，狀態會寫到另一個物件上。兩處重試都沒有核對 claim 的 UID。這是修狀態覆寫問題時發現的，同在 #137 修好。
• ocudu/ocudu — Issue #726（GitLab） 對端只要在 fronthaul 封包裡宣告一種這個版本沒實作的壓縮格式，OCUDU 的整個 gNB 行程就會結束。有五種壓縮格式的解碼器只會回報錯誤、然後讓行程退出，而動態解碼器的格式是從線上封包讀來的，一個畸形的上行封包就夠了。這是我對 U-plane 解碼做 fuzz 時找到的。第一版修正在解碼器內加守衛；AleaLC 在討論中提出另一種做法，faluco 同意，我把 !1296 整個改寫：解壓縮會回報有沒有產出樣本，解不出來的訊息直接丟掉。
• AcademySoftwareFoundation/rawtoaces — Issue #325 rawtoaces 處理 DNG 檔時回報的色溫算錯了，因為內插的方向寫反。它在兩個校準光源之間搜尋，誤差變號時在相鄰兩點間內插，式子裡的減號寫成了加號；測試素材上它回報 5317K，真正的解在 5566K。#327 改正方向，連同另外兩處讓搜尋停錯位置的問題一起修好，並比照 DNG SDK 只在需要時才搜尋，免得原本靠錯誤互相抵銷才算對的檔案在修正後反而出錯。
• AcademySoftwareFoundation/rawtoaces — Issue #329 rawtoaces 把檔名不加引號交給 shell 執行 exiftool：含空白的檔名讀不到任何 metadata，特殊檔名甚至能執行指令。檔名被空白拆開後 exiftool 回報找不到檔案，但輸出不是空的，程式就當成成功；名為 a;id;.NEF 的檔案則會執行 id。#330 為兩個路徑都加上引號，並避免檔名被當成選項。
• kubernetes/kubernetes — Issue #141323 Kubernetes 的 DRA 配置器加總裝置數量時會溢位，讓超過上限的請求通過檢查。每個 claim 的裝置數上限檢查用原生整數加總，越過整數邊界就變成負數。修正在 #141307；pohly 為了回移到 1.34 至 1.37 重新打開 issue，四支回移（#141925、#141924、#141923、#141922）都進去之後才關閉。
• kubernetes/kubernetes — Issue #141617 PVC 指定 PV 時，Kubernetes 比較容量的方式會溢位：超大容量的 PV 被判成太小，極端值下反方向還會讓不夠大的 PV 通過。比較前先把容量轉成 64 位元整數，超過範圍的值會繞成負數；自動配對的那條路早就用了正確的比較方式。#141618 讓這條路也用同一種比較。
• nephio-project/nephio — Issue #1171 Nephio 的 FOCOM 自己設定認證標頭，讓 Kubernetes client 的 exec 認證與 token 輪替都失效。它在建構時讀一次 token、手動寫進標頭，而 client-go 看到標頭已存在就不再注入憑證：exec 型的 kubeconfig 永遠不會執行它的 plugin，service account token 被輪替後，operator 仍送出啟動時那一份，從 Porch 收到 401，直到重啟。#1181 把憑證交回 client-go 處理。
• open-telemetry/opentelemetry-cpp — Issue #4425 OpenTelemetry C++ 的 OTLP HTTP exporter 遇到三種結束狀態時，永遠不會判定請求已完成。處理事件的 switch 漏了這三種，請求不會收尾、結果 callback 不執行、連線不釋放，ForceFlush 與 Shutdown 只能等到逾時。補上這三種狀態的修正在 #4453。
• kubernetes-sigs/kueue — Issue #14398 Kueue 開啟 ClusterQueue 自訂指標標籤後，第一次移除 scheduling gate 就會讓 controller 當掉。這個指標註冊時帶了自訂標籤，記錄時卻只傳三個固定標籤的值，數量不合就 panic，整個 manager 跟著倒。#14419 讓記錄時一併帶上自訂標籤。
• publiccodeyml/publiccode.yml — Issue #363 publiccode.yml 的舊文件網址轉址時丟掉了搜尋字串，從舊連結進來的人只看到空白的搜尋頁。轉址只保留網址的 # 片段，沒有帶上搜尋參數，新的搜尋頁讀不到關鍵字就不搜尋。一行的修正（#364），回報當天就進去了。
• kubernetes-sigs/kernel-module-management — Issue #1346 Kernel Module Management 在兩個 namespace 有同名 Module 時，節點上的就緒標籤會拿不掉。摘標籤前它會先找有沒有替補的 Pod，免得滾動更新時標籤閃爍，但這個查找沒有限定 namespace，把另一個 namespace 的同名 Module 當成了替補。#1347 把查找限定在同一個 namespace。
• cncf/prow-github-actions — Issue #102 CNCF 的 prow-github-actions 可能在 GitHub API 呼叫完成前就結束，留言、加標籤這些動作根本沒送出。指令的處理函式沒有等待自己發出的非同步請求，#103 讓它們都等到完成。
• cncf/prow-github-actions — Issue #105 prow-github-actions 移除標籤失敗時不報錯，維護者會以為指令生效了。#106 讓真正的 API 錯誤使 action 失敗。
• kubernetes/kubernetes — Issue #140797 Kubernetes 的 DRA 配置器可能把一個仍被共享使用的裝置，再獨佔地配給另一個請求。它檢查裝置是否在用時，只看獨佔的配置與正在進行中的配置，漏了已經存下的共享配置；裝置關閉共享之後，同一個裝置就可能同時掛著共享與獨佔兩份配置。修正在 #140798。
• kubernetes-sigs/dra-driver-cpu — Issue #308 這是我提的小改進：讓 dra-driver-cpu 的 Helm chart 拒絕打錯的頂層設定。values 的 schema 每一層都會拒絕未知的鍵，只有最上層沒有，打錯的頂層設定會被默默忽略、chart 照預設值產生；例如把 kubelet 目錄的設定拼錯，操作者以為設好了，實際用的卻是預設路徑。這是我審自己的 #282 時發現的，當天送出 #309。
• microsoft/retina — Issue #2678 Microsoft 的 Retina 遇到 ICMP、SCTP 這類沒有 port 的流量，整個指標模組就會 panic。處理 port 指標時沒先確認流量有沒有 port。#2679 對這類流量送出一個固定的 port 值，也讓標籤組合保持一致。Retina 是 Microsoft 的 eBPF Kubernetes 網路可觀測性工具。
• Gthulhu/Gthulhu — Issue #132 Gthulhu 的節點排程政策只套用到行程的主執行緒，多執行緒程式的其他執行緒完全沒被管到。Linux 排程的單位是執行緒，政策卻只掃描行程。修正跨兩個 repo：Gthulhu #135 改成掃描每個執行緒，plugin #17 讓策略以執行緒為單位套用。
• kubernetes-sigs/kueue — Issue #13988 Kueue 接受一個名為 pods 的資源對應設定，然後默默用 PodSet 的數量蓋掉它。設定通過驗證、看起來生效，配額實際記到的卻不是使用者宣告的東西。#13989 在驗證時直接拒絕這個保留名稱，並回移到 release-0.18（#14758）。
• kubernetes-sigs/kueue — Issue #14744 Kueue 的一組整合測試改寬了共用的指標結構卻沒有還原，之後的測試一跑就 panic。加一行、在測試結束時重設就解決了（#14745）。
• zephyrproject-rtos/zephyr — Issue #113333 Zephyr 的 I2S API 文件說緩衝區用完時會回傳錯誤，i2s_buf_write() 實際上卻一直等下去。它取記憶體區塊時固定用 K_FOREVER，多執行緒的建置下，文件列出的 -ENOMEM 與 -EAGAIN 都不會出現。#115727 改用設定裡的逾時，並補上兩個測試。
• kubernetes-sigs/cluster-autoscaler — Issue #31 啟用 DRA 時，只要有一個 Pod 參照了未被追蹤的 ResourceClaim，cluster-autoscaler 移除節點時就會 panic，整個 autoscaler 停擺。它跳過找不到的 claim 時在清單裡留下空位，之後逐一處理就對空指標取值。#32 改成只收實際找到的 claim。
• prometheus/prometheus — Issue #19432 Prometheus 的 promtool 從規則檔建立資料區塊時，遇到含多份 YAML 文件的檔案就會當掉。它只是想印一句「只處理第一份文件」的警告，卻在 logger 還沒設定好時就呼叫它。#19433 補上預設的 logger。
• kubernetes-sigs/kueue — Issue #14045 Kueue 把兩個各自放得進 64 位元整數的資源請求相加，結果會繞成負數，被當成什麼都沒要。乘法已經會在溢位時停在上限，加減法還沒有。我先開 issue 說明：會計加總適合停在上限，admission 的檢查則應該回報欄位錯誤，兩處要的答案不同。之後 #14100 讓加減法也停在上限，同日回移到 0.19 與 0.18（#14108、#14109）。
• kubernetes-sigs/kueue — Issue #14399 沒有設定 priority 的待排 Workload，會讓 Kueue 的 visibility API panic。priority 是可以合法為空的欄位，程式卻直接取值；#14411 先檢查再取。
• zephyrproject-rtos/zephyr — Issue #115720 ESP32 的 DMA 驅動會把長度為 0 的區塊交給硬體處理。設定 descriptor 時沒有檢查區塊大小，#115723 改成拒收零長度的區塊。
• zephyrproject-rtos/zephyr — Issue #115504 ESP32 的 I2S 驅動在傳送啟動失敗時，會弄丟已經取出的記憶體區塊，失敗幾次之後就沒有區塊可用。DMA 啟動失敗時直接返回，沒有把區塊還回記憶體池；#115523 在失敗路徑歸還。
• zephyrproject-rtos/zephyr — Issue #115719 ESP32 的 I2S 驅動收到不支援方向的觸發指令時，會對空指標取值而當掉。#115721 先擋下不支援的方向、回傳錯誤。Zephyr 的安全團隊之後以 GHSA-5g9q-h8wq-rrf3 發佈公告、指派 CVE-2026-19737，公告列我為修正開發者。
• zephyrproject-rtos/zephyr — Issue #115505 ESP32 的 I2S 驅動停止串流後沒有取消已排程的計時器，計時器之後觸發時會打到已停止的串流或下一段串流。#115725 在停止時一併取消。
• ocudu/ocudu — Issue #643 (GitLab) OCUDU 更新 NTN 衛星參數時，延後執行的工作會讀到已經釋放的記憶體。訊息建在堆疊上，交給延後工作的只是不持有資料的參考，處理函式一返回，兩者都已失效。!1153 讓請求自己持有資料、一路以值傳遞，用 ASan 與 mutation testing 驗證過。
• kubernetes-sigs/kueue — Issue #13902 Kueue 的 LeaderWorkerSet 與 StatefulSet reconciler 裡，一個操作失敗就會把其他互不相干的操作一起取消。這些操作共用同一個 context，任何一個失敗都會取消它。#13921 讓失敗不再牽連其他操作。
• zephyrproject-rtos/zephyr — Issue #115502 ESP32 的 DMA 驅動檢查 descriptor 是否用完時，會讀到陣列尾端後一格，重新載入時還會往那裡寫。#115507 修好這個越界存取，也一併修了 #115503 的重複停止。
• zephyrproject-rtos/zephyr — Issue #115503 ESP32 的 DMA 驅動停止記憶體對記憶體的傳輸時少了一個 break，同一個方向會被停兩次。和 #115502 的越界存取同在 #115507 修好。
• open-telemetry/opentelemetry-cpp — Issue #4375 OpenTelemetry C++ 的 HTTP client 取消請求時，取消的執行緒和 IO 執行緒會同時操作同一個 curl handle。這是資料競爭。#4392 改成透過事件通道通知 IO 執行緒自己取消。
• kubernetes-sigs/kueue — Issue #14012 Kueue 的 Workload 驗證 webhook 會因為一個缺資料的狀態而當掉。webhook 看到 Workload 標了「已保留配額」就去讀配額的分配內容，但這個狀態可以在還沒有分配內容時就被設上，讀到空值於是 panic。修正改成不憑這個狀態就去讀分配內容（#14014）。
• open-telemetry/opentelemetry-cpp — Issue #4389 OpenTelemetry C++ 的 HTTP client 從 curl 錯誤中復原時，會把自己鎖死。復原的函式全程拿著一把鎖，中途又呼叫一個會再拿同一把鎖的函式，同一條執行緒就卡在自己身上。修正把鎖的範圍縮到真正需要的那一段（#4394）。
• RocketPy-Team/RocketPy — Issue #1042 RocketPy 模擬感測器雜訊時沒辦法設定亂數種子，結果無法重現。感測器的雜訊與漂移、GNSS 接收器的精度，都從整個程式共用的亂數產生器抽樣，給了種子也沒有用。現在每個感測器可以各自設定種子（#1052）。
• open-telemetry/opentelemetry-cpp — Issue #4398 OpenTelemetry C++ 的 HTTP 重試，多條執行緒會同時改動同一個亂數產生器。重試前的隨機等待時間都從同一個共用的產生器抽樣，同時重試就是資料競爭，ThreadSanitizer 也確認了。#4399 改成每條執行緒各用一個產生器。
• kubernetes-sigs/dra-driver-cpu — Issue #254 DRA CPU driver 註冊逾時的時候，看不到 kubelet 拒絕它的原因。driver 等待註冊時只看成功了沒有，kubelet 一直回報拒絕，呼叫端最後只拿到一個逾時，很難排查。現在逾時的錯誤會帶上 kubelet 給的拒絕原因（#291）。
• kubernetes-sigs/kueue — Issue #14043 Kueue 可能把 DRA 的配額記到 scheduler 不會配給的那個裝置類別上。好幾個 DeviceClass 宣告同一個擴充資源名稱時，Kueue 取清單裡第一個符合的類別，和 scheduler 實際會配的那個不一定相同。#14044 改成照 scheduler 實際會配的類別計費。
• kubernetes-sigs/kueue — Issue #13998 Kueue 的資源換算結果太大時，請求量會繞成負數，最後被當成 0。換算後只有 CPU 會檢查是否超出 64 位元整數，其他資源超出的部分被靜默截掉。#14042 讓每一種資源都有上限保護，release-0.18 的回移是 #14113。
• kubernetes-sigs/kueue — Issue #13985 Kueue 用負係數寫的「每單位額度」，會被算到不該碰的資源上。資源換算可以用負係數表示每單位可抵扣的額度，計費應該只算超出額度的部分，但這個額度會外溢到其他資源。修正把換算產生的量和 PodSet 原本請求的量分開記（#13986，release-0.18 回移 #14033）。
• kubernetes-sigs/kueue — Issue #13992 Kueue 保留原始請求量時，留下來的卻是乘過倍數的值，配額被灌大。換算規則同時設了「保留原請求」與「乘上倍數」時，程式先把請求量改成乘積，再把這個乘過的值當成原請求留下來。#13986 把這個也一起修掉。
• kubernetes-sigs/kueue — Issue #13990 Kueue 換算的產出和請求的資源同名時，配額可能被保留，也可能被丟掉，要看迭代順序。換算產出用累加的方式寫入，保留下來的原請求卻用覆寫的方式寫回，兩者同名時誰留下來就看 map 怎麼排。這也在 #13986 的重構裡一併修好。
• RocketPy-Team/RocketPy — Issue #1101 從 fork 送來的 PR，RocketPy 的 changelog 檢查每次都會失敗。GitHub 不把 secrets 交給 fork 來的 PR，這個 job 因此一律失敗；#1112 讓它在 fork 來的 PR 上也能執行。
• RocketPy-Team/RocketPy — Issue #1096 RocketPy 文件教的重設亂數種子做法，實際上沒有作用。CustomSampler 的文件示範了一個無效的 reset_seed 用法。#1097 把文件改成有效的做法。修正已合併在 develop 分支，維護者 11/2 把 issue 重新開啟，等 v1.14.0 發佈到 master 才關。
• RocketPy-Team/RocketPy — Issue #1078 RocketPy 匯出飛行動畫 GIF 的測試會偶發崩潰，讓 CI 的結果不可信。修正在 #1100，搭配 #1098。
• RocketPy-Team/RocketPy — Issue #1093 RocketPy 隨機模型裡的每個取樣器都用同一個種子重設，兩個參數其實綁在一起變動。兩個設定不同的高斯分布會抽出逐位元相同的值，掃兩個參數等於只掃一個，算出來的相關性只是種子造成的假象。現在每個取樣器依模型種子和輸入名稱，各自衍生一條獨立的亂數流。#1102 在 GitHub 上顯示 closed，因為整條分支是從合併按鈕以外的路徑併進 develop 的，落地的 commit 可以查（6d66bde5）。
• RocketPy-Team/RocketPy — Issue #1094 RocketPy 抽樣出來的降落傘尺寸，從來沒有用到實際模擬的火箭上。降落傘物件依抽樣結果建好之後，建立火箭時又被丟掉，只取其中幾個欄位重建，抽到的幾何設定就這樣消失了。修正見 #1098。
• RocketPy-Team/RocketPy — Issue #1095 RocketPy 的隨機降落傘，會拒收說明文件上說可以傳的函式型觸發條件。文件寫觸發條件可以是函式，驗證程式卻只接受數值和字串；#1103 修掉了這個落差。
• RocketPy-Team/RocketPy — Issue #1107 RocketPy 宣告的最低相依版本太舊，照著安裝根本 import 不了。套件設定寫 numpy 1.13、scipy 1.0 以上就能用，實際裝這些版本會失敗。#1108 把下限提到真正能執行的版本。
• RocketPy-Team/RocketPy — Issue #1099 RocketPy 的文件建置檢查不會在送往 develop 的 PR 上執行，文件壞了要等進 master 才會發現。這個檢查只在送往 master 的 PR 觸發，近期大多數 PR 卻是送往 develop。現在送往 develop 的 PR 也會建置文件（#1104）。
• ocudu/ocudu — Issue #632（GitLab） OCUDU 的靜態分析就算沒跑完，CI 也照樣顯示通過。分析程式的結束碼被吞掉，唯一的關卡是在報告裡找嚴重等級，所以分析當掉、被中止或根本沒分析到任何檔案時，產出的是空的或殘缺的報告，看起來反而最乾淨。!1146 改成任何一步失敗就判定失敗。
• kubernetes-sigs/kueue — Issue #13913 Kueue 可能把正在被逐出的 workload 片段當成目前有效的那一個，因而放行過多 Pod。逐出分兩步寫入，先標記逐出、再釋放配額，夾在中間的片段看起來仍持有配額；彈性 Job 拿這個片段的數量當放行 Pod 的上限，就多放了 Pod。修正與回歸測試在 #13914，release-0.18 的回移是 #13925。
• kubernetes-sigs/kueue — Issue #13886 Kueue 兩個 release 分支改了一個公開函式的簽章，照上一版編譯的外部整合，升級 patch 版就會編不過。一次修正回移時替這個函式加了參數與錯誤回傳。我是逐一比對每個 package 在 tag 與分支最新版之間的公開介面才找到的。照 mimowo 在 issue 上給的方向，原本的函式照舊保留，新版本另取名字，再加上一個從外部角度編譯的相容性測試（#13887、#13888）。
• kubernetes-sigs/kueue — Issue #13778 Kueue 對彈性 Job 修改優先權標籤時，改動被接受了卻沒有作用，也沒有任何事件。Pod 數量沒變時，程式判定新舊 Workload 相容就提早結束，跳過了唯一會套用優先權變更的那一步。修正在 #13780。release-0.19 的自動回移（#13871）與我手動做的 release-0.18 回移（#13872）都把一個已發佈的公開函式簽章改掉了，我再各送一支還原（#13876、#13877）。
• kubernetes-sigs/dra-driver-google-tpu — Issue #26 Google TPU 的 DRA driver 會拿 TPU 專屬的檢查去套別家 driver 的裝置，讓合法的配置被拒絕。一個資源請求可以由好幾個 driver 一起滿足，這個 driver 卻對整份結果都做 TPU 的檢查，請求裡有別家裝置時，完整的 TPU 配置反而被拒，錯誤訊息也對不上。#25 補回官方範例 driver 本來就有的那道「只處理自己的裝置」檢查。
• IBM/power-dra-driver — Issue #322 IBM Power 的 DRA driver 遇到混用兩家 driver 的資源請求時，整個請求都會失敗，Pod 起不來。它處理設定時已經會跳過別家 driver，處理配置結果時卻沒有，每一筆都拿去查自己的可用裝置清單。現在遇到別家的結果就跳過（#323）。
• argoproj/argo-workflows — Issue #16576 這是我提的新功能：讓 Argo Workflows 的範本可以宣告 Kubernetes DRA 的資源請求。DRA 在 Kubernetes v1.34 正式釋出，Argo 在容器那一半早就能引用資源請求，Pod 層卻沒有對應的欄位，只能整段手寫進 Pod 的修補設定。我在 #16587 替 workflow 與範本加上這個欄位，只驗證屬於 Argo 的部分，其餘交給 API server。
• open-telemetry/opentelemetry-cpp — Issue #4288 OpenTelemetry C++ 內建的 HTTP server，會在連線物件被刪掉之後繼續使用它。處理函式要求關閉連線時，連線物件已經從表中刪除，程式卻沒有立刻返回，接著還去寫它的回應、對已關閉的 socket 送資料。這個 use-after-free 在 #4289 修好。
• open-telemetry/opentelemetry-cpp — Issue #4296 OpenTelemetry C++ 的 Elasticsearch 同步匯出可能永遠卡住。等待回應時沒有檢查條件，通知如果早於等待開始就會遺失，匯出的執行緒從此不會醒來；假喚醒又可能把還在進行的請求誤報為失敗。#4298 改成在鎖內記下明確的完成狀態，再依狀態等待。
• open-telemetry/opentelemetry-cpp — Issue #4291 OpenTelemetry C++ 解析位址時會讀到沒初始化的記憶體，可能把 1.2.3.4:80 靜默解析成 0.0.0.0:80。主機名稱被複製進一塊沒有初始化的緩衝區，只要名稱短於 15 個字元，解析時就會讀到殘留的值。修正在 #4292，同一支也修了 Windows 上的越界寫入。
• open-telemetry/opentelemetry-cpp — Issue #4290 OpenTelemetry C++ 的位址解析在 Windows 上會寫出緩衝區之外。複製迴圈用位元組數當上限，卻用寬字元陣列的索引去寫，超過 200 個字元的位址最多會寫穿 400 個位元組。#4292 讓兩個平台改用同一套解析方式。
• Apache YuniKorn — YUNIKORN-3329（Apache JIRA） YuniKorn 的 gang scheduling，可以被一個 Pod 註記弄出負的資源需求。任務群組的成員數與資源量直接取自 Pod 的註記，沒有上限，相乘與加總都可能溢位，最後把負的需求送進排程核心。YuniKorn PMC 成員 Wilfred Spiegelenburg 分類後指派給我。#1053 在解析註記時就拒絕負值與各種溢位，並照 Wilfred 的要求併進既有的迴圈。committer 以 squash commit（04c62413）併入 master，所以 PR 顯示 closed；收進 1.10.0。
• kubernetes/kubernetes — Issue #140436 Kubernetes 的 DRA 配置器放棄一個候選裝置時，沒有把已經保留的計數與限制還回去，保留狀態於是外洩。#140431 補上這段回滾。
• kubernetes/kubernetes — Issue #140434 Kubernetes 的 DRA 配置器，會把不同 driver 的同名資源池混在一起計算。計數快取只用資源池的名稱當鍵，兩家 driver 剛好用了同一個池名時就互相碰撞。修正見 #140435。
• kubernetes/kubernetes — Issue #140433 Kubernetes 的 DRA 配置器，會把共用的計數扣兩次。一個可共用的裝置只以共用 ID 記錄下來時，配置器沒認出它已經配置過，又扣了一次。#140437 修掉這次重複扣。
• kubernetes/kubernetes — Issue #140441 Kubernetes 的 DRA 容量請求很大時，向上取整的計算會溢位成負數，把無法滿足的裝置判成可以配置。修正在 #140442。
• kubernetes/kubernetes — Issue #140472 Kubernetes 一個已經修好的除以零錯誤又回來了。這個錯誤在 #139653 回報、#139698 修過，但步長是 2 的 64 次方的倍數時會重新出現：守衛用精確的方式判斷步長大於零，後面的計算卻用超出 64 位元就截斷的值，同一個數通過了守衛，除下去卻是 0。#140666 把這個缺口補上。
• cncf-tags/container-device-interface — Issue #320 Container Device Interface 遇到只有一個字元的廠商或類別名稱時會當掉。切字串少了長度為 1 的防護，算出不合法的範圍而 panic；旁邊驗證裝置名稱的函式本來就有這道防護，看得出是遺漏。#321 補上它。
• intel/intel-resource-drivers-for-kubernetes — Issue #73 Intel QAT 的 DRA 外掛釋放橫跨多個實體功能（PF）的請求時會中途返回，留下沒有釋放的裝置。修正見 #74。
• kai-scheduler/KAI-Scheduler — Issue #1873 KAI Scheduler 加總 DRA 的 GPU 數量時會溢位，低估佇列的需求，擋掉本來應該成立的 GPU 回收。受影響的是同一個佇列裡需求被抵銷掉的正常工作，請求過大的那一個反而沒事。修正在 #1874。
• kubernetes-sigs/dranet — Issue #255 DRANET 合併網路設定時，會把目的地相同、路由表不同的路由丟掉。去除重複時只看目的地；修正見 #256。
• kubernetes-sigs/dranet — Issue #253 DRANET 的路由驗證會放行 IPv4 與 IPv6 混用的設定，kernel 實際上卻會拒絕。#254 讓驗證和 kernel 的行為一致。
• kubernetes-sigs/dranet — Issue #250 kubelet 的資料目錄搬過位置時，DRANET 會註冊失敗。DRANET 把 kubelet 的外掛目錄寫死成預設路徑。我先把它和看起來相似的 #19 區分開來，再以 #251 修好。
• kubernetes-sigs/kueue — Issue #12896 Kueue 的 DRA 裝置數量溢位，會讓超額的 Workload 被放行，還汙染 ClusterQueue 的已用配額。修正在 #12897。
• kubernetes-sigs/kueue — Issue #12908 Kueue 計算計數扣抵時的乘法會溢位。和 #12896 是同一類問題，修正見 #12909。
• ocudu/ocudu — Work Item #577（GitLab） OCUDU 的 NTN 設定裡，k_mac 是唯一沒有做範圍檢查的命令列參數。3GPP 規定它只能是 1 到 512，其他 NTN 參數都有範圍檢查。!1045 補上這道檢查。
• ocudu/ocudu — Work Item #579（GitLab） OCUDU 的 NTN 時間提前量，兩個參數相加可能超出 3GPP 規定的範圍，卻沒有任何檢查。!1047 改成檢查兩者的總和是否落在範圍內。
• ocudu/ocudu — Work Item #658（GitLab） OCUDU 把系統資訊移除再加回之後，廣播出去的系統資訊會變成全是 0。編碼器的清單每次重新設定都會調整大小，內容快取卻只增不減，兩者對不上之後就拿到空的編碼器。修正隨維護者的 SI 重構 !1260 合併，我的 !1162 改成補上回歸測試。
• kubernetes-sigs/cluster-api-provider-aws — Issue #6129 Cluster API AWS 移除第二個控制平面負載平衡器的設定時，驗證 webhook 會當掉。webhook 只在新舊值都是空的時候跳過這組檢查，舊的有、新的被設成空時就去讀空值。現在這種移除會被明確拒絕，回傳驗證錯誤（#6130）。
• volcano-sh/volcano — Issue #5620 Volcano 的 DRA 配額會計會溢位，把超額的 Workload 判成可以配置。容量外掛直接把使用者可以控制的裝置數量相加，沒有溢位保護，和 Kueue 先前修過的是同一類問題。#5621 加上不會溢位的加法與乘法；另一條仍直接相加的路徑由 #5625 補上，維護者 JesseStutler 推回三輪後，只留下使用者真能觸發的那一半，release-1.15 的回移是 #5983。
• akhenakh/sgp4 — Issue #10 一個 Go 的 SGP4 衛星軌道函式庫，遇到深太空軌道時會回傳錯誤的位置，卻不報錯。函式庫沒有在 SGP4 與 SDP4 的適用邊界上拒絕輸入，#11 改成明確拒絕。
• kubevirt/kubevirt — Issue #18541 KubeVirt 對 vGPU 顯示設定的兩處判斷互相矛盾，同一份設定 VM 被接受，實際啟動時卻被拒絕。一處把「沒寫明是否啟用」的 ramFB 當成關閉，另一處的預設值卻把它補成開啟。#18542 讓兩處一致。
• kubernetes-sigs/dra-driver-cpu — Issue #253 DRA CPU driver 只處理 Ctrl-C 的中斷訊號，Pod 正常終止時的清理不會執行。kubelet 停止 Pod 時送的是 SIGTERM，driver 沒有攔截；#257 補上。
• pollen-robotics/reachy_mini — Issue #1165 Reachy Mini 無線版的背景程式跑幾個小時後會吃掉約 1.8 GB 記憶體，把 Raspberry Pi 的記憶體耗盡。兩個原因疊在一起：連線中繼在 token 被拒時每 5 秒重連一次，glibc 又在四核 Pi 上開了很多個記憶體配置區、用過的記憶體不還給系統。跑了一週的量測，記憶體從約 1.8 至 2 GB 降到 178 MB。我送了兩支修正：限制配置區的數量（#1193），以及把重連改成有上限的退避（#1224）；token 被拒後立刻重試的那條路，由 alozowski 的 #1201 先修好。
• kptdev/porch — Issue #766 這是我提的新功能：讓 Porch 資料庫快取的 SQL 查詢跟著請求一起取消，也受時限約束。快取的每個函式都收到 context，卻只拿來開追蹤，查詢不會隨上層取消，關機時也停不下來。#405 把這些查詢都改成帶 context。

C · 我回報、上游據以修復並合併，或仍在審查中

這一組是我回報、由別人修好或還在處理中的問題。成群的同類缺陷整理在 Audits；沒有逐一列出的其餘回報，見 GitHub 上的完整清單。

• kubernetes/kubernetes — Issue #143901 用 Python client 建立的 ResourceClaim，之後連加 label 都會被拒絕。opaque parameters 以客戶端送出的原始 bytes 存進 etcd，apiserver 回傳或套用 patch 時會重新編碼，spec 的不可變檢查比的是 bytes，於是更新失敗。zl86790 的修正 #143923 審查中，我審過。
• kubernetes-sigs/kueue — Issue #18129 Kueue 以 implicit TAS 收下的 Job，在 flavor 的 nodeLabel 改成跟 Job 自己的 nodeSelector 衝突之後，會被停掉。兩邊的條件合併失敗時，Kueue 少做了一步標記，之後拿 Job 和 Workload 比對就對不上，連只改 status 的更新都會讓 Job 被停下來。Job 還有 Pod 在跑時，這個停止會一直重試；沒有 Pod 時，Workload 被刪掉重建，新的卻已經放不進原本的 flavor。vic-comm 11/3 送了修正 #18223，審查中。
• stratoweave/stratoweave — PR #724（本人為共同作者）、Issue #521 StratoWeave 的 etcd 測試偶爾在新連線上讀不到剛寫進去的值，根因在 Acton 語言的 HTTP 客戶端。我回報 #521 並送了 #523：連線還沒建立就送出的請求，連上之後會再送一次，多出來的回應落到下一個請求上。plajjan 直接在 Acton 修好（acton #3335、acton #3331），以被取代為由關閉 #523，並把其中處理錯誤回應的一段抽成 #724，列我為共同作者，10/30 合併。PR 是他送的，不算進我的合併數。#521 已在 11/2 關閉。
• kubernetes-sigs/kueue — Issue #17899/#17907 Kueue 啟動 Job 時，有兩種情況可能讓 Workload 保留了配額，Pod 卻跑不起來。同一個 admission check 可以對同一個 PodSet 給兩筆 podSetUpdates，Workload 的 webhook 照收。啟動 Job 時每個 PodSet 只套用第一筆，TAS 安排位置時卻每一筆都算，所以 Pod 沒拿到的 toleration，TAS 當成有，可能選到 Pod 不能容忍的帶 taint 節點（#17899，henry3260 已認領）。另一則是 Job 的 Pod template annotation 剛好到 262,144 bytes 的上限：Kueue 加上 kueue.x-k8s.io/workload 之後，API server 拒絕解除暫停，Kueue 卻不把這當成永久錯誤，只在 log 裡記下、一再重試，Job 與 Workload 上都看不到原因，配額一直保留；waitForPodsReady 預設 30 分鐘後把 Workload 驅逐，重新排隊後又以同樣的方式失敗，沒有次數上限（#17907，Huangpinhan 已認領）。兩則都還沒有修正的 PR。
• kubernetes/test-infra — PR #38158（含本人的 commit） Kubernetes 的 DRA node e2e job 從 containerd 2.1 換到 2.4，1.37 分支留下的舊 job 照樣保有 TestGrid 分組。這支是 dims 的 PR。release-1.37 還留著 2.1 那幾支 presubmit 的分叉，它們在 TestGrid 上的分組要保住；我審查時照 pohly 提的另一個做法，把 TestGrid 的 annotation 移到 1.37.yaml 裡對應的 job 上，本機檢查過分組與分頁都沒變。pohly 認為這樣 job 定義比較單純，日後拿掉 1.37 時這段設定也會一起消失，請我出 patch，dims 套成第二個 commit，10/26 合併。PR 是 dims 送的，所以不算進我的合併數。COS 上 2.4 的 job 因 runc 需要 GLIBC_2.38 而失敗，我把 runc 改成靜態連結的那個改動回移到 containerd 的 release/2.4（containerd #14465）。dims 起初說不需要，看到新 job 的失敗紀錄後同意，和 AkihiroSuda 一起 approve，10/27 合併。COS 上 2.4 的 periodic job 在合併後第一次執行時還裝到舊版套件，仍然失敗，之後到 10/28 連續五次通過。release-1.35 到 1.37 的 COS DRA job 裝的是 containerd release/2.1，裡面的 runc 同樣需要 GLIBC_2.38，也失敗了，我回報在 #143451。2.1 已經停止維護，我送了 test-infra #38166 把 1.37 的 DRA job 換到 2.4，kannon92 10/28 回覆 CI 能通過的版本就可以，同意改用 2.4。Ubuntu 的 job 換到 2.4 要用到我在 #141626 加的 image_exclude_regex，1.37 的測試程式還不認得，回移的 #143479 要等審查與 release manager 核准；COS 的 job 用的是 image_family，不需要這支回移。10/31 我把 #38166 縮小成只換 COS 的四個 job 定義（containerd release/2.4、COS 133），轉成正式 PR，Ubuntu 的 job 維持原樣。
• kubernetes/kubernetes、kubernetes-sigs/windows-testing — 四則 CI 回報（#143371/#143380/#143984/windows-testing #603） 在 Release Team 追 CI 時開的四則，問題都出在測試環境與腳本：三則讓 job 間歇失敗，一則讓 job 少跑一部分測試卻照樣通過。kube-up 取 COS 映像家族裡最新的一個，不看它是否已就緒；cos-cloud 發佈新映像的空檔裡，建控制平面 VM 會失敗，當時也不會重試。10 月的四次 COS 發版之後共失敗七次，分布在六支 release-blocking 與 informing 的 job，我提議查詢時只取狀態為 READY 的映像（#143371），照這個做法送的 #143437 在 11/5 合併。過去的 log 沒記下選映像時的狀態，它能不能擋掉那七次失敗還無法確認；#143371 要等 1.37 的回移合併、再兩週沒有同樣的失敗才關閉。11/2 與 11/8 又失敗四次，原因不同：查映像的 gcloud 碰到 API 錯誤時，腳本拿到空的映像名稱也不檢查，後面的重試都沿用這個空值（#143984）。資源管理器的 node e2e job 跑在 n2d-standard-32 上，test-infra 的設定註明它有兩個 NUMA 節點，GCS 留存的 7/26 以來 77 次 topology manager 執行，VM 卻都只有一個；需要兩個以上 NUMA 節點的測試全被略過，topology manager 每台 VM 只跑了 11 個裡的 2 個。kannon92 關掉 #142985（機器缺貨的部分已修好）時，請我把 NUMA 這一半另開（#143380）。Windows 的 capz job 抽到 germanywestcentral 時，常因 AKS 容量不足建不起管理叢集，10/5 到 10/24 這個區域 26 次失敗 11 次；腳本為這種錯誤寫了重試，但 errexit 會先讓腳本結束，比對的錯誤碼名稱也不對，重試一次也跑不到；清理又停在半路，留下沒刪的資源群組（windows-testing #603）。#143371、#143380 與 #143984 由我自己接手。#143380 要換的機型，kannon92 要先用 presubmit 在 k/k 的 PR 上實際跑過；我把 test-infra #38159 改成新增一支手動觸發、跑在 n2-standard-64 上的 presubmit（COS 與 Ubuntu 各一台），kannon92 給過 lgtm 與 approve，我修正 Ubuntu 的映像設定後 lgtm 被拿掉，要等重新 lgtm。
• kubernetes-sigs/kueue — Issue #17524/#17525 Kueue 暫停 LocalQueue 時會把它的計數器歸零，暫停中刪掉又會留下舊的計數；fair sharing 下兩個 ClusterQueue 的 share 不受搶占影響時，會一直互相搶占。前者是因為暫停走的是刪除 LocalQueue 的路徑，連帶清掉計數器與 histogram，恢復之後下一次 admission 的計數從 1 重新開始；暫停中的 LocalQueue 已經不在佇列管理器裡，刪除時那段清理會提早返回，暫停期間記下的驅逐與完成計數就留下來，同名重建的 LocalQueue 會從這些值開始算（#17524）。歸零那一半是 tomsen02 在留言裡發現的，我在 main 上重現後併進同一則。後者是審 LindaSummer 的 #17194 時找到的：兩個 ClusterQueue 向同一個 Cohort 各借一張 GPU，share 都是 500，又在搶同一份 CPU；CPU 工作的進出不改變 share，fair sharing 比較 500 與 500 兩個方向都成立，只要驅逐順利完成就一再互相搶占，在 envtest 裡 25 秒內搶了一百多次（#17525）。兩則都附可重現的測試。vic-comm 照我在 issue 裡提的做法以 #17968 修好 #17524，我審過，11/5 合併。LindaSummer 認領了 #17525，我在 issue 裡提了只擋掉這種平手的寫法；它會改到 fair sharing KEP 的規則，我建議先在 issue 裡談定做法再送 PR；JanKaczmarski 10/22 認為分析在數學上成立，但想謹慎一點，請熟悉 fair sharing 的 pajakd 給意見。#17525 還沒有修正。
• kubernetes-sigs/kueue — Issue #17384/#17385 Kueue 重新排隊 DRA 工作時，可能丟掉排程途中送進來的新配額；一個 RuntimeClass 的事件，會讓整個叢集裡等待中的工作都重新處理一次。前者接在 Anjali-Chauhan1 修 #14535 的 #14562 之後：工作被排程器取出、還沒放回佇列的這段時間，控制器推進來重新算過的配額只寫進 LocalQueue 那一份，放回佇列時又被取出當下的舊值蓋掉，排程器可能拿舊配額保留資源（#17384）；digvijay-y 的 #17388 在修，審查中。後者是第二個欄位篩選條件蓋掉了 RuntimeClass 的篩選，除了真的有變動，controller 每次啟動和每次 informer resync（預設約 10 小時）也會對每個 RuntimeClass 各跑一遍（#17385）；dlanov 的 #17386 修好，我也審過，11/3 合併。
• lima-vm/lima — Issue #5643 Lima 在 macOS 上關閉自動啟動時，可能把開機啟動的 LaunchDaemon 留下來；VM 刪掉之後就關不掉了。同一台 VM 同時設了登入和開機兩種自動啟動時，limactl autostart disable 移除 LaunchAgent 就結束；VM 刪除後再下 disable，會先去找這台 VM，回報 instance not found。同一段程式還有兩個小問題：檢查 plist 時，權限錯誤會被當成沒有註冊；launchctl bootout 失敗時錯誤被直接丟掉。這兩處我在 #5649 改成會回報錯誤，AkihiroSuda 10/28 合併。其餘牽涉到要拆掉哪個 job：job 的標籤只用 VM 名稱，不同使用者或不同 LIMA_HOME 下的同名 VM 會撞在一起，所以我先問維護者要怎麼把載入中的 job 對到 VM，等維護者決定後再送修正（#5643）。
• Niko1221/Strata — Issue #2990/#2991 Strata（在一般消費級硬體上跑 Qwen3.8-Flash-Next 的推論引擎）的建置腳本與自我測試各有一個問題：SYCL 建置腳本成功時回傳 1、編譯失敗時反而回傳 0；PLE 讀取器的自我測試把測試檔寫在暫存目錄的固定檔名，兩個建置同時跑會互相覆寫，造成當機或卡住。建置腳本開了 pipefail，結尾卻沒有 exit，結束碼變成最後一條 grep 的結果：建置成功時找不到 FAILED 行，回傳 1；編譯失敗時找到了，反而回傳 0。用 && 串在後面的步驟，因此在建置成功後被跳過，失敗後照跑（#2990）。自我測試的 ctest 項目沒有指定目錄；我讓兩份測試共用同一個 TMPDIR，第二份分別晚 0 到 6 秒啟動，六組裡有五組出事：兩組有一份因 SIGBUS 結束，三組有一份印出 FAIL 之後卡住，一直到 182 至 764 秒後被我終止（單獨跑一次約 13 秒）；各用自己的 TMPDIR 時，12 次全部通過（#2991）。兩則都附了修法；#2990 由維護者 Niko1221 在 0.2.7 修好，讓腳本照建置本身的結果結束，#2991 維護者 11/5 清理舊 issue 時以 not planned 關閉。
• kubernetes-sigs/kueue — Issue #14395/#14438 Kueue 預建的 Workload 和 Job 對不上時，配額先被釋放、Pod 卻還在跑；TAS 第一次評估偏好的節點親和性時，分數算成兩倍。前者是 Workload 以 OutOfSync 結束之前沒有先停掉 Job（#14395）。後者是分數寫進共用狀態後又被加一次，之後每次評估都變成 0（#14438）。adibmbrk 的 #18215 修好 #14438，11/6 合併；我原本的 #14444 在 #17051 接手時已關掉。#14395 的修正 #14441 為了不超過 Kueue 開著 PR 數量的上限，10/11 先關掉，問題仍在 main 上。
• openwrt/openwrt、openwrt/mt76 — 同一塊板子的兩則驅動回報（#25721/mt76 #1156） 同一塊 Edimax BR-6478AC v2 上，OpenWrt 的兩個驅動問題：外接 MT7530 交換器的流量計數器全對錯了欄位；MT7612E 的 5 GHz 發射功率在一次 MCU 逾時恢復之後一直偏低。交換器驅動一律用 MT7620 內建交換器的暫存器配置去讀，換到 MT7530 上，同一組位址是另一批計數器，標成「收到的封包」的其實是傳送延遲的次數；我下載 50 MiB 前後比對，網路介面多收了三萬多個封包，交換器那邊收到的計數仍是 0（#25721）。Wi-Fi 那則在功率設成 8 dBm 時最明顯，恢復後掉了 7 到 9 dB，觀察的一分多鐘裡都沒有回來；暫存器紀錄顯示，每秒一次的溫度補償把補償欄位一路壓到最低。我讀到的原因有兩個：韌體重新載入後，TSSI 校正的旗標沒有清掉，TSSI 初始化不會重跑；定期的校正工作也可能插進重新載入的空檔，用錯的順序先跑。兩個試驗性的修改一起用時擋得住，但只在這一塊板子上試過，還留著 2 到 3 dB 說不清楚的損失，所以我只描述試過什麼，沒有當成修正送出（mt76 #1156）。兩則都還沒有修正。
• matplotlib/matplotlib — 3D 繪圖的兩則回報（#32127/#32129） Matplotlib 3.11 的 3D 線條，座標用 list 傳入、又剛好有一個點在目前的刻度下無效時，畫的時候會當掉。set_data_3d 接受任何 array-like，繪製時卻直接讀 .shape；只有出現 NaN 這類無效值才走到那段，所以平常看不出來，3.10 沒有這個問題（#32127）。ShamikOfficial 的 #32306 改用 np.shape 讀取，list 和 tuple 都能畫，10/14 合併。另一則還開著：自訂刻度的 limit_range_for_scale 如果照 Matplotlib 自己 LogScale 的寫法只處理純量，3D 軸上的資料會整批消失，沒有警告也沒有錯誤（#32129）。
• insomniacslk/dhcp — Issue #594 Go 的 DHCP 函式庫把時區偏移當成無號數解讀，UTC-5 會被印成大約 136 年。RFC 2132 規定時區偏移（option 2）是有號的 32 位元整數，函式庫卻和租約時間共用同一個無號的解碼器。這只影響顯示，送出的值和租約都不受影響。SashaMIT 的 #602 給它獨立的有號解碼，維護者 insomniacslk 10/14 合併。
• kubernetes-sigs/kueue — 別人修好的三則回報（#14535/#14266/#14372） Kueue 的三個問題，分別由別人的修正或依賴升級解決。DRA 的 Workload 在排程途中被更新時，重新排隊可能把最新的物件配上舊版本算出的配額（#14535）；Anjali-Chauhan1 的 #14562 改用當前版本算出的配額，10/15 合併，也回移到 0.19。StatefulSet 的 webhook 以「沒有就緒的副本」判斷可以改 queue 名稱，Workload 還保留著配額時也放行，之後的 reconcile 永遠套用不了（#14266）；weizhoublue 的 #16320 已經修好這個判斷，Andrushika 指出後由 mimowo 在 10/15 關閉。Kueue 編譯 DRA 裝置選擇器時給的是空的功能集，CEL 環境可能比 API server 的窄（#14372）；v0.20.0 升到 Kubernetes 1.37 的依賴之後，編譯時一律用最新的環境，不再看傳進去的功能集，我確認後關閉；0.19 仍是舊版，但要開 alpha 功能才碰得到，所以沒有要求回移。
• vllm-project/vllm — Issue #60237 vLLM 的 structured output 在預設的 auto 模式下，會把一部分 JSON schema 交給處理不了它們的 xgrammar，其中的限制被靜默丟掉。anyOf、oneOf、allOf 旁邊同時寫著其他限制時，xgrammar 會把那些限制丟掉，xgrammar 那邊的修正還沒合併。vLLM 先前（#59061）只把兩個分支以上的 allOf 改送 guidance，單一分支的 allOf 和所有的 anyOf、oneOf 仍然送 xgrammar。我用兩個 schema 重現，不需要模型或 GPU：限制寫在最上層時整份 schema 等於沒有作用，xgrammar 接受了全部九個不合格的輸出，guidance 全部擋下。joselynrianaaa 10/6 送了 #60263：遇到 combinator 旁邊還有其他限制的 schema，就改送 guidance，審查中。
• open-telemetry/opentelemetry-collector-contrib — Issue #51794 OpenTelemetry Collector 的 journald receiver 在匯出失敗、正在重試時被停掉，重啟後會跳過那一筆 log，再也不會送出。receiver 在送出之前就先存下讀取位置，重啟時從這個位置之後開始讀，正在重試的那一筆就被當成處理過了。條件是開了持久化儲存、receiver 自己的重試與同步送出的 feature gate；我用 SIGTERM 與 SIGKILL 各跑十次，二十次都少了那一筆。NachiketPatil26 也重現了，照 code owner 的意見送出修正 #52685，審查中。
• kubernetes-sigs/kueue — fair sharing 的 share 回報（#16529/#16530） Kueue 的 fair sharing 在兩種邊界情況下，回報的 share 和實際狀態對不上。權重為正的 ClusterQueue 若只借用 Cohort 沒有可出借的資源，share 會是 0，看起來和沒有借用一樣，排序時也被當成同等（#16529）；權重為 0、有借用的 Cohort，指標回報 +Inf，說明文字卻寫 NaN，同樣狀態的 ClusterQueue 回報的則是 NaN（#16530）。兩則都附重現步驟。#16530 由 abhayjoshi201 的 #16581 修好，我審過，10/7 合併。審查時 mimowo 覺得用 +Inf 判斷有點隨意，我另開 #17057，把 ClusterQueue 與 Cohort 的四處判斷都改成直接看是不是權重為 0 又在借用，10/13 合併。#16529 由 LindaSummer 10/14 開的 #17194 修其中一部分，我 10/21 給了 lgtm，等維護者 approve。同一塊另外三個 share 的問題，我的修正都在 10/2 合併：超過 int64 時在 amd64 上變成負數（#16487）、權重為 0 的借用者被算成 0（#16488）、權重極大時被捨入成 0（#16528）。
• argoproj/argo-workflows — Issue #16626 → #16891 Argo Workflows 的節點 ID 偶爾會撞在一起，撞到時 workflow 會遺失節點，嚴重時父子關係繞成迴圈。我先回報另外兩個走訪節點圖的程式也假設圖裡不會有迴圈（#16626）；維護者 Joibel 選擇直接修掉碰撞本身（#16883），我同意後把 #16626 關掉。審 #16883 時，我又找到 resubmit 那條路徑會沿用舊的編號，改名時還可能撞出新的碰撞。Joibel 據此開了 #16891、註明是我找到的，再以 #17028 修好。兩支修正都回移到 4.0 與 4.1；#16883 已隨 v4.0.12、v4.1.4 發佈，#17028 會在下一個修補版出貨。
• tektoncd/pipeline — PR #10827（承接本人的 #10330） Tekton 的 tracing 現在看得出每一輪 reconcile 實際寫了什麼。這是我做的新功能，回應 vdemeester 開的 #10322：PipelineRun 與 TaskRun 的每一輪 reconcile 會被標成沒寫入、只寫 status、只寫 metadata，或兩者都寫。我在 #10330 送出，依審查意見改了取基準的時機與屬性名稱，之後這支 PR 停住，我自己關掉。waveywaves 接手成 #10827，裡面兩個 commit 是我寫的，已合併；PR 是 waveywaves 送的，所以不算進我的合併數。同一個 issue 的文件（#10826）與 helper（#10834）也由 waveywaves 接手，還在審查。
• zephyrproject-rtos/zephyr — PR #112729（承載本人的 commit，源自 jetpax/PiZZa #1） 讓 Raspberry Pi Zero 2 W 在 Zephyr 上四顆核心都能跑。這是我做的新功能：開機時把另外三顆核心喚醒，核心之間透過晶片的 mailbox 互相通知排程與 FPU 狀態。我先在 jetpax 的專案交出原型（jetpax/PiZZa #1），實機上四顆核心都排得到工作，也寫明還沒完成的部分；jetpax 照同一個設計補完，再把它送進 Zephyr 上游。這支 PR 由 jetpax 送出，四個 commit 裡有一個是我寫的，仍在審查，合併後也不算進我的合併數。
• kagent-dev/kagent — 串接模型的兩則回報（#3009/#3070） kagent 用 Gemini 時，structured output 的答案還沒驗證就先送到了 client；同一個 agent 的兩個 Ollama 模型，只能連同一台主機。agent 帶有工具時（kagent 一律會加一個），Gemini 會改用工具呼叫來交答案，而 kagent 先把這個工具呼叫發出去才做驗證，所以格式不對的答案照樣送得到使用者手上（#3009）。這是我寫 structured output 文件（website #545）時逐項實跑發現的。Ollama 那則是 controller 把主機寫進主模型與摘要模型共用的環境變數，後寫的蓋掉先寫的，主模型也會連到摘要模型那台（#3070）。liyifan9642-creator 修 #3009 的 #3024 停滯後，11/3 被機器人關閉；兩則都還沒有修正。
• zephyrproject-rtos/zephyr — i2s/dma 跨 vendor 稽核（#120493/#120501/#120503/#120504） 把檢查資源歸還與 API 約定的同一套方法，換到另外四家 SoC 的 i2s 與 DMA 驅動上，各找到一個問題。nrf_tdm 準備緩衝區失敗時，沒有把借來的記憶體區塊還回去，RX 與 TX 兩側都會漏（#120493）；i2s 的 API 把讀取設定列為必備功能，卻不檢查驅動有沒有實作，litex 與 max32 兩個驅動沒有實作，一呼叫就是呼叫到空指標（#120501）。mcux_lpc 的 DMA 在還沒設定過的 channel 上停止傳輸時，會讀寫陣列界外的記憶體（#120503）；siwx91x 在串流開始前或停止後收到 DROP，會多放掉一次電源管理的參照計數（#120504）。#120503 的修正 #120926 在 11/9 被 teburd 要求修改，issue 同一天被機器人關閉；#120501 由 saibontha18-hub 的 #121168 修好，我審過，10/15 合併；#120493 由 JakkulaVeerababu 的 #124310 修好，11/4 合併；#120504 沒有人修，11/8 被機器人關閉。
• NVIDIA/aerial-cuda-accelerated-ran — 移植到 DGX Spark 時回報的問題（#34/#36/#37/#38/#41/#45） 把 NVIDIA 的 GPU 加速 5G RAN 搬到 aarch64 的 DGX Spark 時，一路撞到的平台假設。CRC 的一條 API 路徑漏了初始化，在 DGX Spark 的 GPU 上測試失敗（#34）；有一個測試對成功的回傳值，定義和程式相反（#36）；啟動腳本寫死 x86 的函式庫路徑，在 aarch64 上起不來（#37）；產生效能測試資料的腳本把參數名稱的大小寫打錯（#38）。前傳驅動把網路線沒接當成致命錯誤，沒接線時 RU 模擬器與控制程式都起不來（#41），接著我也請求為自迴路測試加一個可以恢復的逾時設定（#45）。整段移植過程寫成預印本（Cross-Layer Diagnostics for Operator-Side Platform Porting of GPU-Accelerated 5G RAN）。六則都還開著，最近一次查 main，#37 與 #38 的問題仍在。
• zephyrproject-rtos/zephyr — Issue #115722 ESP32 的 DMA 驅動在多個 channel 同時傳輸時，最先結束的那個會替其他 channel 放掉電源管理的鎖。驅動只用一個旗標記錄有沒有拿到這個鎖，第一個結束的 channel 把鎖還掉，其他還在傳的就失去保護。我回報後，raffarost 以 #117706 把旗標改成每個 channel 各一個，已合併；這是社群修的，我之後把 issue 關閉並註明修在哪一支。
• 我回報、由社群其他貢獻者修復並合併（RocketPy 7 則、kueue 22 則、opentelemetry-cpp 5 則、kubernetes 5 則、HAMi-DRA 1 則、otel-collector-contrib 1 則、test-infra 1 則、kernel-module-management 1 則、scheduler-library 1 則、dra-driver-cpu 2 則、dra-driver-google-tpu 3 則、dra-driver-spyre 1 則、dra-example-driver 1 則、spinifex 1 則、KAI-Scheduler 1 則、taiwan-md 1 則、zephyr 2 則、wshobson/agents 1 則、anthropics/claude-code 1 則） 這些問題是我找到並回報、由專案裡其他人送 PR 修好的。修正不是我寫的，所以不算進 Found & Fixed；我做的是把問題找出來，寫清楚怎麼重現。
  Kueue 有 22 則，多半是配額算錯或控制器卡住。其中兩則花了最多力氣。一則是 DRA 的工作在退避後重新排隊時，資源被照原始的 Pod 規格重算（#13930）：vibhordubey333 的修正 #13967 我審查時改跑整合測試，發現修正版會讓帶 ResourceClaimTemplate 的工作再也回不到佇列，比原本更糟，作者因此換了寫法才合併。另一則是排除規則比資源轉換先套用，轉換規則會靜默失效（#14204）：照設計文件加檢查，會讓官方文件裡的設定在升級後起不來，所以我把三種處理方式寫出來留給維護者選，henry3260 選了在設定驗證時擋下（#15926），升級前要先調整設定。其餘和計費有關的：負的 request 被算成負的費用（#14216，#14367）；兩個 DRA 資源名稱對到同一個配額時被壓成一筆（#14156，#14200，我審過，也手動回移到兩個舊版本）；只在 limits 寫到 DRA 資源的工作沒有經過前處理（#14393，由別人一支較大的修正順帶修好，bolubo 照原本的重現步驟複驗無誤後我關閉）；直接寫出的 Workload 可以用比容器還小的 Pod 層 request 少算配額（#14255，#16047）；預建 Workload 的比對漏了兩種資源（#14390，#14436）；合併資源清單時，回傳值與輸入共用同一份儲存（#14375，#14387）。控制器卡住或不停重試的：Workload 無法跟著擁有者離開優先級類別，又一直重試（#14482，#14565）；優先級類別的批次更新中途無法取消（#13982，#14737）；StatefulSet 的 reconcile 在同步 label 或列出 Pod 失敗時就停住（#14013 由 #14597、#14211 由 #15609 修好，我送的 #14117 隨之撤回）；worker cluster 上的優先級蓋掉 MultiKueue 設定的值（#13929，我送的 #14116 沒經審查就關閉，後來由 weizhoublue 的 #14963 修好）。驗證與觀測的：MPIJob 上的 Pod 編號註記完全沒有驗證（#14475，#14485，我也審過）；MPIJob 驗證時排序了不屬於它的資料（#14476）；不同 namespace 的同名佇列共用一個排隊位置（#14400，#14431）；metric 少了一個 label（#14457）；ClusterQueue 的自訂 label 值一改，計數與直方圖就被清空，Cohort 卻會保留（#14478）：我在 #17413 把保留的條件寫進 KEP-7066，要每個自訂 label 都設了 trackedValues，Andrushika 照這個條件以 #17260 修好，我審過，11/9 合併；負的觀測值沒有夾成零（#14456，#14474）；KubeRay 的測試用到過期的映像（#14518，維護者 tenzen-y 以 #14523 修）。兩個 flavor 的 nodeLabels 衝突時，Pod 的 nodeSelector 每次結果可能不同（#14409，bolubo 以 #16170 修）。9/30 我也撤回幾支已經被別人的修正涵蓋的 PR：#14048（修自報的 #14007，已由 #15954 與 #16041 涵蓋）、#14448（#15499）、#14439（#15577）、#14407（#16047 已涵蓋），以及實際上走不到的 #14415。#14367、#14200、#14436、#14431 與 #14737 是 pujitha24 修的，這個帳號已經不在，PR 頁面打不開，連結改指向合併進 main 的 commit。
  Kubernetes 有 5 則，都和 DRA 或 kubelet 有關：同一個 request 配到多個裝置時，「屬性值不可重複」的限制擋不住重複（#140438，GunaKKIBM 以 #140600 修）；kubelet 重啟後重新準備同一個 claim，會把裝置再記一次，checkpoint 越長越大（#140471，bart0sh 當時審查中的 #140274 修好；我指出舊的版本分支還是舊行為，bart0sh 再開了回移；ashishpatel26 補的回歸測試 #140918 我審過，10/23 合併）；driver 沒有實作健康回報時，kubelet 每 5 秒記一次 ERROR（#140353，harche 當時審查中的 #139477 已經處理（之後合併），我自行關閉）；容量的合法值清單去重時，把不同的小數值當成重複（#140457，sunya-ch 的 #140161 修好，我驗過後關閉）；節點資源占用查裝置時只比名稱、不比 driver（#140460，pravk03 的 #140009 修）。
  OpenTelemetry 有 6 則：C++ SDK 的位址類別遇到超出範圍的 port 會靜默繞回（#4305，維護者 marcalff 以 #4500 修），同一個類別還把位址當成未對齊的 sockaddr_in 存取（#4307，JonSnow1807 以 #4725 修）；Elasticsearch exporter 收到含非法 UTF-8 的 log，會讓整個行程中止（#4439，om7057 以 #4501 修）；一個早就沒人用的標頭在 Windows 上編不過（#4299，owent 以 #4306 直接移除）；ETW exporter 把字串陣列轉成 vector 時長度變成兩倍，還不管 string_view 的長度讀過頭（#4347，Tyagiquamar 以 #4656 修，我審過）；Collector 的 Prometheus remote write receiver 把長度不對的 trace 與 span ID 補零或截斷，沒有拒收（#50547，arcusbuilds 以 #50576 修；這個 receiver 也在我的 #50292 稽核範圍內）。
  各家 DRA driver 有 8 則：Google TPU driver 接受不支援的晶片世代（#32，#48）、說會驗證網路設定卻從不比對讀回的值（#33，#46）、不擋非正的拓撲數值與相乘溢位（#23，#51），三則都由 yindia 修好；IBM 的 Spyre driver 拿別家 driver 的配置結果去解析，讓多 driver 的 claim 整個失敗（#59，這個 repo 目前只收協作者的 PR，由維護者 sunya-ch 依報告實作 #65）；dra-driver-cpu 的額外參數能改掉綁定位址，健康檢查卻沒有跟著改（#256，維護者 fmuyassarov 以 #294 移除那個參數）；同一個 chart 掛載 kubelet plugin 目錄前不檢查路徑存不存在，設錯了也照樣啟動（#255，Kitio-Tek 以 #378 修好路徑不存在的情況）；dra-example-driver 讀不到 checkpoint 時解參考空指標（#240，vikasbolla 以 #248 修，我也參與審查）；HAMi-DRA 把 annotation 的值沒加引號就串進 CEL 選擇式（#73，moezdil 以 #91 修）。
  排程器方面：scheduler-library 過期的 snapshot 包裝可以改到共用的 snapshot，下一次刷新也不會察覺（#9，維護者 brejman 以 #19 修，我自己的 PR 隨之撤回）；KAI-Scheduler 檢查父子佇列配額時，把代表無上限的 -1 當成普通數字相加，一個無上限的子佇列反而把總和拉低、蓋掉真正的超額（#1881，我在審自己的 PR 時發現；eladb 以 #2167 修好，順帶修了同一區的另一則）。
  RocketPy 有 7 則，集中在 Monte Carlo 模擬與降落傘：降落傘的觸發條件每個時間點被評估兩次（#1086）；覆蓋率報告有六分之五被丟掉（#1088）；降落傘的氣壓雜訊不在 Monte Carlo 的亂數種子樹裡（#1091）；輸入與輸出檔不是原子寫入（#1110）；連初始條件這種非隨機的值也被抽樣（#1109，#1122）；每次模擬把飛行參數抽了三次，記錄下來的輸入與實際飛行對不上（#1090，#1126）。以上由 thatrandomasiandev 修好。另有降落傘拒收 numpy 整數的觸發值、卻接受浮點數（#1106，abhi-0203 修）。其中 #1086、#1091、#1106、#1110 的修正還在 develop 分支，維護者 11/2 把它們重新開啟，等 v1.14.0 發佈才關。
  其他：Kubernetes test-infra 的 Docker-in-Docker 讓 Go 看不到上層的 CPU 配額（#37727，stmcginnis 以 #37733 修）；kernel-module-management 在 DRA 或 device plugin 的 Module 加上或拿掉 spec.moduleLoader 之後，同一個 driver 會留下兩個 DaemonSet（#1330），TomerNewman 同意改成不能變更，NataliShemtov 以 #1368 修，10/28 合併；Zephyr 的 v3.7 維護分支少了 ESP32 Wi-Fi 掃描失敗後的修正（#110290，sylvioalves 以 #110387 回移）；四個 I2S 驅動把「永遠等待」的逾時（SYS_FOREVER_MS）換成不等待，佇列一滿或一空就立刻失敗（#116030，oliverhuahua 以 #120597 修，我審過）；spinifex 釘的 insomniacslk/dhcp 版本早於遠端 DoS 的修正（#803，維護者 juliansommer 修）；Claude Code 的互動模式在 kernel 4.18 上（例如 RHEL 8 節點的容器）一啟動就結束（#31522，Anthropic 在 2.1.76 修掉）；wshobson/agents 有 30 個 agent 名稱在不同 plugin 之間重複，一起安裝會互相覆蓋（#500，維護者以 #554 改名，並讓 CI 擋下重複）。還有一則不是程式：開源的台灣知識庫 frank890417/taiwan-md 有一篇把「921 若體制完善約 500 人本可救活」寫成台灣災難醫療制度的起源，我指出這是 AI 幻覺，500 這個數字來自阪神淡路大地震，催生的是日本的 DMAT（#1752）；維護者確認後改寫了整段。
• kubernetes/kubernetes — 私下回報給 Security Response Committee（2026-09-12，待回覆） 開啟 user namespaces 時，目錄服務一斷線，kubelet 就可能把 pod 對到錯的 host ID 範圍，而且幾乎不留痕跡。kubelet 會先查自己的帳號，再決定 pod 可以用的 ID 範圍。帳號放在 LDAP 或 sss 這類目錄服務、而 kubelet 啟動時目錄剛好連不上，查詢只會回「沒有這個帳號」，kubelet 就改用預設範圍，log 裡只有一行要開到最高詳細度才看得到的訊息。我用自製的 NSS 模組模擬目錄斷線，量了六種設定：1.33 到 1.37 在常見的設定下就會這樣，master 自 #135870 改用 getent 之後，每一種設定都會。後果是 pod 可能被對進目錄使用者常用的 UID 區間，目錄恢復後 kubelet 重啟時還會起不來。公開的 #141970、#141971、#142027 與 shadow#1738 都沒提到斷線這個情境，所以我私下回報，附上三個修法方向；回報裡也講明這是 fail-open 的行為，沒有示範實際的利用方式。
• open-telemetry/opentelemetry-cpp — Issue #4625 用 Bazel 建置 opentelemetry-cpp 的人，碰得到 CMake 安裝時刻意排除的六個內部標頭。CMake 只安裝四個公開標頭，Bazel 卻把整個目錄的十個都露出來，所以內部類別的記憶體配置對 Bazel 使用者等於公開介面，一改就會破壞相容性。要把 Bazel 收窄，還是把 CMake 放寬，該由維護者決定，我把兩條路的代價都寫清楚。這是我在評估自己的 #4618 算不算 ABI 變更時發現的，維護者已接受，標為 help wanted。ParthibanRajasekaran 的 #4634 選了收窄 Bazel，我審了幾輪，10/14 核准，等維護者合併。
• golang/go — Issue #81776 Go runtime 在 cgroup v1 上讀 CPU 限制時，第二個檔案打不開就會漏關第一個檔案描述子。我把那段函式抄進測試、換成真的開檔與關檔，每失敗一次就多一個沒關的描述子，補上關檔後歸零。回報裡我也把影響講小：runtime 只在啟動時開一次，最多留下一個描述子，而且在真實的核心上這兩個檔案會一起存在，很難踩到。我表示可以送修正，目前待處理。這是繼 #81180 之後，我給 Go runtime 的第二則回報。
• golang/go — Issue #81180 Go 依容器自動設定 GOMAXPROCS 時，只看行程所在的那一層 cgroup，上層有 CPU 限制就會設錯。父層限制兩顆 CPU、葉層沒有限制時，核心實際執行的是兩顆的限制，Go 卻設成 5；同一個行程放在父層，就正確得到 2。三個 Go 版本都重現，重現程式不依賴 Kubernetes。Go 團隊說明這是原始設計刻意的取捨：為了能定期更新而一直持有限制檔，不去走整條階層。我接受這個前提，並把我碰到的情境說清楚：Kubernetes CI 的 Prow runner 為了跑 Docker-in-Docker，自己把容器的 cgroup 再切一層。討論中。
• kubernetes/kubernetes — Issue #141624 Kubernetes 約十九個 node e2e 設定用一條寫錯的正規表示式挑 cgroup v2 映像，會連帶漏掉名稱正常的映像。那條式子本意是排除名稱以 -cgroupsv1 結尾的映像，實際上排除的是最後一個字元落在這幾個字母裡的所有名稱，例如以 ...v20260801 結尾的版本。我送了 #141626，加上一個專門用來排除的欄位，已合併。issue 還開著：只有 master 的 job 在讀的設定現在就能改，test-infra 一次改一個：#38098 和刪掉沒有 job 在讀的舊設定的 #38102 在 10/20 合併，#38100、#38101 在 10/21 合併，十九個設定檔現在剩九個還用原來的式子；release-1.34 到 1.37 的 job 也在讀的設定，要等那些分支的 runner 認得新欄位才能改。
• kubernetes/kubernetes — Issue #141725 CSI driver 只回報 kubelet 不認得的健康狀態時，磁碟區會被當成健康，先前記下的「無法存取」也被抹掉。kubelet 遇到不認得的狀態就略過，全部不認得時得到一份空清單，再拿這份空清單覆蓋原本的紀錄。我對 master 實測四種回覆列成表，證明這種情況和「沒有異常」分不出來；節點層級的儲存健康狀態也是同樣的寫法。社群的 Roaimkhan 以 #141743 接手修，我在上面要求修改，審查中。
• kubernetes/kubernetes — Issue #142439 開著 race detector 的 DRA CI job，在 kubelet 用的 cAdvisor 裡抓到資料競爭，連帶讓收尾的 log 檢查變紅。競爭發生在讀檔案系統統計的逾時處理，出現在我自己那支 #142411 的 presubmit 上。我追進相依套件，在 cAdvisor 開了 google/cadvisor#3937 並附上修正 #3938。這一則留在 Kubernetes 這側，記錄它怎麼讓 job 變紅，也說明讀統計為什麼會超過兩秒：同一段時間整個 job 都停頓了，那是 #142440。我自己接手追蹤。
• kubernetes/kubernetes — Issue #142440 DRA 的一支選擇性 presubmit 會整個停頓將近一分鐘，測試因為連不到 apiserver 而失敗。到 9/26 的兩週內，143 次有 19 次撞到。停頓期間節點的 log 最多晚 42 秒才進來、etcd 一次唯讀操作花了 16.9 秒、controller-manager 與 scheduler 掉了 lease 重啟，但 apiserver 與 etcd 都沒有重啟或 OOM。我對成因只提出一個明說是猜測的解釋：CPU 不夠。divyanshuprakas-h 以 test-infra#37924 把這支 job 的 CPU 從 2 提到 4，已合併；同一天我從 build cluster 公開的監控資料看逐容器的指標，指出瓶頸在記憶體，也更正了自己前一則留言算錯的地方。後續照 pohly 的提議，CPU 與記憶體各給半台機器，一台節點能同時跑兩支：divyanshuprakas-h 的 test-infra#37985 把 CPU 從 4 調回 3.5、記憶體從 12Gi 加到 13Gi，我審過，10/6 合併。定期執行的那支 job 下載預先建好的執行檔，race 偵測等於沒開；test-infra#37984 讓它也從原始碼建置，我審過，10/7 合併。最近兩週的 presubmit 與定期執行都沒再出現這個逾時，我 11/6 關閉。
• google/cadvisor — Issue #3937 cAdvisor 讀檔案系統統計時，逾時返回的路徑和背景的 goroutine 同時寫同一組變數，沒有同步。這是從 Kubernetes 的 DRA CI job 開著 race detector 跑 kubelet 追出來的，六天內出現八次。我送了修正 #3938：背景工作把結果寫在自己的變數裡再交回來，不再碰呼叫端的變數，審查中。Kubernetes 那側的記錄在 #142439。
• wmnsk/go-pfcp — Issue #145 5G 核心網路用的 PFCP 函式庫 go-pfcp，一批欄位解析器遇到過短或畸形的資料會 panic，有些在合法輸入上也會漏掉欄位。我對每一種欄位型別餵短的隨機資料、呼叫每一個讀取方法，再把建構函式產生的欄位送回解析器來回跑，逐一列出結果。最容易從網路上觸發的是 PFD Contents：一個能正常解析的 PFD 管理請求，讀它的內容時就會越界 panic；其他還有 Flow Information、Outer Header Creation 等。我送了修正 #146，審查中。
• cri-o/cri-o — Issue #10375 Pod 沙箱裡只要有一個建立了卻沒啟動的容器，CRI-O 停止沙箱時就要等滿逾時，每個沙箱 118 秒。停止時會對這個容器送出終止訊號，但裡面沒有程式能回應，CRI-O 只能等到逾時才強制結束。我用 crictl 三行指令重現：同一個沙箱在容器啟動過的情況下停止只要 0.13 秒，containerd 停一個只建立過的容器也只要 0.16 秒。這是從 Kubernetes CI 追回來的：#142404 記錄的那四次失敗，都是 kubelet 重啟時剛好碰上容器建立到一半，CRI-O 留下一個沒啟動的容器，之後停止沙箱就各花了 118 秒左右。cvas22 的 #10452 讓從沒啟動過的容器直接強制結束、不必等逾時，審查中。
• kubernetes/kubernetes — Issue #142262 Kubernetes 兩支 release-blocking 的 alpha 功能 e2e job，自 9/17 起常常在 120 分鐘的預算內跑不完。測試幾乎每次都全部通過，只是時間用完，master 上 61 次有 15 次逾時。我以 v1.38 Release Team Signal Shadow 的身分開單並負責追蹤。比對同一個 commit 上快慢兩次執行，差距幾乎全在 InPlacePodVerticalScaling 的測試：每次執行要 exec 進測試 pod 讀 cgroup 檔案一千多次，而 exec 的代價跟著 pod 的 CPU 上限走，測試給的上限很低，exec 起的 shell 每 100 毫秒只分到約 3 毫秒。那幾個測試的時間大多耗在這種讀法上。我提議過不經 exec 讀，或把三個檔案併成一次 exec；後者我送成 #142402，審查中。它只減少測試輔助函式的 exec 次數，不動 resize 的實作，我也還沒證明單靠它就能消除逾時；這個測試的其他失敗另外追。SIG Node 被要求先縮短這些測試的執行時間，延長逾時要等那之後再談。之後發現逾時集中在 Intel 的 worker：9/16 到 9/22，三台都是 Intel 的執行約一半逾時，三台都是 AMD 的一次也沒有。#142402 能省下每次執行四成多的 exec。這張單標為最高優先；SIG Node 的 kannon92 認為它不擋發版，但希望 1.38 正式發佈前修好。
• kubernetes/kubernetes — Issue #141829 → PR #141898 Kubernetes 的 DRA 排程遇到某個節點的資源池正在更新時，會讓整輪排程中斷；正確的處理是只把那個節點判為不適合。要求配置全部裝置的請求碰到正在更新或無效的資源池時，回傳的錯誤沒有標成「這個節點不行」，排程器於是當成整體失敗，停止檢查其他所有節點。divyanshuprakas-h 以 #141898 在三個 allocator 版本都補上標記與回歸測試，已合併。
• shadow-maint/shadow — Issue #1738 Linux 的 getsubids 在三種不同的情況下輸出完全一樣，呼叫它的程式分不出帳號不存在、帳號沒有設定範圍，還是設定檔讀不到。函式庫內部的狀態碼分得出這些情況，命令列工具卻從沒用上。kubelet 就是分不出來的那個呼叫端，所以只能先用 getent 查帳號。我在回報裡把相關的四則既有 issue 對上，並表示介面定下來之後可以送 patch 與測試；共同維護者很快回覆同意這個方向。
• nephio-project/nephio — Issue #1192 Nephio 的 GetClient 可能在 client 還沒初始化完成時，就把它交給呼叫端。檢查共用 client 是否存在和取得鎖之間有一段空窗，呼叫端可能拿到一個還沒初始化的 client。NopeCharon 送了修正 #1212，我已 approve。它的測試要開 -race 才抓得到這個競態，CI 卻沒有開（#1214）。
• nephio-project/nephio — Issue #1193 Nephio 建立 Gitea token 前檢查是否已存在時只看第一頁，帳號的 token 超過 30 個就會判斷錯。查詢沒有指定分頁，Gitea 只回第一頁、每頁 30 筆。我在 sandbox 用的 Gitea 1.19.3 上實測：帳號有 35 個 token 時只看得到 30 個，第 31 個以後一律被當成不存在。NopeCharon 送了修正 #1210，我已 approve。換到新版 Gitea 還有兩處會壞（#1213）：建立 token 必須指定 scope，而 scope 名稱在 1.20 改過；新版也把 page=0 當成第一頁，#1210 的修法在新版上仍只拿得到前 30 筆。
• RocketPy-Team/RocketPy — Issue #1186 RocketPy 的六自由度運動方程式裡，質心的力臂方向反了，側向力會讓火箭往錯的方向俯仰。推導以乾質心為原點，需要兩個從乾質心出發的向量，程式讀到的兩個函式依定義卻都是反方向，直接拿來用，力臂於是反號：施在乾質心的側向力，會讓火箭往物理上應有的反方向轉。我附了常質量、單一側向力的閉式重現。後來在唯一有實測資料的 Defiance 2024 飛行上，每一處修正都讓模擬的遠地點更接近實測值，但我也說明只有一次飛行，不能單獨當作證據。我送了修正 #1196，審查中。
• cert-manager/cert-manager — Issue #9327 cert-manager 在重用私鑰時，有一種失敗的憑證請求永遠不會被換掉，簽發一直失敗、重試次數一路往上加。這種請求標成失敗，卻沒有記錄失敗時間；負責換掉舊請求的檢查因此不會觸發，簽發那一側又要求一定要有失敗時間，兩邊的條件剛好錯開。回報當天，kokhlo 以 #9328 依這份報告提出修正，wallrj 核准後在 10/11 合併，會隨 v1.22.0 發佈。
• nephio-project/nephio — Issue #1186 Nephio 的 focom-operator 從 kubeconfig 取 token 時，一律拿檔案裡第一個使用者的，不看目前選用的 context。它自己手動解析 kubeconfig，所以檔案裡有多組憑證時，拿到的可能是別人的 token。NopeCharon 送了修正 #1211，改過一輪後我已 approve。
• nephio-project/nephio — Issue #1187 Nephio 的安全掃描在不同機器上可能跑出不同結果。Makefile 在有容器執行環境時跑容器裡最新版的 gosec，沒有時改跑本機安裝的那一版，同一份設定因此用到不同版本的掃描器。
• nephio-project/nephio — o2ims operator 與 controller-manager（#1174/#1177/#1178/#1179/#1180） Nephio 的 o2ims operator 出錯時會卡住或回報錯的狀態，對外的 REST API 也從沒真正啟動過。對外的 HTTP 呼叫都沒設逾時，設定失敗了還被報成「進行中」，要等 30 分鐘才逾時（#1174）；查詢佈建請求狀態時打錯了 endpoint，讀回的資料形狀對不上，單元測試的 mock 剛好把問題蓋掉（#1177）；北向 API 的執行緒建好了卻沒有真的啟動（#1179）。這三則我一起修在 #1197，目前是 draft、審查中。另外兩則：controller-manager 收了 --leader-elect 參數卻從沒套用，而 catalog 裡好幾個設定檔都帶著它（#1178，回報中）；我先前在 #1172 修好 Node 的 watch 之後，Endpoint 的 watch 還是舊寫法、也沒有測試（#1180，兩位社群貢獻者已認領）。
• kubernetes/kubernetes — Issue #141942 → kubernetes/test-infra PR #37840 Kubernetes 的 race 測試 job 並沒有替 kubelet 開 race 偵測。race 偵測需要 cgo，kubelet 改成靜態編譯之後，建置腳本就不再替它加上 race 參數。報告裡我逐一分出哪些 job 真的從原始碼建 kubelet、哪些只是下載現成的執行檔，後者加了名字也沒有作用。這則是從 #135870 的討論中拆出來的；dims 後來在 test-infra#37840 修好並關閉這則，我原本送的 test-infra#37842 就關掉了。
• kubernetes/kubernetes — Issue #141940 → PR #135870 kubelet 給使用者命名空間分配的 ID 區間，會因為它有沒有用 cgo 編譯而不同。kubelet 靠 Go 的 os/user 查自己的帳號來決定拿哪一段 subordinate ID，但這個套件在有沒有 cgo 時行為不一樣；查不到帳號時就直接退回內建的預設區間，沒有去查主機設定的 subordinate ID。同一台機器、同一份設定，就可能拿到不同的區間。dims 的 #135870 把 kubelet 改成不用 cgo 的靜態執行檔並合併後，這則以 completed 關閉。同一批回報的 #141941 還開著。
• kubernetes-sigs/kueue — Issue #14563 → PR #14822 Kueue 在 DeviceClass 變動時會重新排隊受影響的工作，但已經保留配額的那些永遠收不到通知。它只在還沒保留配額的工作裡找，已保留的剛好落在查詢範圍之外。維護者討論後認為，要撤回既有的保留，得知道 scheduler 當初是從哪個 DeviceClass 配出來的，而 controller 現在拿不到這個資訊，所以列為 KEP Beta 的後續工作。yindia 在 #14822 補上回歸測試，並把這個限制寫進 DRA KEP 的風險段落，這則 issue 隨之關閉。
• cncf/prow-github-actions — Issue #101 → PR #107 README 的範例要大家用 @v2，可是這個 repo 從來沒有 v2 這個 tag，照著複製的人裝不起來。mfahlandt 在 #107 把發布流程自動化，v2.0.0 從此存在，這則 issue 也隨之關閉。修正不是我送的。
• vllm-project/vllm — Issue #53887 → PR #54201 vLLM 載入 Qwen3.5 時會短暫多配置兩張完整的詞表，讓原本放得下的模型在 24 GiB 顯卡上記憶體不足。MTP 的草稿模型先各自建好兩張 vocab table，之後才改成和主模型共用，載入尖峰因此多出約 4.7 GiB，27B INT4 模型在 24 GiB 的卡上直接 OOM。我在 RTX 3090 上重現，追到是 embedding 與輸出層兩張表，也更正了初版報告只找到其中一張的錯誤。Chishenzheng 接手送出 #54201，載入尖峰從 25,826 MiB 降到 20,974 MiB，輸出結果不變；後來也有使用者在 RTX 5090 上重現。這支修正還在審查中。
• kubernetes-sigs/external-dns — Issue #6683 external-dns 在 Route 53 上改紀錄類型失敗時，會留下一筆孤立的 TXT 紀錄，之後永遠同步不回來。在 upsert-only 模式下，它先送出標示所有權的 TXT，下一批才送真正的 A/AAAA 紀錄；舊的 CNAME 沒刪掉讓第二批被拒，第一批卻已經生效，於是每一次同步都卡在同一個狀態。#6640 的完整同步迴圈測試能走到這個狀態，但刻意沒把這個錯誤的行為寫成正確結果。amarkdotdev 的 #6688 寫了要修這個問題，我實測後指出它刪掉的不只是孤立的 TXT；改了幾版之後，審查者 u-kai 在 10/3 指出現在的 diff 已經修不到 #6683；amarkdotdev 11/3 改送只加一則警告的 #6915，issue 仍開著。
• zephyrproject-rtos/zephyr — Issue #114739 NXP 的 LCD 控制器驅動在 MIPI DBI Type A（6800）模式下永遠找不到輸出格式。查表時拿錯了常數當鍵值，所以任何 Type A 模式都對不到。NXP 的維護者在 #115197 修好，這則以 completed 關閉。
• kubernetes-sigs/kueue — Issue #13933 Kueue 的外部整合指南給錯了記錄事件所需的權限。指南給的是 core/v1 Event 的 RBAC，程式實際卻透過 events.k8s.io 記事件，照指南設定的自訂整合會因權限對不上而記不了事件。社群的 #14021 修正了文件。
• kubernetes-sigs/kueue — Issue #13987 KEP-2941 說 DeviceClass 的對應必須唯一、放寬是未來的工作，但程式早就放寬了。文件和實作不一致，會誤導讀者。後來社群的 #13993 把文件改成和程式一致。
• kubernetes-sigs/cluster-autoscaler — Issue #37 cluster-autoscaler 的 DRA 快照直接共用 informer 快取裡的物件，改快照就等於改快取。建立快照時沒有複製 ResourceClaim，最底層的快照又被當成可以直接修改，所以模擬排程時做的任何更動，都會寫進其他元件共用的快取，影響之後的處理。magic-peach 在 #104 改成先複製再放進快照；我從另一側送的 #124 修的是同一件事，就自行關掉讓路，改在 #104 上補實測：main 上跑完一輪，informer 裡的 claim 多了一筆保留，#104 上則是空的。同一個 repo 我回報的 #33（Pod 兩次引用同一個 ResourceClaim 時，還原會漏掉一筆更動）由 magic-peach 在 #105 修，我在上面驗過三條路徑，main 上都會漏、那支 PR 上都正常。後來維護者依 sig-autoscaling 的討論，一次關掉了包括這兩支在內的五支 PR；Choraden 另外送的 #254（#37）與 #255（#33）在 11/9 合併，兩則 issue 都已關閉。
• kubernetes-sigs/karpenter — Issue #3221 Karpenter 把只取得管理存取權的 DRA 配置也算成裝置被佔用，可能誤判節點已滿。admin-access 的配置依 API 定義只授權存取、不保留也不耗用裝置，但 Karpenter 計算裝置佔用時從沒讀這個欄位，把它當成一般配置累加，因此高估佔用量，進而做出錯誤的新增或合併節點決定。回報中，尚待維護者分類。
• kubernetes-sigs/kueue — Issue #13820/#13866/#17122 Kueue 更新工作的優先權時，同一次處理裡可能替同一個優先權類別寫進不同的值。每個 Workload 都各自去讀一次 WorkloadPriorityClass，沒有共用結果；LeaderWorkerSet 會把更新分給多個 goroutine 同時做，類別的值若剛好在中途改了，各個元件就被寫成不同的值（#13780 加入的擴容路徑也一樣）。而且不會自己恢復，要等這個類別下一次改值才會被拉回一致。我送的 #13904 和 sohankunkerkar 討論後縮小範圍：只改更新路徑，把 LeaderWorkerSet 的所有元件一次交給同一個呼叫，類別只解析一次，11/4 合併；建立元件的路徑沒動，#13820 為了這另一半繼續開著。另一則 #13866：類別的值在任何 Workload 引用它之前就改了，那次更新會被吃掉，之後引用它的 Workload 帶著舊值進來，因為 controller 不監看 Workload，就一直停在過時的優先權。我送的 #13920 加上對 Workload 的監看，為了不超過 Kueue 對開著 PR 數量的上限，10/11 先關掉；10/13 改送 #17100，Workload 開始引用類別時，只替那一個 Workload 補寫類別的值，審查中。第三則 #17122：一次批次寫入途中類別的值改了，同一類別、引用沒變的 Workload 會停在舊值，沒有東西再觸發修正。trukhinyuri 的 #17160 照 issue 裡建議的做法，在寫完之後重讀類別，審查中。
• open-telemetry/opentelemetry-cpp — Issue #4339 OpenTelemetry C++ 的 OTLP exporter 還有請求沒送完時，ForceFlush 就可能回報成功。等待迴圈只要被任何一個完成通知喚醒就跳出，不管其他請求是否還在途；等待的時間也以 exporter 自己的逾時為準，不理會呼叫端給的截止時間。我送的 #4357 已合併：改成依未完成的請求數決定要不要繼續等，並以呼叫端剩下的時間為上限。這只修了一部分，issue #4339 還沒關（見 Ledger）。
• open-telemetry/opentelemetry-cpp — Issue #4360 OpenTelemetry C++ 的 curl HTTP client 曾在回報失敗之後仍把請求送出去，也會對同一次請求通知兩次結果。每個 HTTP exporter 都用這支 client。issue 現在列了四處，兩處由我修好並合併（見 Ledger）：#4363 讓收到回應後才取消的請求只回報回應，不再同時通知「已取消」；#4457 讓壓縮失敗的請求停下，不再把寫壞的內容送出去。還開著的兩處都是一個結果通知兩次：一次設定失敗會發出兩種失敗事件，一次取消會通知兩次「已取消」。我提議的規則是每次請求恰好只有一個最終結果。
• apache/airflow — Issue #71748 Airflow 的 KubernetesPodOperator 重新接上 Pod 時只檢查一次身分，之後可能操作到另一個同名的 Pod。Pod 的 uid 只在讀回狀態時比對一次，之後都只靠名稱與 namespace；原本的 Pod 消失、同名的新 Pod 頂上時，後續的操作就會打到錯的 Pod。這是 #71743 的延續，相關的還有 #71744。bnspopi 10/13 開的 #74655 處理刪除的那一半：刪除時帶上先前記下的 uid 當前提條件，審查中；後續輪詢那一半還沒有人做。
• kubernetes-sigs/scheduler-library — 可變快照一致性稽核（#6/#7/#8/#9/#12） scheduler-library 的可修改叢集快照，在新增、移除與還原時會弄髒共用的資料，還原失敗也照樣回報成功。這串共五則：還原時把錯誤吞掉卻照常繼續（#12）；rollback 與 Unpreempt 回報成功卻沒有真的還原（#7）；新增與移除後會留下整份快照共用的 affinity（#8）；過時的快照包裝仍能寫進共用的儲存（#9）；改用上游 framework 的建構方式會改變語意（#6）。#9 已由維護者 brejman 在 #19 修好並關閉，#7 的修正 #10 審查中，其餘三則仍開。
• koordinator-sh/koordinator — reservation controller 稽核（#3145/#3148/#3149/#3151/#3152/#3154/#3155/#3157/#3158/#3199） Koordinator 的資源預留（Reservation）在建立、取代與結束的過程中，有一整串狀態對不上的問題。已經在結束或被取代的預留，仍可能被排程並標成可用（#3154）；同名的替代者會認到舊的工作佇列鍵（#3157），並把舊的預留 Pod 留在排程佇列裡（#3152）；預留 Pod 的排程結果沒有帶版本，過時的節點決定會被記到新的身分底下（#3158）。另外幾則是時序與註冊的問題：controller 在 Pod 索引更新之前就先動作（#3151），plugin 的快取更新和依賴它的喚醒之間沒有先後保證（#3148），重新同步無法停用（#3149），漏註冊了部分事件的排程提示（#3145）；限定資源種類的預留擴大追蹤範圍之後，先前被遮掉的用量補不回來，用量因此少報（#3155）。這些都還在回報中；其中 #3157 有 yuvc21 的 #3234 在修，#3155 有 weiDaXinXin 10/21 送的 #3244，都在審查中。另有 #2927 審查中留下的一則後續：elasticquota 分不出解碼失敗與一般的新增（#3199），不影響排程結果，已由 QIW9 認領，修正 #3227 審查中。
• zephyrproject-rtos/zephyr — i2s/mipi_dbi/dma 驅動稽核（#113310/#113333/#114739/#114741/#115250/#115251/#115499/#115502/#115503/#115504/#115505） Zephyr 幾個驅動在歸還資源與設定上的一串問題，大多已經修好。ESP32 的 I2S 與 DMA：每次 DROP 都會漏掉一塊緩衝區，之後的寫入會永遠卡住（#113310）；同時收發時一邊出錯，另一邊仍繼續跑（#115499）；DMA 檢查描述子用完時讀到陣列外一格，重新載入時還寫進那一格（#115502）；停止時多跑了一段，同一方向被停兩次（#115503）；傳送啟動失敗會弄丟已經取出的緩衝區（#115504）；延遲傳送的計時器從不取消（#115505）。後四則我自己修好並合併（#115507、#115523、#115725，見上方 B 組）。I2S 的共用 API 文件說緩衝區不夠時會回錯誤，實際卻無限期等待、無法中斷（#113333），由我的 #115727 修好，也在 B 組。MIPI DBI：片選的判斷和取腳位的範圍不一致（#115251），API 測試因為標籤打錯而被濾掉（#114741），這兩則我也自己修好（#115254、#115831，同在 B 組）；NXP LCD 控制器的 Type A 模式找不到輸出格式（#114739），由 NXP 的維護者在 #115197 修好。另外，合規檢查沒有檢查公開標頭裡的 designated initializer 是否照 C++ 的宣告順序（#115250）。#115499 由 harshitnub077 的 #117645 修好（我審過那支）。#113310、#115250 仍開：#113310 有 wmrsouza 的 #123325 在修，審查中；#115250 其中一處由 ashutoshpandey-eaton 的 #119655 修好。
• kubernetes/kubernetes — DRA allocator 稽核額外七則（#140424/#140468/#140799/#141103/#141117/#141214/#141216） Kubernetes 核心 DRA allocator 的第二批正確性問題，接在 v1.37 已合併的五個修正之後。裝置請求的數量沒有上限與溢位保護（#140424）：它和 #141323 重疊，相關修正與回移落地之後我自行關閉。計算節點的可配置需求之前，沒有擋掉負的已耗用容量（#140468），KrishnaParihar1 的 #140563 被 pohly 關閉，改採 kvalliyurnatt 已合併的 #143287；allocator 這側由我的 #140442 涵蓋，我 11/6 關閉。關掉 allowMultipleAllocations 之後，仍保留建立時會被拒絕的容量設定（#140799）：krishhna24 的 #141644 讓裝置清單一變動就整份重新驗證，我原本的修法因此撤回，改補上更新路徑的測試（#142536，已合併），這則隨之關閉。擴充資源的對照快取可能過時，對照碰撞時會丟掉正確的那一筆（#141103）：anshulchikhale30-p 在 #141110 修好。ResourceSlice 數量不一致時，pool 是否完整的判斷會受順序影響（#141117）：我提的檢查經維護者兩輪討論後沒有收，結論是 driver 有責任發布正確的資料，程式改成用註解標明「不檢查」，這則我以 not planned 關閉。節點條件格式錯誤時應該只讓那個節點失敗（#141214）：維護者認為沒有 driver 發布過這種資料，1.38 起驗證也會擋下，我同意不改 allocator、自行關閉；驗證的那一半由 #141213 修好，2026-10-02 合併。裝置消耗的計數可以是負值，扣除時反而墊高可用量，造成共用的計數被超額配置（#141216），仍開，piyushrajyadav 的 #141705 讓驗證和 allocator 都拒絕負值，審查中。
• kubernetes-sigs/dra-driver-nvidia-gpu — compute-domain 稽核（#1347/#1348/#1349/#1350/#1351） NVIDIA GPU 的 DRA driver 處理 ComputeDomain 設定時，有幾處驗證與錯誤處理的缺口。打錯字或大小寫不對的配置模式會被默默當成預設值（#1347）；還沒確認 ComputeDomain 存在，就先建目錄、寫設定檔（#1348）；admission webhook 從沒驗過 ComputeDomain 的兩種設定，和 kubelet plugin 的驗證不一致，不過這個 webhook 預設是關的（#1349）；多份設定的套用順序取決於 Go map 的迭代順序，失敗時留下的副作用也跟著不固定（#1350）；幾種重試也不可能成功的輸入錯誤沒有標成永久錯誤，會一直重試到期限用完（#1351）。這五則是我在做 #1346 時找到的，NVIDIA 的維護者把五則都指派給我修。shivamerla 為了趕 v0.5.0，把 #1346 的一部分拿進他 8/19 合併的 #1368，#1349 因此已經修好，我 10/28 核對後關閉；#1346 現在也修 #1351，審查中；#1347 交給想接手的 khs-alt，他 10/29 送了 #1600；#1348 與 #1350 還沒有 PR。
• containernetworking/plugins — host-local 稽核（#1294/#1295/#1296） CNI 的 host-local 位址分配還有三個設定檢查的缺口，是我修 #1292 時記下的。#1292 本身由我的 #1293 修好，在上面的 B 組。明確指定的 gateway 沒檢查是否同一位址族、是否在子網路內（#1294），bodapatisaikrishna 的 #1303 補上這兩項檢查，10/14 合併；範圍明確設在 IPv4 的網路位址或廣播位址時仍會被分配出去（#1295），改了會影響既有的設定，留給維護者決定；另一則是防禦性的補強：NextIP 越過位址族的尾端時回傳 nil，RangeIter.Next 沒有檢查（#1296），ravi-arnan 10/28 送了 #1316，審查中。
• karmada-io/karmada — scheduler 與 estimator 兩則（#7818/#7819） Karmada 把還在途中的工作算進去之後，估出來的可用副本數反而變多。計算「每個副本的用量乘以副本數」時用的是會溢位的一般整數乘法，請求夠大就變成負數，從可配置量減掉負數等於加上去（#7818，附重現測試）；Vasudev2401 在 #7820 提出修正，審查中。另一則是 scheduler 關閉時不等正在跑的那一輪結束，關閉之後仍可能寫入排程結果（#7819）：已有人在 master 上重現，也指出我附的重現程式要先關掉現在預設開啟的優先權排程才跑得起來，最後一個斷言在任何正確的修法下也過不了；mishradwaterlaw 表示要接手修。
• kubevirt、external-secrets、volcano — 三則單獨回報（#18543/#6876/#5844） 三則各自獨立的回報，目前都還開著。KubeVirt：同一台虛擬機同時用 device plugin 與 DRA 分到 mdev 時，兩邊各開一個預設的 ramfb，會出現兩個顯示裝置（#18543）；驗證那一半我已經在 #18542 修好，產生設定的那一半由 Pcmhacker-piro 認領，修正 #19106 審查中。External Secrets：從 Infisical 遞迴讀取時，同一個子樹裡同名的密鑰會互相覆蓋；預設設定下 12 次同步都留下子目錄那一個，開了 #6349 提議的 SkipUniqueValidation 之後，12 次裡有 2 次換成另一個（#6876，附 Infisical v0.158.0 的實測）；mathnogueira 的 #6908 已合併，加上可選的 includeSecretPath。Volcano：佇列容量把某些資源設得很大來表示「不限」時，換算會溢位，那個維度的容量變成 0，什麼都排不進去（#5844）；這是從原始碼追出、用 scheduler 的資源 API 重現的，沒有在叢集上實測；khanskr 的 #5845 在修，審查中。
• 修了一部分、issue 還開著（opentelemetry-cpp #4287、kueue #13842） 兩則都修了一部分，issue 還開著。OpenTelemetry C++ 內建 HTTP server 的稽核總追蹤（#4287）：記憶體安全的三則我在 #4289、#4292 修好（見上方 B 組），Windows 的編譯問題由 owent 移除整個標頭解決；維護者說明這兩個檔只給測試與一個範例用之後，其餘的強化項目我就撤回了，把安裝的標頭改成明列清單的 #4327 已合併，issue 留給維護者關。Kueue 的 DRA 配額沒有綁到實際產生 ResourceClaim 的那份設定，刪掉範本再用同名重建就能少算配額（#13842），這是 KEP-2941 留下的後續，我已認領。
• ocudu/ocudu — #689/#690（GitLab） OCUDU 的 DU 遠端指令，驗證時接受的內容和實際能套用的不一致。系統資訊（SIB3、SIB4）的鄰區清單在解析時不檢查長度，編碼器卻有上限，超長的清單會先通過驗證、寫進正在廣播的系統資訊並更新版本號，到編碼時才失敗；而那個失敗檢查在 Release 版會被編譯掉，等於把壞掉的狀態提交出去（#689）。另一則是無線資源政策的指令接受並儲存了專用比例，套用時卻只處理最小與最大比例，只設專用比例的請求被接受卻默默不生效（#690）。#689 已由維護者 Mateusz Michalski 在 !1259 修好並關閉，#690 仍在回報中。
• OpenAirInterface 5G — Issue #1035 在 EURECOM 的 GitLab 上，對 5G 核心網路開源實作送出的 bug 回報。

D · 他人回報、由我修復並合併（71 則）

這一組的 issue 是別人開的：有人遇到問題或提出需求，我送出修正並合併，issue 跟著關閉。和上面 B 組的差別只在誰先發現問題。71 則分布在 38 個 repo，來自 49 個回報帳號（其中一個是 coderabbit 機器人），不少是該專案的維護者。

• OpenTelemetry 家族 · 14 則：opentelemetry-cpp 九則：一個不穩定的測試（#4265）、TSAN 在取消路徑抓到的競態（#4369）、LogRecord 數量上限的實作（#4126），以及三則 clang-tidy 清理（#4198、#3979、#3980）；另有設定檔的 resource detector（#3916），以及 delta 計時的起點用了整個 MeterProvider 的啟動時間、應該用每個 instrument 自己的（#4062）。cpp 的最後一則（#4614）是 TSAN 在重試整合測試抓到的競態，貼出的人問是不是已知的那條，我查出是新的一條，用 #4618 修掉，已合併。其餘分散在 Android SDK 的磁碟緩衝匯出週期要能設定（#1823）、Collector 設定檔裡的顯示名稱（#14114）、collector-contrib 的 native histogram 沒檢查攻擊者可控的 offset（#50286）與 PostgreSQL receiver 文件裡無效的設定範例（#42838），以及 Helm chart 要跟上 operator 的可用版本（#2248）。
• llm-d-router · 6 則：專案要每個 plugin 都能把內部狀態傾印出來，方便觀察與除錯，這六個 plugin 由我實作：file-discovery（#1776）、no-hit-lru-scorer（#1790）、mm-embeddings-cache-producer（#1789）、approx-prefix-cache-producer（#1801）、program-aware-fairness（#1798）、precise-prefix-cache-producer（#1794）。
• Kueue · 9 則：DRA reconcile 的錯誤要分成暫時性與確定性兩種（#11994）；一則從 2024 年就開著，找不到 WorkloadPriorityClass 時要發出事件（#3439，主線與回移各一支 PR）；reserved pods 的名稱驗證在 0.18 與 0.19 要用 feature gate 擋住（#14763）；以及 #13601 審查時開出的一則（#16301）：KEP 裡備選裝置的路徑少寫了一層 spec，firstAvailable 配額設計的作者名單也漏了一位，由 #16313 修掉。mimowo 審我的 #15026 時，把其中兩個 fair sharing share 的修正拆到另一則（#16477）並指派給我：很大的 share 換成 int64 會溢位，在 amd64 上變成負數；權重為 0、正在借用的 ClusterQueue 或 Cohort 拿到的 share 是 0 而不是 +Inf。我以 #16487 與 #16488 各修一種，10/2 合併，10/28 確認都修好後關閉。sohankunkerkar 開的 #16322 是另一類：Workload 會從 Job 或 Pod 抄來 Kueue 自己用來控管的 label 與 annotation。我照 sohankunkerkar 的建議拆成兩支，#14227 不再複製這些 key，#16779 讓 Kueue 啟動時把設定裡寫到的這類 key 記進 log。維護者 mimowo 回報 cherry-pick 腳本在輸入 y 之後中止（#17597）。我重現出原因：衝突的解法先在另一個視窗 commit 了，腳本就找不到要提交的變更，實際執行時還會刪掉帶著那個 commit 的分支。#17607 讓腳本把 HEAD 退回 pick 之前再重新提交，回報當天合併。mimowo 把一個 integration test 的 flake（#17796，coderabbit 開的）丟出來請大家看，我從失敗的紀錄查出原因：scheduler 在 admission 寫回之後又把 Workload 的標籤值存一次，中間發生的刪除或改標籤就被蓋掉。mimowo 請我和 #14577 的作者 Sidd-Prabhu 從那支 PR 拆出這一段，我送出 #17856，改成從已 admit 的 Workload 推導這些值、不再存回，10/28 合併。mimowo 審我的 #14414 時，請 coderabbit 開了一則後續（#17998）：provisioning controller 的測試用 struct literal 建 ProvisioningRequest，再複製一份改名稱與 PodSet。我送出 #18006，加上 ProvisioningRequestWrapper 改用它來建，10/30 合併，同日回移到 0.20 與 0.19。
• jaeger-ui · 5 則：plexus 繪圖層的元件要改寫成 function component，其中五個由我完成：MeasurableNode（#3389）、NodesLayer（#3394）、SvgLayer（#3399）、SvgLayersGroup（#3400）、SvgEdgesLayer（#3398）。
• Porch 與 Nephio catalog · 5 則：Porch 四則由我分三支 PR 解決：#375 留下的收尾工作（#765）由 #398 處理，資料庫快取處理不了二進位檔（#780）由 #437 修好，porchctl 的 namespace 參數沒給值時不報錯（#870）與 rpkg 各指令之間重複的程式碼（#900）一起由 #541 解決。另一則開在 Nephio 主 repo，要 catalog 改用 kptdev 版本的 kpt（nephio#984），由我在 catalog 的修正關閉。
• 其餘 32 則：會讓程式當掉或結果出錯的有十一則。cert-manager 遇到帶失敗時間的憑證請求會因空指標而當掉（#9119），產生的 CSR 也可能不是用指定的私鑰簽的（#6331）；Argo Workflows 封存工作流程時把同一個步驟做了兩次（#16575）；OpenTofu 遇到無效的 removed.from 會當掉（#4319）；kube-vip 的 control plane VIP 拿不到 DHCP 位址（#844）；OpenChoreo 遇到暫時性錯誤時默默跳過 observability release（#2764）；external-secrets 忽略 Infisical 的路徑設定（#6685）；Kubernetes 的錯誤訊息用錯 log 層級（#136027）；minikube 沒有容器時 minikube status 仍回報成功（#22466）；Harbor 改了管理員密碼的參數後起不來（#22704）；prow-github-actions 幾個標籤一起用時報錯（#81）。其餘是功能與維護工作：Envoy 把 TLS 對端憑證的驗證狀態帶進 CEL（#45660）、kube-vip 收到訊號時傾印設定（#1301）、Kubeflow Pipelines 的 driver 可以指定 label 與 annotation（#12015）、minikube 的 containerd preload 測試（#23035）、KubeStellar 拿掉 controller 多餘的權限規則（#3475）、KEDA 的 Artemis scaler 支援 TLS（#6448）、Cortex 的測試在 arm64 上跑（#6897）、Perses 的 Y 軸支援奈秒與微秒（#3526）、score-spec 的 Pub/Sub 模擬器 provisioner（#53）、DRANET 網站加上範例（#204）、prow-github-actions 的另一則（#78）、rawtoaces 色溫 Kelvin 與 mired 的雙向換算（#273）、QGIS 從 2021 年開著的一則，qgis_process 要能指定 profile（#44783）、Zephyr 的 mipi-dbi binding 加上色彩格式（#98657）、RocketPy 的 CHANGELOG 自動化（#905）、ASWF dna 的逐字稿發佈流程（#120），以及 kagent 1.x 文件缺了 structured output 這一頁（#518，我的 #545 合併後關閉）。最後四則是文件與網站：Meshery（#17135）、Microcks（#550）、Keycloak（#43818）、kubernetes/website（#53090）。

E · 上游 PR 審查 — 審他人的貢獻（152 筆）

• kubernetes/kubernetes · 41 筆：DRA kubelet/scheduler、TAS placement、CompositePodGroup 的節點提名、scheduler 計分溢位、kubelet QoS 加總的溢位、LimitRanger ratcheting、Quantity 行為釘測、volume recycler 逾時上限、資源換算的精度與除以零、exec/attach 串流關閉的時序、kube-up 建立 GCE 網路的重試、e2e 對 OpenAPI 請求的重試與逾時、kubectl test-cmd 的 CRD 測試競態、DRA E2E 停測 v1beta1、ResourceClaim 只改 metadata 時不再撞上不可變檢查等
• kubernetes-sigs/kueue · 37 筆：DRA extended-resource、workload priority、scheduler snapshot、request 超過 int64 的精確計算、fair sharing 的指標、PodSet overhead 的驗證、LeaderWorkerSet 的 queue 變更、佇列指標的保留、ProvisioningRequest 的 PodSet 合併、HoldAndDrain 的驅逐、負的 request 在配額裡當成零、label 與停止策略同時變更時的 LocalQueue 指標、DRA 重新排隊時保留 request 總量、PodSet 自帶 overhead 時少算 RuntimeClass 的 overhead、RuntimeClass 事件不再觸發無關 Workload 的 reconcile、刪除 ClusterQueue 時清掉 MultiKueue 的計數、暫停 LocalQueue 時保留計數器、template 合併衝突時保留執行中的 PodSet、Workload 的 queue 與優先權一起更新、帶舊負值 request 的 Workload 更新
• zephyrproject-rtos/zephyr · 31 筆：以 M5Stack Platforms Maintainer 身分審 M5Stack/ESP32 硬體支援與顯示驅動 PR、含 backport；也審 i2s 驅動的修正，例如 oliverhuahua 修自報 #116030 的 #120597，以及 CI 的 compliance 檢查腳本與測試、範例的篩選條件
• shovel-heroes-org/shovel-heroes · 8 筆：鏟子英雄，花蓮救災的民間協作平台（131 stars、本人為第三大貢獻者），審後端 API、資料模型與部署流程的 PR
• 其餘 35 筆散落 nephio、nephio test-infra、ROCm/k8s-gpu-dra-driver、RocketPy、cluster-autoscaler、dra-example-driver、dra-driver-nvidia-gpu、kubernetes/autoscaler、kubernetes/test-infra、kubeadm、volcano、kubevirt、controller-runtime、argo-workflows、argo-cd、intel-resource-drivers、prow 與 opentelemetry-cpp

查看完整 GitHub profile