Vlákno názorů k článku Kernel panic s QR v Linuxu 6.12, neshody Rust vývojářů se správci částí jádra od Yenya - On s Rustem v kernelu je hlavně problém,...

On s Rustem v kernelu je hlavně problém, že Rust si ještě neřekl, jaký vlastně je jeho paměťový model vzhledem k věcem typu přeskládávání instrukcí a viditelnost téhož z jiných CPU (třeba rcu_dereference() a vlastně celé RCU), paralelní přístup k paměti ze strany CPU i periferií (různé ty kruhové buffery a mailboxy pro komunikaci s protistranou jako má třeba virtio), a tak podobně. A nejen že si neřekl, ale někteří propagátoři Rustu v kernelu vlastně ani nevědí, že toto je nějaký problém k řešení.

Víc než jste o tom kdy chtěli vědět lze najít například v blogu Paula McKenneyho, autora RCU:
https://paulmck.livejournal.com/tag/rust

2. 9. 2024, 10:27 editováno autorem komentáře

Opravil bych jen čas: tohle bude naprosto zásadní problém, pokud se má rust v jádrře opravdu nějak víc rozšířit. Zatím se spíš omezují na nějaké "leaf" drivery, takže na větší problémy tohoto typu ještě nenarazili a vystačí s jednoduchým modelem, že jakýkoli paralelní přístup je špatně a chytrý překladač se postará, abychom ho vyloučili. A nebo když už je potřeba pracovat s něčím, co používá RCU nebo jinou "lockless" synchronizaci, přistupuje se k tomu přes céčkové wrappery, čímž se to stane PNJ. (A všetečným otázkám, jak že pak rust vlastně zaručuje tu memory safety, se raději vyhneme.)

Jako jo, ale ten budoucí čas už je "fakt brzo" - v článku se zmiňuje Asahi Lina a driver pro applovskou GPU. To už víceméně je ten problém kruhových bufferů s přístupem "z obou stran north bridge". Částečně z toho lze udělat PNJ ještě tím, že se ty buffery dají do paměti GPU, která je přes něco jako MTRR v CPU nakonfigurovaná jako necachovatelná a bez write-combing, ale umístění v hlavní paměti se stejně časem nevyhnou.

Ona ta cachovatelnost je docela rozdil mezi platformama.. napr stridat ARM vs X86, tak si musite v driveru hodne ohlidat, ze chcete opravdu onen koherentni pool (necachovanou oblast). Na jedne z platforem ale bude fungovat i cachovana, protoze struktura caches je jina a dokud to nezkusite portovat jinam, tak nevidite, ze mate problem, protoze zdanlive vse funguje.

A nekde jde udelat cache flush, a nekde udelat nejde. Nekde flush znamena dropnout celou cache, nekde jen dotcene radky - tahle nekonzistentnost je nejvetsi pitomost prozatim v Linuxu, kdyz resite low level veci, ale oni na to nemaj konzistentni API.

Prakticky napr nas DMA driver pouziva oba typy alokaci - koherentni region (s marnym vykonem) obsahuje jen deskriptory ktere je nutno menit pri linkovani bufferu runtime, a obycejne alokace pro vsechny ostatni - staticky inicializovane a pozdeji nemenne deskriptory.

(už trochu off-topic, ale představte si, že bývaly platformy typu sun4m, které měly _virtuálně_ adresovanou cache, tedy umístěnou ještě před TLB. Pak systém musel řešit i případy, že je toho třeba vylít víc v případě, kdy tatáž fyzická stránka je do virtuální paměti mapovaná víckrát)

napr stridat ARM vs X86

A to jsou pořád ještě docela "civilizované" architektury. Ale co si vzpomínám, tak třeba Alpha sloužívala jako spolehlivý generátor protipříkladů k "samozřejmým" očekáváním.