Linux 7.0 RC2 pārsteigums: lielāks, drošāks, sarežģītāks

Ievads

Linux kodola izstrāde reti sagādā negaidītus pavērsienus šādā agrīnā posmā, taču Linux 7.0 to izdarīja. Otrais izlaiduma kandidāts (RC2) parādījās acīmredzami apjomīgāks nekā parasti, un Linuss Torvalds to nepārmeta klusējot — viņš norādīja, ka nav "īpaši priecīgs" par to, cik liels tas izrādījās.

Šī ziņa ir nozīmīga gan tehniskajai kopienai, gan izplatītāju uzturētājiem, jo izmaiņu apjoms sākotnējos kandidātos parasti nosaka, cik daudz darba un testēšanas būs nepieciešams līdz stabilajam izdevumam. RC2 lielais apjoms izceļ diskusiju par izstrādes ritmu, piegādes plūsmu un riskiem, kas saistīti ar sarežģītām izmaiņām kodola iekšienē.

Kāpēc RC2 izrādījās tik liels?

Torvalds šo situāciju skaidroja ar "nejauku laikašanas troksni" — tāda veida grafika anomālija, kas dažkārt padara vienu nedēļu haotisku, kamēr nākamā ir mierīgāka. Tomēr liels skaits nemerges komitu norāda, ka patiesībā var būt runa par kaut ko sarežģītāku nekā īslaicīgs blips: Linux 7.0 izstrādes cikls, iespējams, sākas ar lielāku svārstīgumu nekā parasti, kad ievērojams apjoms reāla darba nonāk vienā brīdī, nevis tiek izdalīts pakāpeniski.

Šādas situācijas ietekme nav tikai kvantitatīva — vairākas izmaiņas vienlaikus palielina sinerģijas un regresijas risku. Kad kodolā nonāk daudz neatkarīgu labojumu, kļūdu meklēšana un sakarību noteikšana kļūst sarežģītāka, jo viena izmaiņa var maskēt citas blakusparādības. Tas prasa labāku izmaiņu pārvaldību, intensīvāku paštestēšanu un plašāku sadarbību starp izstrādātājiem un izplatītājiem.

Kas ir iekšā RC2?

Interesantākais RC2 nav vienīgi tā lielums, bet arī saturs. Agrīnie kodola kandidāti parasti ir orientēti uz draiveriem — jaunām vai labotām ierīču saskarnēm. Šoreiz situācija ir citāda: draiveri veido tikai aptuveni ceturtdaļu izmaiņu. Lielākā daļa patchseta iedarbojas uz iekšējo infrastruktūru: kodola kodu bāzi, tīkla uzlabojumiem un failu sistēmu atjauninājumiem. Šāds izmaiņu miksējums var nostiprināt pamatprincipus, taču vienlaikus tam ir plašāks ietekmes rādiuss, ja kaut kas noiet greizi.

Tieši šādas izmaiņas — kodola serdes uzlabojumi, tīkla stabiliķa (network stack) sīkas korekcijas un failu sistēmu atbalsta labojumi — parasti nav mediju virsrakstu temats, taču tie būtiski ietekmē sistēmu uzticamību, veiktspēju un drošību ilgtermiņā. Šajā RC2 kārtā tieši šīs jomas saņēma lielāku uzmanību, kas nozīmē, ka izmaiņas var skart vairāk lietotāju scenāriju nekā daži jauni draiveri.

Draiveru īpatnības

Tomēr draiveri nav pilnībā aizmirsti. Aptuveni ceturtā daļa no izmaiņām tomēr attiecas uz atsevišķiem ierīču vadītājiem, plātēm un perifērijas interfeisiem. Šie labojumi parasti ir aktīvi testēti konkrētās aparatūras konfigurācijās, taču, ja vienlaikus nonāk vairākas neatkarīgas izmaiņas, pastāv iespēja, ka kāda konfigurācija paliks nepamanīta līdz stabilajam izlaidumam.

Failu sistēmas un uzticamība

Failu sistēmas šonedēļ saņēma ievērojamu daļu uzmanības. Darbs, kas skāra SMB klientu, XFS un EROFS, veidoja aptuveni ceturtdaļu no atjauninājuma. Temats ir uzticamība — neromantiskā, bet būtiskā daļa, kas novērš datu korupciju un sistēmu krišanu nostandarta vai reto robežgadījumu dēļ. Šajos labojumos dominē nevis jaunas funkcijas, bet stabilitātes, statistikas un piesardzības uzlabojumi.

XFS un smalki labojumi

