Ett avrundningsfel på en enda kodrad gjorde delar av ett reserverat grafikminne tillgängligt för vanliga program. Resultatet blev skadade data och svart skärm. För att hitta orsaken tog Linus Torvalds hjälp av AI – men det krävdes 24 felsökningspatchar och 18 omstarter innan gåtan var löst.
AI används i allt fler delar av programutvecklingen, och nu har tekniken även spelat en viktig roll vid felsökning av själva Linuxkärnan.
Linux skapare Linus Torvalds berättar i en kodändring i Linuxkärnan hur AI hjälpte honom att hitta ett ovanligt svårupptäckt fel i grafikdrivrutinen Intel Xe. Han beskriver arbetet som en ”debug session from hell” – en felsökningssession från helvetet.
Problemet drabbade Torvalds egen dator med en Intel Battlemage G21-grafikkrets och 16 GiB grafikminne. När datorn startades visades ingen vanlig inloggningsskärm. I stället möttes han av en svart skärm medan inloggningshanteraren GDM gång på gång försökte starta om skrivbordets grafikprocess.
Datorn fungerade i övrigt, men grafiksystemet kom aldrig längre än till sitt första riktiga arbete.
En gräns drogs åt fel håll
Felet fanns i hanteringen av en del av grafikminnet som används för kompressionsdata, så kallad Flat CCS. CCS kan förenklat beskrivas som metadata som hjälper grafikkretsen att hålla reda på hur olika delar av grafikminnet är komprimerade.
Detta område måste vara reserverat för grafikkretsens egen hårdvara. Operativsystemets vanliga minneshanterare får därför inte dela ut det till program eller använda det för exempelvis sidtabeller.
Intel Xe-drivrutinen läste adressen där det reserverade CCS-området började. Adressen avrundades sedan uppåt till närmaste gräns på 128 KiB. Allt grafikminne under den avrundade adressen betraktades därefter som ledigt och användbart.
Det låter kanske rimligt, men gränsen markerade var det användbara minnet slutade – inte var ett nytt ledigt område började. Genom att avrunda uppåt råkade drivrutinen därför lägga en liten del av det reserverade CCS-minnet i den fria minnespoolen.
Man kan jämföra det med en lagerhylla där halva den sista hyllplatsen redan är reserverad. Om lagrets tillgängliga utrymme avrundas uppåt räknas hela hyllplatsen som ledig, trots att den reserverade delen fortfarande används.
Två kilobyte räckte för att slå ut skrivbordet
På Torvalds dator handlade överlappningen om endast två kibibyte. Eftersom minneshanteraren arbetar med hela minnessidor hamnade det reserverade området ändå på samma sida som minne vilket drivrutinen kunde dela ut.
Vid varje kallstart råkade Mesa, den öppna grafikstacken som används av Linux, placera en viktig sidtabell på just denna minnessida. Sidtabeller fungerar ungefär som kartor som visar grafikkretsen var olika data finns i minnet.
Samtidigt skrev grafikkretsens kompressionshårdvara sina metadata i den reserverade delen av sidan. Den behövde varken något vanligt program, någon bufferthantering eller en särskild GPU-instruktion för att göra det. Skrivningen skedde direkt i hårdvaran – till och med innan användarmiljön hade startat.
När kompressionsinformationen skrevs förstördes delar av Mesas sidtabell. Därmed försvann den post som pekade på minnet där kompositörens kommandon låg. När skrivbordsmiljön skickade sitt första arbete till grafikkretsen kunde GPU:n inte längre hitta instruktionerna.
Resultatet blev ett grafikfel, varefter GDM startade om kompositören. Samma sak upprepades och användaren blev kvar framför en svart skärm.
En manuell omstart av GDM kunde däremot få systemet att fungera, eftersom den nya grafikprocessen fick sina sidtabeller placerade på en annan plats i minnet. Det gjorde felet ännu svårare att förstå: hårdvaran verkade fungera, och problemet kunde tillfälligt försvinna utan att någon kod hade ändrats.
AI gjorde det tidskrävande arbetet
För att hitta orsaken behövde Torvalds lägga till allt mer detaljerad diagnostik i drivrutinen. Sammanlagt krävdes 24 tillfälliga felsökningspatchar och 18 starter med olika versioner av Linuxkärnan.
AI fick göra mycket av det repetitiva arbetet: lägga till ny felsökningskod, bearbeta den insamlade informationen och föreslå nästa kontroll. Torvalds styrde undersökningen och bestämde vilka spår som skulle följas.
Enligt honom ville AI-systemet ge upp vid flera tillfällen. Det hävdade att problemet inte gick att lösa och föreslog att de i stället skulle sammanställa en rapport om vad som hade undersökts. Torvalds fortsatte dock att pressa fram nya tester.
När AI:n fick tydliga instruktioner att fortsätta tog den fram ytterligare diagnostik och analyserade resultaten. Till slut kunde minnesskadan knytas till CCS-området och den felaktigt avrundade adressen.
Torvalds lät även AI skriva den långa tekniska beskrivningen i den färdiga kodändringen.
En rättning på en kodrad
Själva lösningen var nästan komiskt liten. I stället för att avrunda gränsen uppåt ändrades koden så att den avrundades nedåt till den sidstorlek som minneshanteraren använder.
På den berörda datorn innebar det att exakt en minnessida undantogs från den tillgängliga minnespoolen. När Torvalds därefter läste innehållet i den reserverade sidan kunde han se ett regelbundet mönster av kompressionsmetadata – ett tydligt bevis på vad som hade skrivit över sidtabellen.
Drivrutinen innehöll redan en kontroll som var tänkt att upptäcka problemet. Den var dock utformad på ett sådant sätt att den felaktigt avrundade adressen kunde godkännas just i det fall som kontrollen skulle fånga. Dessutom var kontrollen endast aktiv när ett särskilt felsökningsalternativ för Intel Xe-drivrutinen hade aktiverats.
Även den kontrollen har nu ersatts med en som faktiskt kan upptäcka om CCS-området kolliderar med ett annat reserverat minnesområde.
AI som verktyg – inte ansvarig utvecklare
Händelsen visar både möjligheterna och begränsningarna med AI-baserad programmering. AI:n löste inte självständigt problemet och var flera gånger beredd att ge upp. Däremot kunde den snabbt producera diagnostisk kod och gå igenom stora mängder teknisk information när en erfaren utvecklare styrde arbetet.
Det ligger nära Torvalds tidigare hållning: Linuxprojektet ska varken vara ett AI-projekt eller ett anti-AI-projekt. AI bör behandlas som vilket utvecklingsverktyg som helst. Det är fortfarande människan som använder verktyget som ansvarar för kodens kvalitet, granskar resultatet och ser till att ändringen är korrekt.
Felsökningen av Intel Xe-drivrutinen är ett tydligt exempel på detta samspel. AI:n stod för mycket av uthållighetsarbetet, men det krävdes mänsklig envishet, teknisk erfarenhet och 18 kernelstarter för att nå fram.
Efter 24 felsökningspatchar visade sig hela problemet i praktiken handla om skillnaden mellan att avrunda uppåt och att avrunda nedåt. I Linuxkärnan kan en enda felaktig avrundning vara skillnaden mellan ett fungerande skrivbord och en helt svart skärm.
Källor: Kodändringen i Linuxkärnan och diskussionen på DRM-utvecklarnas e-postlista.
FAKTA // Linuxbuggen som krävde 18 omstarter
- $ berörd_drivrutin
- Intel Xe, grafikdrivrutinen i Linuxkärnan.
- $ symptom
- Svart skärm när GDM upprepade gånger försökte starta om skrivbordets kompositör.
- $ testad_hårdvara
- Intel Battlemage G21 med 16 GiB grafikminne.
- $ orsak
- En minnesgräns avrundades uppåt. Därför kunde en del av grafikminnet som var reserverat för kompressionsdata delas ut som vanligt, användbart minne.
- $ konsekvens
- Grafikkretsens kompressionshårdvara skrev över delar av Mesas sidtabell. GPU:n kunde då inte hitta kompositörens instruktioner.
- $ felsökning
- 24 felsökningspatchar och 18 omstarter av Linuxkärnan.
- $ ai_roll
- AI hjälpte till att skriva diagnostisk kod, analysera resultaten och dokumentera felet. Linus Torvalds styrde arbetet och avgjorde vilka tester som skulle genomföras.
- $ lösning
- Gränsen ändrades från uppåtrundning till nedåtrundning, så att det reserverade CCS-minnet inte längre kunde lämnas ut till andra användare.
> SLUTLIG ÄNDRING:
round_up() → round_down()
