linux-cachyos

@dr_sensor Just pushed a commit today to fix this. The default kernel with 7.3.2 will include rust now! :) See: linux-cachyos#1123

CachyOS Linux Kernels: Enhanced Linux kernels with improved performance and multiple CPU schedulers (4.7k stars) What it does All text below is quoted directly from the project README. >Archlinux Kernel based on different schedulers and some other performance improvements. CPU Enhancements: - Multiple Schedulers: BORE, EEVDF, and BMQ schedulers for different workload optimization - POC Selector v2.6.3: Piece-Of-Cake fast idle CPU selector inspired by scx_cake, reducing wakeup latency - Cluster-Aware Scheduling: Improved load balancing for CPU clusters, including balancing between CPUs of identical capacity on hybrid architectures - CachyOS Sauce: Custom CONFIG_CACHY configuration with scheduler and system tweaks - AMD P-State Enhancements: Preferred Core support and latest amd-pstate improvements from linux-next - Real-Time Support: RT kernel builds available with BORE scheduler integration - Low-Latency Optimizations: Patches for improved responsiveness and reduced jitter >All CachyOS kernels are available in multiple architecture optimizations: x86-64, x86-64-v3, x86-64-v4, and znver4. Repository CachyOS/linux-cachyos Repository stats |Metric|Value| |:-|:-| |Stars|4,720| |Forks|174| |Last release|6.17.9 (2025-12-01)| |Languages|Shell 100%| |Contributors|30| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|None| |AI co-authored commits|None| Main contributor |Field|Value| |:-|:-| |Name|Peter Jung| |GitHub|@ptr1337| |Commits to this repo|1,175 (top contributor)| |Bio|Founder and Developer of @CachyOS, @archlinux Package Maintainer| |Company / Location|Germany| |Followers|1.2k| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.

Something to watch if you are on Linux linux-cachyos#1084

CachyOS is adding a dedicated EACv2-compatible kernel (`linux-cachyos-eac`) plus a Secure Boot setup guide so users can optionally meet Epic’s new Easy Anti-Cheat Linux v2 requirements without changing their normal optimized kernel.

CachyOS is adding a dedicated EACv2-compatible kernel (`linux-cachyos-eac`) plus a Secure Boot setup guide so users can optionally meet Epic’s new Easy Anti-Cheat Linux v2 requirements without changing their normal optimized kernel.

CachyOS is adding a dedicated EACv2-compatible kernel (`linux-cachyos-eac`) plus a Secure Boot setup guide so users can optionally meet Epic’s new Easy Anti-Cheat Linux v2 requirements without changing their normal optimized kernel.

Epic's own post is here: onlineservices.epicgames.com — read the FAQ line about not loading a kernel module first, because every other requirement on the list follows from having to prove integrity without one. The CachyOS flavour is PR #1084: linux-cachyos#1084

CachyOS is adding a dedicated EACv2-compatible kernel (`linux-cachyos-eac`) plus a Secure Boot setup guide so users can optionally meet Epic’s new Easy Anti-Cheat Linux v2 requirements without changing their normal optimized kernel. linux-cachyos#1084