XFS atsevišķi saņēma 19 ielāpus, aptverot visu no inode skaitītāju statistikas līdz potenciālajām rādītāju piekļuves sacensībām. Tādas problēmas parasti ir īsti "zem radara" defekti: tās var palikt nepamanītas mēnešiem, darbojoties tikai īpašos slodzēs vai specifiskās aparatūras kombinācijās, bet var izraisīt datu zudumu vai diska neparedzētu atteici lielākā skaitā gadījumu.

Konkrēti XFS labojumi bieži ietver:

• Statistikas rādītāju precizēšanu, lai nodrošinātu pareizu metrikas atspoguļojumu un diagnostiku;
• Sinhronizācijas korekcijas, kas novērš potenciālas sacensību situācijas (race conditions) pie rādītāju vai inode apstrādes;
• Atmiņas žurnālu un pārbaudījumu uzlabošanu, lai nodrošinātu konsekvenču saglabāšanu pēc sistēmas noklusējuma.

SMB un EROFS konteksti

SMB klienta izmaiņas parasti uzlabo tīkla failu piekļuves stabilitāti un mijiedarbību ar attālajiem failu serveriem, tostarp labojumus laika sinhronizācijā, atteices gadījumu apstrādē un kešošanas stratēģijās. EROFS (Read-Only File System) uzlabojumi var būt vērsti uz kompakto datu lasīšanas optimizāciju un kļūdu apstrādi ROM tipa attēliem vai statiskām sistēmām.

Kopumā failu sistēmu sadaļa RC2 norāda uz fokusētu darbu uz datu integritāti, slodzes noturību un edge-case atbalstu — jomām, kas kritiski svarīgas serveriem, mākoņu infrastruktūrai un iebūvētām sistēmām, kur datu zaudējumi var radīt plašāku postu.

Drošība un atmiņas pārvaldība

Arī drošības un atmiņas vadība saņēma pamatīgu apkopes raundu. Nonāca labojumi KASAN (Kernel Address SANitizer) problēmām, kas saistītas ar aparatūras etiķetēm atmiņas pārvaldniekā, un papildus tika veikti darbi saistībā ar spekulatīvās izpildes drošību x86 FRED (Flexible Return and Event Delivery) kontekstā. Šīs izmaiņas nav vizuālas funkcijas, taču tām ir nozīme: kodola aizsardzība pret blakuskanālu tipa uzbrukumiem un bīstamām atmiņas kļūdām tiek veidota no maziem, precīziem labojumiem.

KASAN un aparatūras etiķetes

KASAN ir instruments, kas kodolā atklāj atmiņas pārkāpumus, piemēram, ārpus robežām rakstīšanas un brīvo atmiņas izmantošanu (use-after-free). Labojumi, kas saistīti ar aparatūras etiķetēm (hardware tags), ir īpaši nozīmīgi platformām, kur aparātūra nodrošina papildu metadatu slāņus atmiņas reģioniem. Pareiza šo etiķešu apstrāde nodrošina, ka KASAN var uzticami atklāt anomālijas, nepārprast paralēlās operācijas un neizraisīt negodīgu false positive rezultātus.

Spekulatīvā drošība un x86 FRED

Spekulatīvā izpilde joprojām ir jutīga drošības joma, īpaši pēc iepriekšējiem laikmeta atklājumiem (piemēram, Spectre un Meltdown). FRED ir mehānisms x86 arhitektūrā, kas palīdz efektīvāk apstrādāt atgriezenes un notikumu piegādi, taču tam ir savi drošības aspekti, kas jāņem vērā. Speculative-safety darbi parasti ietver kodola ceļu un mikroarhitektūras kombināciju pārbaudi, lai novērstu iespējamus blakuskanālu atklājumus vai spekulatīvu datu noplūdi.

Šāda veida uzlabojumi bieži prasa ciešu sadarbību starp arhitektūras ekspertiem, drošības pētniekiem un kodola uzturētājiem, jo risinājumu implementācija var ietekmēt veiktspēju vai prasīt papildus mitigācijas slāņus.

BPF, selftesti un reāllaika konfigurācijas

Atjauninājumā ietilpst plaša Berkeley Packet Filter (BPF) izmaiņu un paštestu partija, turpinot stabilu darbu pie tā, kā Linux palaid un validē ieslodzītas (sandboxed) programmas kodolā. Šonedēļ veiktie labojumi ir vērsti uz ārpus-robežām rakstīšanu (out-of-bounds writes) un sacensību stāvokļiem — tie ir īpaši aktuāli PREEMPT_RT konfigurācijām, kur laikaing un vienlaicīguma kļūdas var izpausties skarbāk.

BPF nozīme mūsdienu kodolā

