Jaderné noviny – 15. 5. 2014: Jak bránit nalézání dalších chyb

3. 6. 2014 | Luboš Doležel | Jaderné noviny | 4480×

Aktuální verze jádra: 3.15-rc5. Citáty týdne: Josh Triplett, H. Petern Anvin. Zpomalení připojování CPU za běhu.

Obsah

• Aktuální verze jádra: 3.15-rc5
• Citáty týdne: Josh Triplett, H. Petern Anvin
• Zpomalení připojování CPU za běhu

Aktuální verze jádra: 3.15-rc5

Aktuální vývojová verze jádra je 3.15-rc5 vydaná 9. května. A ačkoliv rc5 bude možná větší než rc3/4, nemám z toho obavy. Toto začleňovací okno bylo větší než většina jiných a tedy to, že je rc5 o něco větší než obvykle, mě příliš neznepokojuje. A protože rc4 zase bylo menší než obvykle, tak se to pěkně vyrovná. Celý příští týden ale nebudu vůbec dostupný, takže se vrhněte na testování, jelikož na -git stromu bude ticho.

Stabilní aktualizace: verze 3.14.4, 3.10.40 a 3.4.90 byly vydány 13. května.

Citáty týdne: Josh Triplett, H. Petern Anvin

Možná že důvodem, proč Linus přešel na git (a předtím na BK) je částečně i to, aby se vyhnul problému posílej-patche-dokola-než-je-Linus-přestane-zahazovat. Vypadá to, že jsme problém ani tak neopravili, jako ho spíš přesunuli o krok dál na správce subsystémů.

-- Josh Triplett

Dřív jsem si myslel, že 32bitová zařízení budou do roku 2025 minulostí. Nejen, že je teď zjevné, že tomu tak nebude, dokonce jsem se zmýlil tím nejhorším způsobem... a to proto, že všude tam, kde dnes máme 8bitové mikrokontroléry za pár korun s triviálními operačními systémy, budeme mít 32bitové mikrokontroléry za pár korun a na velkém množství z nich poběží Linux. Jak se blížíme k bodu, kdy nejdražší věcí na mikrokontroléru je jeho obal, tak už není důvod si nepořídit výkonné CPU se skutečným OS a minimalizovat čas strávený programováním toho zmetka.

-- H. Peter Anvin

Zpomalení připojování CPU za běhu

Jak tomu tak bývá, jaderní výojáři nemají rádi, když se problémy obcházejí nebo skrývají za pomoci všelijakých hacků. Ačkoliv nedávno zaslaný patch, který právě takový hack používá, asi nebude začleněn, byl obecně vcelku dobře přijat a předvádí zajímavý způsob použití této techniky. Když už jsou naděje na správnou opravu problematického subsystému ztraceny, tak je možná čas na zoufalé činy.

Subsystém, o kterém se bavíme, je ten, který se stará o hotplug CPU. Nabízí se řada důvodů, proč bychom mohli chtít za běhu připojovat (nebo odebírat) CPU na běžícím systému: hardware nám něco takového zkrátka umožňuje nebo chceme odpojit procesor, který se špatně chová. Ve světě virtualizace je změna počtu CPU za běhu zjevným způsobem, jak upravit výpočetní výkon dostupný hostovskému systému. Tato funkčnost má svůj přínos a nikdo by určitě nenavrhoval ji odstranit. Ale nikdo není spokojený s tím, jak byl CPU hotplug implementován.

Změna procesorů na běžícím systému je komplexní operací; na různých úrovních se nachází řada stavů specifických pro procesor, o které je nutné se postarat. V takových situacích dává smysl mít obecný mechanismus, který se stará o složitost, rozděluje ji na jednoduché kroky a zajišťuje, že tyto kroky jsou provedeny ve správném pořadí. Linuxové jádro takový mechanismus bohužel nemá; namísto toho má matoucí pole notifikátorů a zpětných volání, se kterým je obtížné něco dělat. Nepřekvapí tedy, že se v něm nacházejí chyby; vývojáři, kteří se odhodlali je jít hledat, neměli problém na nějaké hned narazit.

Chyb je tam dokonce tolik, že se Borislav Petkov chce postarat o to, aby bylo těžší je najít. V úvodu jeho patche se píše:

Máme tady hromadu přehnaně aktivních testerů, co slepí nějaký skript a začnou bezmyšlenkovitě mlátit do CPU hotplugu a pak hlásí chyby, co se jim podařilo vyvolat.