RX 7800 XTのKernel Oopsを報告したら、既知のTTMバグと一致していた話 CachyOSでメモリ不足が起きた直後、Radeon RX 7800 XTを使うPCのカーネルがttm_resource_add_bulk_move()でOopsを起こし、その後のハング・リセットにつながりました。 調べたところ、GPUメモリ管理のTTMに関する既知の不具合とクラッシュの特徴が一致していました。CachyOSのIssue #1058とLinux DRMの開発メーリングリストにログと調査結果を送り、開発者からも一致するとの返信をもらいました。 この件は自分がカーネルの修正パッチを作った話ではありません。既存の問題について、ハイバネーションとは違う発生条件を報告し、ソースとインストール済みモジュールを調べ、修正の取り込み方まで追った記録です。 OOMの直後に、GPUメモリ管理でOopsが起きた 最初に問題が起きたのは2026年9月です。環境は次のとおりでした。 項目 クラッシュ発生時の環境 GPU Radeon RX 7800 XT（Navi32） OS CachyOS Linuxカーネル 7.2.4-1-cachyos Mesa 26.2.2-2 libdrm 2.4.134-1.1 公開した不具合報告には、次のログが残っています（抜粋・省略あり）。 kswapd0 invoked oom-killer Out of memory: Killed process <redacted> amdgpu ... Not enough memory for command submission! WARNING: ... ttm_resource_add_bulk_move ... BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: ttm_resource_add_bulk_move+0xc9/0x150 [ttm] OOM Killerが動いたあとにAMDGPUのメモリ不足エラー、TTMの警告、NULLポインタ参照が続いていました。さらにRCU stallが発生し、最終的にホストをリセットしています。 ただし、これはKernel Oopsとして記録されたもので、ログにKernel panic - not syncingはありません。「Kernel panicが起きた」と断定しないよう、報告でも区別しました。 スタックトレースはswapoutを指していた クラッシュ時の呼び出し履歴には、次の経路が含まれていました。読みやすいよう、下から上へ、呼び出し元から先の順に並べています。 amdgpu_gem_fault → ttm_bo_vm_fault_reserved → ttm_bo_populate → ttm_tt_populate → ttm_global_swapout → ttm_bo_swapout → ttm_lru_walk_for_evict → ttm_bo_swapout_cb → ttm_resource_alloc → ttm_resource_add_bulk_move ← Oops この経路が手掛かりになりました。メモリを退避させるswapoutの途中で、バッファオブジェクト（BO）の管理情報を更新するときに落ちています。 そこで、以前から報告されていたDRM/AMDのIssue #5387と、関連するLinuxカーネルのコミットを確認しました。 戻り値の条件を読むと、後始末が飛ばされていた TTMでは、GPUバッファオブジェクトなどのメモリ配置を管理しています。その一部で使うbulk_moveには、複数リソースをまとめてLRU上で扱うための範囲情報があります。 問題になっていたttm_bo_swapout_cb()では、次のような条件でその範囲を更新していました。 ret = ttm_tt_swapout(bdev, tt, swapout_walk->gfp_flags); if (!ret) { ttm_resource_del_bulk_move_unevictable(bo->resource, bo); ttm_resource_move_to_lru_tail(bo->resource); } ここでttm_tt_swapout()は、成功すると退避したページ数を返します。ページを持っているTTMなら、正常なswapoutの結果は正の値です。 それなのに条件はif (!ret)。成功して正の値が返った場合、bulk_moveからの除外処理が実行されません。 そのまま別の経路でリソースが解放されると、bulk_moveが持つ範囲の端点が解放済みのリソースを指すことがあります。古い端点をたどった先でuse-after-freeが起きる、という仕組みです。 修正に必要なのは、swapoutが成功したときに後始末をする条件です。 - if (!ret) { - if (ret > 0) { 今回のクラッシュで、古い端点がどのように参照されたのかは、後述する開発者の返信で詳しく確認できました。 修正コミットを読んで、少しややこしいことが分かった 調査時点で関連するコミットは2つありました。 3db7d7d fcfe647 最初のコミットは、本来ttm_tt_swapout()の後ろにある条件を変えるはずが、別の関数ttm_bo_alloc_at_place()のttm_resource_try_charge()の後ろにある条件を変更していました。後続のfcfe647で、誤った変更を戻すとともに、本来のswapout側をif (ret > 0)に直しています。 つまり、最初のコミットだけを取り込んだツリーには、このswapoutバグの修正が入っていません。 そこで、自分の環境も確認しました。CachyOS 7.2.4-1のソースには古いif (!ret)が残り、インストール済みttm.koを逆アセンブルしても、ゼロとの比較を示すtest eax,eax / jneという分岐でした。後に調べた7.2.6、7.2.7のソースにも古い条件が残っていました。 単にコミット番号を探すだけでなく、いま動いているバイナリで、実際にどちらの条件が実行されるのかを確かめた部分です。ソースとバイナリを調べた結果は、公開メーリングリストへの追記にも載せています。 メーリングリストで開発者に確認した CachyOSへの報告に加え、Linux DRMメーリングリストにもログと分析を送りました。 当初の調査では、既知の問題の発生条件は主にハイバネーションでした。一方、私の環境で確認したのは、通常稼働中にグローバルOOMが起き、ttm_global_swapout()を通ったケースです。 詳しいスタックやbulk_moveの端点について追記したところ、2026年9月25日にVadim Nikitushkin氏から返信がありました。 返信では、pos->firstが解放済みのリソースを指し、pos->lastも古いまま残っているためNULL参照につながることが説明されています。また、処理がbdev->lru_lockのもとで発生するため、後続のKFD workerやamdgpu_drm_releaseがロック待ちになった状況とも整合するとのことでした。 ハイバネーションだけが特別なのではなく、メモリ圧迫時にも同じswapout経路へ到達できるという回答でした。これは既存の原因分析に対する別GPU・別トリガーからの追加事例です。修正そのものを私が発見した、という話ではありません。 7.2系へのバックポートも確認した 7.2系はmainlineとはコード構成が異なり、先ほどのttm_resource_try_charge()がありません。開発者からは、7.2.8向けには2つのmainlineコミットの効果を、swapout側の1か所の変更にまとめて取り込むと説明されました。 自分でもCachyOS 7.2.7のソースに対し、その1か所の差分がpatch --dry-run -p1で適用できることを確認し、Issue #1058のコメントに記録しました。 これは「ソースへパッチを適用できる」という確認です。修正したカーネルのビルド、実機起動、クラッシュ再現テストとは別です。 その後、安定版への修正とCVEを確認 Linux 7.2.8のリリース記録とLinuxのCVE告知によると、7.2系の修正はコミット1169fe8c11ca45e3f91d59a73eb271d0ca8a7fb0として取り込まれました。2026年10月6日には、この不具合にCVE-2026-98166が割り当てられています。 CVE告知には、元の報告で使用された別のGPU（AMD Phoenix APU）について、ハイバネーションの試行で修正前18回中5回クラッシュし、修正後の12回はクラッシュしなかったという検証も記載されています。この数値は元の修正側の検証で、私のRX 7800 XTでの測定ではありません。 Linux本流・安定版に修正が入ったことと、各ディストリビューションの実機へ適用されたことも分けて考える必要があります。 今回、私のRX 7800 XT上で修正済みカーネルを起動し、同条件で比較するA/B試験はしていません。自分が確認したのは、当時のログ、ソースとインストール済みモジュールの条件、開発者の見解、安定版への修正反映までです。 PRを出さないOSS貢献もあった これまではOSSへの貢献というと、コードを書いてPRを提出する場面を考えることが多かったのですが、今回は少し違いました。 手元のクラッシュログから呼び出し経路を取り出し、既知の不具合の修正前後のコードを照合して、追加の発生条件として開発者に届けました。CachyOSのIssueには、当時の7.2系でどの差分を取り込めばよいかも残せました。 クラッシュが直ったと自分の環境で実証できたわけではありません。それでも、「別のGPUで、ハイバネーションなしに同じ問題が起きた」という情報には意味がありました。自分の報告と、既存の原因分析・修正・検証をそれぞれ誰が行ったかまで残しておきたいと思います。 参照した一次資料 CachyOS Issue #1058：自分のクラッシュ報告とバックポート差分 Linux DRM開発ML：最初の報告 Linux DRM開発ML：開発者との確認 mainlineコミット 3db7d7d mainlineコミット fcfe647 Linux 7.2.8リリース記録 Linux CVEチームのCVE-2026-98166告知