Portál AbcLinuxu, 20. dubna 2024 02:11
MAP_SHARED_VALIDATEMAP_SHARED_VALIDATE
Stav vydání jádra. Huston: o dalších 10 let později. Patche poll() staženy. Citáty týdne: Dave Chinner a Daniel Vetter. Pohled na hack MAP_SHARED_VALIDATE.
Kernel release status. Jonathan Corbet. 3. července 2018
Současné vývojové jádro je 4.18-rc3, vydané 1. července. Linusova slova: „A vypadá to celkem normálně – něco přes třetinu jsou ovladače (různé: vstupní zařízení, usb, zvuková zařízení, gpu, mtd, sítě,…) a zbytek aktualizace architektur (arm/arm64 – dominují jim soubory stromů zařízení, microblaze, powerpc, x86), souborové systémy (xfs, trochu btrfs, drobnosti v jádře vfs), sítě, aktualizace dokumentace a nástroje okolo.“
Stabilní aktualizace: 4.17.4, 4.14.53, 4.9.111, 4.4.139 a 3.18.114 byly vydány 3. července.
Huston: Another 10 years later. Jonathan Corbet. 28. června 2018
Za přečtení stojí, co sepsal Geoff Huston o tom, jak se posledních deset let vyvíjely a kam by mohly směřovat sítě. „Možná, že tento větší odpor ke změnám je způsoben růstem velikosti sítě, její setrvačná hmotnost také roste. Kdysi jsme si navzájem citovali Metcalfeho zákon, opakovali jsme si mantru, že „hodnota“ sítě kvadraticky roste s počtem uživatelů. S tím souvisí pozorování, že odpor sítě ke změnám, vlastně setrvačná hmotnost, také přímo závisí na druhé mocnině počtu uživatelů.“
poll() patches pulled. Jonathan Corbet. 3. července 2018
Jak se psalo v článku Zrušení daně poll(), patche, které přidávají polling subsystému asynchronního I/O (AIO), byly sice začleněny pro vydání 4.18, ale přinesly se sebou nepříjemnou výkonnostní regresi. Proběhla diskuze, jaké změny provést, aby se dopady zmírnily, ovšem Linus Torvalds závěrem vrátil celou skupinu změn z hlavního stromu. Takže nakonec ve vydání 4.18 přeci jen žádné nové rozhraní pro polling nebude.
Torvalds k patchům měl řadu připomínek, a to i k přidaným nepřímým voláním funkcí, která právě způsobovala problémy s výkonem. Ale nezdála se mu ani změna implementace poll() na úroveň virtuálního souborového systému: nelíbilo se mu obnažení některých nízkoúrovňových detailů. Náhrada této skupiny patchů tedy bude muset zvolit jiný přístup, který ponechá stávající mechanismus a variantu s AIO přidá zvlášť. Zůstaňte na příjmu.
Quotes of the week. Jonathan Corbet. 4. července 2018
To je ten skutečný problém – přimět uživatelský prostor, aby používal všechny urychlovací bity, které poskytujeme. Jak dlouho už máme rozhraní splice, která umožňují efektivně kopírovat data, aniž by musela procházet uživatelským prostorem? Jeden by si myslel, že používat tato API je samozřejmost, ale nepoužívá je vůbec nikdo. Mám podezření, že s copy_file_range() a podobným pokrokem v API AIO+DIO se stane to samé…
Obhajoba stručnosti jako efektivního způsobu komunikace se vrací jako bumerang, protože, aspoň já mám takovou zkušenost, vede potenciální dobrovolníky k tomu, aby šli jinam, kde budou spíše vítáni.
MAP_SHARED_VALIDATERevisiting the MAP_SHARED_VALIDATE hack. Jonathan Corbet. 29. června 2018
Jedna z nejčastějších chyb v návrhu systémových volání je opomenutí kontroly neznámých příznaků, pokud volání příznaky přijímá. Stane-li se někdy, že volající mohou nastavit neznámé příznaky, přidávání nových příznaků se stává minovým polem. Ovšem v případě mmap() vývojáři přišli na chytrou obezličku, jak se tomu vyhnout. Nedávná diskuze pak tento přístup zpochybnila a nadhodila otázku, co je to vlastně regrese v jádře. Žádné změny se sice v důsledku nechystají, ale tato debata poskytuje příležitost jednak se podívat na tento hack, jednak sledovat, jak se jaderná komunita rozhodne, zda je změna regrese, či nikoliv.
V roce 2017 se několik vývojářů snažilo přijít na to, jak umožnit bezpečný přímý přístup uživatelského prostoru k souborům uložených na zařízení s nevolatilní pamětí. Příslušný hardware sice procesoru umožňuje paměť adresovat přímo, ale kdyby souborový systém současně změnil uspořádání bloků, veškeré změny by přišly vniveč. Jako řešení se objevil nový příznak MAP_SYNC volání mmap(). Když se soubor (uložený na zařízení s nevolatilní pamětí) namapuje s tímto příznakem, jádro si dá záležet, aby zajistilo, že nedojde ke střetu přístupu k mapování a změn na úrovni souborového systému. Z pohledu aplikací tento příznak problém řeší.
Nebo řešil by, kdyby nebylo onoho problému s neznámými příznaky, který mmap() provází od samého začátku. mmap() (jak káže letitá praxe) nesmí vrátit chybu, když dostane neznámé příznaky. Jedna možná komplikace plynoucí z přidávání nových příznaků k takovém systémovému volání je, že pokud některý program z nějakých důvodů už příznak MAP_SYNC používal, mohlo by se změnit jeho chování. To by v tomto případě neměl být zásadní problém. Co je vážnější, aplikace nemají možnost zjistit, zda jádro, na kterém běží, vůbec příznak MAP_SYNC podporuje, protože všechna jádra při volání s ním vrátí kód odpovídající úspěchu. Jestliže tedy integrita dat aplikace závisí na použití MAP_SYNC, aplikace potřebuje vědět, zda je tato funkce vůbec podporována – jenže mmap() neposkytuje žádný způsob, jak to zjistit.
Řešení vyplynulo z toho, že mmap() vlastně podporuje dva vzájemně se vylučující příznaky: MAP_SHARED a MAP_PRIVATE. Volání mmap() s oběma příznaky tedy selže, takže žádný funkční program jej takto nepoužívá. Tato kombinace je tudiž potenciálně k dispozici pro jiné způsoby použití. Tento commit přidal nový „příznak“ nazvaný MAP_SHARED_VALIDATE, který je definován jako kombinace MAP_SHARED a MAP_PRIVATE, tzn. vyžádá si vytvoření sdíleného mapování, ale současně také explicitní ověření všech ostatních poskytnutých příznaků volání. Souborové systémy a ovladače zařízení mohou jádru (pomocí pole mmap_supported_flags ve struktuře file_operations) sdělit, že podporují příznaky nad rámec těch „historických“. Nedostane-li jádro tuto informaci, shledá, že tyto příznaky podporovány nejsou a (v případě použití MAP_SHARED_VALIDATE) nechá všechna volání, která se pokusí je použít, selhat.
Oba příznaky, MAP_SYNC a MAP_SHARED_VALIDATE, byly začleněny do vydání 4.15. Aplikace, která je ve volání mmap() použije oba, si může být jistá, že MAP_SYNC je opravdu podporován jak jádrem, tak souborovým systémem, ve kterém je namapovaný soubor uložený. Jinými slovy, jaderná komunita našla způsob, jak přidat (volitelné) ověřování příznaků systémovému volání, u nějž se tradičně tato kontrola neprovádí.
Nedávno ovšem Eric Sandeen na MAP_SHARED_VALIDATE narazil a uvědomil si, že jeho přidáním se chování mmap() možná překvapivě změnilo. Dříve předání MAP_SHARED a MAP_PRIVATE způsobilo selhání volání mmap(), nově však může uspět, tzn. nějaká aplikace mohla předávat tuto dvojici příznaků (aniž by tušila o existenci MAP_SHARED_VALIDATE) s jiným výsledkem než nyní. Sandeen tuto změnu nazval „regresí“ a sepsal patch, který navrací původní chování v situaci, kdy chybí příznaky mimo onu „historickou“ skupinu, neboli MAP_SHARED_VALIDATE selže, pokud nejde ověřit žádné zvláštní příznaky.
Tento patch ale začleněn nebude. Linus Torvalds zdůraznil, že změna chování sama o sobě není regresí. Aby o regresi šlo, změna by musela rozbít dříve funkční programy. Bity, ze kterých se MAP_SHARED_VALIDATE skládá, byly vybrány právě proto, že žádný program, který je takto používal, nemohl být funkční, a tak se změnou ani nemohl rozbít. Torvalds to popsal jako logicky ekvivalentní přidání nového systémového volání: programy, které ho zkoušely volat, než bylo přidáno, se nepochybně dočkají změny chování, ale těžko to nazvat regresí.
Sandeenův patch by místo toho mohl způsobit selhání dnes funkčních volání mmap(), některá aplikace totiž možná používá MAP_SHARED_VALIDATE, ale už ne další příznaky vyžadující ověření. To by regrese byla. Takže chování MAP_SHARED_VALIDATE se nezmění, dokud se neobjeví zprávy o rozbitých aplikacích (což se nejspíš nestane).
Zkušenosti ukazují, že programy mohou záviset na sebemenších detailech chování systému – již mnohokrát se vynořil Hyrumův zákon. Ale za těch šest měsíců od vydání 4.15 nebyly nahlášeny žádné problémy, tím pádem se zdá pravděpodobné, že tato konkrétní změna se obejde bez regresí. Jedna věc by však opravena být měla: manuálová stránka mmap() stále tvrdí, že výsledkem předání MAP_SHARED a MAP_PRIVATE současně je chyba, což teď už není pravda. To je naštěstí snadno řešitelný problém.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.