V první řadě se většina chyb, ne-li všechny, týká tak či tak hotplugu. Ale víme, že hotplug je slepený lepící páskou a a přelepený papírovými pytlíky. Proto jednoznačně marníme příliš mnoho času nad mechanismem, o kterém víme, že je beztak celý rozbitý.

Jeho řešení bylo jednoduché: vložit jednosekundovou prodlevu do každé operace hotplug. Takové zpomalení minimalizuje počet operací, které je možné testovat, a také souběhy mezi nimi. Mělo by to pěkně omezit přísun hlášení chyb.

Má to ale jeden drobný háček: tento patch neopravuje žádné chyby; jen je skrývá. Andrew Morton rychle podotkl, že by takový patch s jisotou vedl k méně opraveným chybám. Thomas Gleixner si zato myslí, že to může být dobrá věc: Kdyby lidé raději strávili stejné množství času tím, že by ten binec v hotplugu přepsali, bylo by to jen ku prospěchu. Ale ne, my tam radši nacpeme ještě víc lepící pásky a všelijakých hacků.

Thomas se už v minulosti o určitý přepis pokusil; v Jaderných novinách jsme o tom psali vloni. Rozdělil hotplug a hotunplug na dlouhý seznam jednotlivých kroků; pak sestavil systém, který je spustí v řádně definovaném pořadí. Ke skutečnému řešení problému to ale mělo daleko; většina stávajícího kódu hotplugu zůstala, jak byl, jen se volal jinak. Vznikl ale framework, který by časem mohl pomoci kompletnímu přepisu.

Jediným problémem je, že nikdo přepis neuskutečnil. Thomasovi došel čas a přesunul se zpět k jiným úkolům a nikdo to po něm nepřevzal, takže patche od svého zveřejnění akorát chřadnou. Namísto přepisu se přidávají opravy čím dál složitějších chyb (nedávný příklad) ve snaze stávající implementaci urdžet v běhu. Tyto opravy mohou řešit konkrétní chyby, ale neřeší složitost a neudržovatelnost systému jako celku; samozřejmě nakonec problémy spíš zhoršují.

Borislava k zaslání patche vedla frustrace z lepení dalších vrstev lepící pásky a papírových pytlíků. Nakonec je to tak, že vývojáři, kteří se v této oblasti kódu pohybují, nechtějí další opravy chyb; chtějí, aby byl kód jednodušší a snáze pochopitelný, aby se přestaly valit opravy, co kód ještě zhoršují. Ztížení nacházení chyb v tomto subsystému je takovým hrubým pokusem o to, jak přesunout pozornost vývojářů jinam.

Patch je samozřejmě spíš vyjádřením postoje, než skutečnou snahou o změnu jádra; bylo by překvapivé, kdyby byl patch začleněn. Ve světě, kde správci subsystému jádra nemohou nutit vývojáře pracovat na konkrétní oblasti a kde žádný manažer neuznal za vhodné, aby jejich podřízení pracovali na vyřešení problému s hotplugem CPU, je někdy nutné být kreativní, aby se podařilo s něčím hnout. Můžeme jen doufat, že zaslání tohoto patche konečně někoho rozhoupe k tomu, aby na problému zapracoval. Thomas ale možná tuto snahu nechtěně sabotoval tím, že řekl, že jestliže se k přepisu subsystému pro hotplug CPU nikdo nedostane, udělá to sám.

       

Komentáře

[pavlix]

Jak bránit nalézání dalších chyb

Na tuhle formulaci bych si dával pozor ;).

[gsnak]

Tiež ma to zarazilo. Predstavil som si skupinu nájomných vrahov ktorá pôjde po ľuďoch čo zapisujú chyby do bugzilly.

[Honz]

Na to jsou tu přece naše oblíbené agentury...

[Michal Kubeček]

Záleží na tom, jestli je to třetí pád nebo čtvrtý… :-)

[trekker.dk]

Jakože tři pády ještě v pohodě, ale po čtvrtém pádu už se problém musí řešit?

[R]

Pri mnohych projektoch netreba nikoho najimat, pretoze bugy v bugzille nikto neriesi. Hnije to tam niekolko rokov a potom sa to uzavrie s tym, ze je to u nepodporovana verzia. Obcas to niekto znovu otvori, ze je ten bug aj v dalsej verzii...

[x14]

minimalozovat

[ebik]

"výojářů" asi se půjdu také vyojit .