BPF ir kļuvusi par centru dinamiskai instrumentācijai, tīkla filtrēšanai un drošības politiku ieviešanai tieši kodola līmenī. Tā iespējas ļauj izpildīt mazu, drošu programmu kodā bez nepieciešamības rakstīt jaunu draiveri, bet tas arī uzliek lielas atbildības — jānodrošina, ka BPF bytecode nevar sabojāt kodola atmiņu vai izraisīt negaidītas sacensības rindās.

PREEMPT_RT konteksts

Reāllaika (real-time) PREEMPT_RT konfigurācijas uzsver minimālu latentumu un deterministisku uzvedību. Šādos režīmos laikaing kļūdas vai sacensības var kļūt acīmredzamas tikai pie augstām slodzēm vai īpatnējām aparatūras iestatēm. Tāpēc BPF un citu modulāru elementu labojumi PREEMPT_RT vidē ir svarīgi, lai saglabātu kodola stabilitāti, īpaši ierīcēs ar prasībām uz zemu latentumu (piemēram, tīkla ierīces, audio apstrāde un industriāli kontrolsistēmas).

Kāpēc izmaiņas sakrājās tieši tagad?

Kāpēc viss sakrājās šajā brīdī? Torvalds norādīja, ka daļa no skaidrojuma var būt Linux 6.19 cikla paplašināšana par nedēļu. Šāds pagarinājums var radīt pēcefektu, kas izskatās kā sastrēgums: ielāpi gaida, spiediens pieaug, un nākamais merge logs kļūst pārpludināts. Ja tas ir vienkārši paskaidrojums, RC3 vajadzētu nomierināt situāciju un atjaunot ierasto ritmu.

Tomēr var būt arī citas cēloņsakarības, kas vērš uzmanību uz izstrādes procesa niansēm:

• Sadalīta darba piegāde: dažādu uzturētāju un attīstītāju darbība var sakrist, nodrošinot vairākus neatkarīgus patchus vienā laika brīdī;
• Atkarību ķēdes: labojumi vienā subsistēmā var izraisīt nepieciešamību pēc papildus labojumiem citur, kas palielina vienlaicīgo izmaiņu apjomu;
• Vēlme iekļaut kritiskus uzlabojumus agrīnā stadijā: ja attīstītāji atrod būtiskas stabilitātes vai drošības korekcijas, tās mēdz iekļaut ātrāk, lai nodrošinātu plašāku testēšanu kopā ar RC ciklu.

Ko sagaidīt no RC3 un turpmāk

Ja RC3 būs normāla izmēra, tas liecinās, ka RC2 bija īslaicīgs laikašanas efekts. Taču, ja RC3 arī būs palielināts, tas norādītu uz dziļāku stabilizācijas fāzi Linux 7.0 izstrādē, kas nozīmētu ilgāku testēšanas periodu pirms stabilā izlaiduma. Tas varētu būt pozitīvi no kvalitātes viedokļa, jo vairāk laika testēšanai parasti nozīmē mazāk regresiju produkcijas vidē.

Šeit ir dažas konkrētas lietas, kam izstrādātāji, izplatītāji un sistēmu administratori jāpievērš uzmanība nākamajos kandidātos:

• Testu paplašināšana failu sistēmām, īpaši XFS, SMB un EROFS, lai atklātu edge-case problēmas;
• BPF un PREEMPT_RT savietojamības pārbaudes uz reāllaika slodzēm;
• KASAN un citu sanitizatoru izmantošana, lai atrastu atmiņas pārkāpumus, kas var būt slēpti parastā testēšanā;
• Detalizēta regresiju analīze, ja RC3 turpinās būt kuplāks, ar izmaiņu segmentāciju, lai identifikētu potenciāli bīstamākos patchu kopumus.

Secinājums un ietekme ekosistēmai

Linux 7.0 RC2 ir interesants indikators: tas parāda, ka šis izstrādes cikls var būt dinamiskāks un potenciāli prasīt vairāk uzmanības no kopienas. Lai arī pašas izmaiņas bieži nav vizuāli uzkrītošas, tās ir būtiskas sistēmas uzticamībai, drošībai un ilgtermiņa veiktspējai. Distro uzturētājiem un uzņēmumiem, kas plāno migrēt uz jaunāko kodolu, ieteicams sekot līdzi RC3 un veikt papildu testēšanu savās konfigurācijās pirms pārejas.

Galu galā nākamie izlaiduma kandidāti pateiks skaidrāk: vai RC2 bija tikai laikašanas troksnis vai arī signāls par intensīvāku stabilizācijas periodu. Kodolam kā projektam tas nozīmē vienu lietu — vairāk komunikācijas, rūpīgāku testēšanu un sadarbību starp izstrādātājiem, uzturētājiem un lietotājiem, lai nodrošinātu, ka Linux 7.0 iznāk pēc iespējas drošāks un uzticamāks.