Jaderné noviny – 27. 2. 2014: Problémové příznaky podruhé

18. 3. 2014 | Luboš Doležel | Jaderné noviny | 3286×

Aktuální verze jádra: 3.14-rc4. Citáty týdne: Thomas Gleixner, Paul McKenney. Řádné ošetřování neznámých příznaků v systémových voláních.

Obsah

• Aktuální verze jádra: 3.14-rc4
• Citáty týdne: Thomas Gleixner, Paul McKenney
• Řádné ošetřování neznámých příznaků v systémových voláních

Aktuální verze jádra: 3.14-rc4

Aktuální vývojová verze jádra je 3.14-rc4 vydaná 23. února. Linus ji okomentoval slovy: Nic velkého nebo obzvláště strašidelného.

Stabilní aktualizace: verze 3.13.4, 3.12.12, 3.10.31 a 3.4.81 vyšly 20. února, verze followed by 3.13.5, 3.12.13, 3.10.32 a 3.4.82 pak 22. února.

Citáty týdne: Thomas Gleixner, Paul McKenney

A teď vážně, všichni, kdo stále používají tasklety, aniž by si byli vědomi jejich nenápadných problémů a měli zatraceně dobrý důvod je používat, by si měli vzít štípačky nebo nějaký jiný vhodný nástroj, aby zneškodnili svou klávesnici a začali pracovat v pekárně, kde mohou jíst vše, co si sami nadrobili.

-- Thomas Gleixner

Rád dávám patchům několik týdnů pořádný záhul, než je předám dál. Mám tu zkušenost, že když to neudělám, tak dostanu zanedlouho záhul já.

-- Paul McKenney

Řádné ošetřování neznámých příznaků v systémových voláních

Jedním z důležitých kroků při přidávání argumentu flags pro příznaky do systémového volání je ověřování, zda tento argument obsahuje jen podporované hodnoty. Pokud se tak nestane, tak si zavaříme na řadu problémů s kompatibilitou do budoucna. Pohled na historii vývoje systémových volání na Linuxu (a Unixu) ale ukazuje, že dělá lidem problém si na to zvyknout.

Každý argument s příznaky (nebo jakoukoliv jinou vstupní strukturou, která obsahuje pole s příznaky) by měl mít příslušnou kontrolu, která může vypadat následovně:

if (flags & ~(FL_XXX | FL_YYY))
	return -EINVAL;

Zde FL_XXX a FL_YYY představují hypotetickou sadu příznaků, kterým systémové volání rozumí, důsledkem této kontroly je pak vrácení chyby, pokud volající nastaví jakýkoliv bit, které není v seznamu podporovaných. Podobné kontroly připravují toto API na budoucnost, tedy aby bylo možné systémové volání rozšířit o dodatečné příznaky. Představme si, že systémové volání má nový příznak nazvaný FL_ZZZ a mění tedy kontrolu následovně:

if (flags & ~(FL_XXX | FL_YYY | FL_ZZZ))
	return -EINVAL;

Aplikace v uživatelském prostoru je nyní schopna ověřit, jestli běží pod jádrem, kde dané systémové volání podporuje FL_ZZZ, a to tak, že si pohlídá chybu EINVAL při uskutečňování volání. Díky tomu mají aplikace možnost řešit rozdíly v systémových voláních napříč verzemi jádra.

I když implementace podobných kontrol v jádře může vypadat jednoduše, ukazuje se, že spousta systémových volání tuto kontrolu nedělá, a to včetně clock_nanosleep(), clone(), epoll_ctl(), fcntl(F_SETFL), mmap(), msgrcv(), msgsnd(), open(), recv(), send(), sigaction(), splice(), unshare() a spousty dalších.

Většina těchto volání tu s námi je už celé roky. Mladší volání, která argument flags mají, nezbytnou kontrolu zpravidla obsahují. I mezi nimi se ale najde pár takových, které ji nemají, jako jsou open_by_handle_at() (2.6.39), recvmmsg() (2.6.33) a sendmmsg() (3.0). V těchto případech autor možná emuloval nepřítomnost takové kontroly u příslušných dřívějších volání (open(), recv(), send()). Jde ale o promeškanou příležitost, jak původní API vylepšit.

U každého volání, které u argumentu flags postrádá kontrolu, pak nemají aplikace v uživatelském prostoru možnost jak zjistit, které příznaky daná verze jádra podporuje. Opomenutí implementovat tyto kontroly v jádře pak představuje komplikaci i pro životy jaderných vývojářů, což několik vzniklých situací dokazuje.

Pokud jádro nekontroluje, že ve flags dostává jen platné bity, pak mohou aplikace beztrestně do „nevyužitých“ bitů ve flags dávat náhodný bordel. Jestliže se pak jaderný vývojář rozhodne využít některý z nevyužitých bitů, tak může docházet k překvapivým poruchám v aplikacích, což zase může vést k tomu, že jaderný vývojář bude muset psát neoptimální implementace nových funkčností v API. Příkladem z nedávné doby budiž implementace příznaku EPOLLWAKEUP, kde snaha vyhnout se rozbití uživatelského prostoru vede k tomu, že jádro tiše ignoruje tento příznak, pokud volající proces nemá právo CAP_BLOCK_SUSPEND. V ideálním případě by samozřejmě jádro volajícího o chybě informovalo navrácením chyby. Následkem toho aplikace, které si chtějí být naprosto jisté, že volání uspěje, si musí explicitně ověřit, že mají právo CAP_BLOCK_SUSPEND.

Ještě čerstvějším případem je implementace příznaku O_TMPFILE u open(), kdy definice příznaku zahrnuje příznak O_DIRECTORY s tím účelem, aby starší jádra, která O_TMPFILE neznají, vrátila chybu v případě, že je tento příznak použit. Bylo potřeba to tak udělat proto, že aplikace vytvářející dočasné soubory si jsou často vědomy bezpečnostních důsledků a potřebují vědět, zda bylo požadavku na vytvoření skrytého dočasného souboru vyhověno. Bez této úpravy by příznak O_TMPFILE byl na starších jádrech prostě ignorován a aplikace by nevědomky vytvářela viditelný soubor. Nepříjemným vedlejším účinkem je pak to, že aplikace musejí kontrolovat vrácení dvou různých chybových hodnot, aby zjistily, zda běží na jádře, které O_TMPFILE nepodporuje.

Dále stojí za zmínku, že několik systémových volání přidalo kontrolu argumentu flags až po počáteční implementaci. Mezi ně patří dvě stará volání umount2() (kontrola přidána v Linuxu 2.6.34) a swapon() (kontrola přidána v Linuxu 3.4). Dále je tu pak mremap(), které se poprvé objevilo v Linuxu 2.0 a bylo rozšířeno o kontrolu v Linuxu 2.4, a volání timerfd_settime(), které se poprvé objevilo ve verzi 2.6.25 a bylo o kontrolu rozšířeno v Linuxu 2.6.29.

Přidání kontrol do těchto volání ale představuje vyjímku z pravidla, že podobné kontroly nelze přidávat, jelikož by mohlo dojít k rozbití stávajících aplikací, které předávají nahodilý bordel v „nevyužitých“ bitech argumentu flags. U umount2() a swapon() bylo možné změnu udělat snad proto, že mimo příkazy mount a swapon je málokdo používá a tyto programy by bylo možné v případě rozbití jednoduše opravit. V případě timerfd_settime() došlo ke změně krátce po počáteční implementaci, kdy toto rozhraní moc programů asi ještě nepoužívalo. A v případě mremap() došlo ke změně při velkém skoku verze jádra (mezi 2.2 a 2.4), kdy byly takové změny ABI výjimečně povoleny; při současném 10týdenním vývojovém cyklu takové změny možné nejsou.

Proto, když kontrola nepoužívaných bitů příznaků není zařazena do počáteční implementace, nebývá možné ji doplnit později. Jednoznačným závěrem tedy je, že náležité kontroly by měly být přidány hned zkraje.

       

Komentáře

[Ondrej 'SanTiago' Zajicek]

Pouzivani EINVAL pro kontrolu, zda je featura dostupna, me prijde jako dost prasacke rozhrani. Pokud se zavadi kontrola s ohledem na budouci rozsiritelnost, tak by mel byt pouzit nejaky specificky chybovy kod ('ENOFLAG'), podobne jako se pouziva ENOPROTOOPT u setsockopt() pro nezname options. A EINVAL by se mel nechat pro skutecne invalidni hodnoty, nikoliv pro nezname, ale potencialne (v budoucnu) validni.

[Karry]

Přijde mi že jaderní vývojáři se zdráhají vytvářet jednoznačné chybové kódy... Podobně jako u Btrfs může ENOSP znamenat od "došlo místo", "vyčerpal jsi kvótu", "kernel špatně odhadl místo pro metadata" až po "nepodařilo se mi alokovat buffer v paměti"...

[Petr Ježek]

Kdyby tak byly jednoznačné podněty pro vyvolání těchto chybových kódů. Jak známo, rozbít si ústa lze nekonečně mnoha způsoby...

[little.owl]

I like to hammer new patches for a few weeks before passing them on. My experience is that if I fail to do so, they hammer me somewhat later.

a

Rád dávám patchům několik týdnů pořádný záhul, než je předám dál. Mám tu zkušenost, že když to neudělám, tak dostanu zanedlouho záhul já.

Tohle me hned chytlo za usi, preklad posledni vety je cely dosti mimo.

[Lol Phirae]

Nevidím problém?

[little.owl]

Kounete se na znovu na posledni vetu.

Anglicka verze jasne rika od koho se dostane zahul, v ceskem prekladu se to musite domyslet; navic prelozit "later" jako "zanedlouho" take neni to prave orechove, pozdeji neznamena zanedlouho.

Tedy, trochu lepe:

... , tak [oni] daji pozdeji zahul mne.

Tohle vam v komunikaci prinese problemy.

[Lol Phirae]

No nic. Tyhle doslovný překlady fakt "miluju"...

P.S. Kdo oni? Snad ony?

[Lol Phirae]

P.P.S. "Somewhat later" je něco somewhat jiného než "later".

[little.owl]

Jiste, lze to jeste upresnit. Jinak si rad poslechnu jaky rozdil v tom vy vidite.

[Lol Phirae]

jaky rozdil v tom vy vidite.

No, asi takový, jako autor překladu, který to přeložil jako zanedlouho a ne později.

[little.owl]

Tak to v zadnem pripade, je to stale "pozdeji", tomu neutecete. "somewhat" je tu neco mezi urcitou formou eufemismu a slovni vatou.

Schvalne jsem se na to ted zeptal svych rodilych britskych kolegu: vypusteni "somewhat" zde vyznam v zasade nemeni, ani nema vliv na to jestli se to stane drive ci pozdeji na casove ose (vseobecna shoda), spise to indikuje, ze se tak skutecne stane (o neco mensi shoda). Anglicane, co ti vedi o anglictine, ze?

[Lol Phirae]

Kolego, končím debatu o lejnu.

[little.owl]

Nejde o doslovnost, ani pravopis, ale posunuti vyznamu a vypusteni informace, coz je u citace problem; dalsi casti take rozhodne nejsou doslovne a nic proti tomu nemam.

P.S. Kdo oni? Snad ony?

Muzsky nezivotny, nominativ by asi mel byt skutecne "ony". Vyrustal jsem v prostredi, kde se pouzivalo jen "oni". V jake oblasti CR se prirozene mluvi podle doporucenych pravidel Ustavu pro jazyk cesky?

[Lol Phirae]

Já tam skutečně žádnou vypuštěnou informaci nikde nevidím, sorry.

V jake oblasti CR se prirozene mluvi podle doporucenych pravidel Ustavu pro jazyk cesky?

No, to je tak, když někdo nesmyslně rejpe do překladu, a pak to sám zkomolí tak, že to nedává smysl...

[Ondrej 'SanTiago' Zajicek]

V jake oblasti CR se prirozene mluvi podle doporucenych pravidel Ustavu pro jazyk cesky?

Jak se mluvi je vzhledem k psane forme komentare irelevantni, ale pise se tak snad ve vsech oblastech.

[Lol Phirae]

Asi tak nějak. Ale jinak na závěr tip pro sovy: co se jít vyřádit třeba na ýDěs?

Originál: "It sounds very much like a fireball or an extra-bright meteor, meaning a chunk of rock from space that got in the way of Earth and burns up in the atmosphere."

Překlad: "Podle výpovědí to vypadá na obyčejnou ohnivou kouli, nebo velice jasný meteorit."

[little.owl]

OK, OK, beru vse zpet a prekladateli zde se timto omlouvam.

[little.owl]

Vetsinou se pise tak jak se mluvi a predtim, nez to budete rozporovat, projdete si diskuze na tomto serveru.

Pokud si jeste vzpominam na stredni skolu, kde jsem kvuli tomu dostaval na budku - rozlisujeme: (a) spisovnou cestinu, (b) hovorovou spisovnou cestinu a (c) nespisovnou cestinu. (a) je odvozovano z (b), a (b) pouziva prvky z (c). Slang, kterym se to tu casto jen hemzi, je povazovan za nespisovnou cestinu.

Predpoklad, ze psana forma je automaticky (a), skoncil v dobe kdy pisemny projev prestal byt domenou formalni komunikace.

[Pavel Stárek]

No a tedy jak by měl znít správný překlad oné věty?

[Lol Phirae]

Rád kladivo nové záplaty pro několik týdnů předtím, než je předá dál. Moje zkušenost je, že když tak neučiní, že kladivo mě o něco později. ;)

[u2]

tak to asi neumis anglicky. Me osobne naopak z originalu konecne ta veta zacla davat smysl. Mel me varovat uz ten pubertacky vyraz "zahul", ze neco nebude s prekladatelem vporadku...

[Lol Phirae]

Máš pravdu, jen jsem v Anglii vystudoval VŠ a překládáním se asi deset let živím, jinak do toho vůbec nevidím. Já mám totiž bohužel dojem, že lidi přestávají (roz)umět česky.

[Petr Ježek]

Stálo to za to takhle zaplavelit téma? Nic jiného na sdělení k tématu? Kam to spějeme...

[Václav HFechs Švirga]

+1, tesil jsem se, ze se zas dozvim neco o flazich, jako pod minulym dilem a ono tohle :-P

[u2]

obavam se ze o FLAZICH by ses nedozvedel stejne nic