Jaderné noviny – 11. 4. 2013: Na cestě k vynucenému odpojování disků

29. 4. 2013 | Luboš Doležel | Jaderné noviny | 4650×

Aktuální verze jádra: 3.9-rc6. Citáty týdne: Dave Chinner, Ingo Molnar, edeloget. Přidána podpora pro 3D na NVIDIA Tegra. Jaderná podpora pro emulaci floating-point na ARM odstraněna. Další snaha o revoke().

Obsah

• Aktuální verze jádra: 3.9-rc6
• Citáty týdne: Dave Chinner, Ingo Molnar, edeloget
• Přidána podpora pro 3D na NVIDIA Tegra
• Jaderná podpora pro emulaci floating-point na ARM odstraněna
• Další snaha o revoke()

Aktuální verze jádra: 3.9-rc6

Aktuální vývojová verze jádra je 3.9-rc6 vydaná 7. dubna. Jede to podle plánu, takže jestli se něco nepokazí, tak rc7 bude jako obvykle poslední.

Stabilní aktualizace: verze 3.8.6, 3.4.39 a 3.0.72 vyšly 5. dubna; verze 3.2.43 vyšla 10. dubna.

Citáty týdne: Dave Chinner, Ingo Molnar, edeloget

Vzdal jsem snahu přesvědčovat lidi, že by měli používat obecný kód, když se všichni snaží o drobné optimalizace. Argument „můžu se u každé inkrementace a dekrementace zbavit 3 instrukcí“ zdá se vždy vyhraje nad „víme, že obecná počítadla fungují“...

-- Dave Chinner

Kconfig není příliš sofistikovaný jazyk – je to takový COBOL mezi konfiguračními jazyky.

-- Ingo Molnar

Chybějící podpora i386 v Linuxu 3.8.6 mě znepokojuje.

-- edeloget

Přidána podpora pro 3D na NVIDIA Tegra

Jde o malou sadu patchů, ale i tak to stojí za řeč: Avionic Design (ve spolupráci s NVIDIA) přispělo podporou 3D pro řadu SoC NVIDIA Tegra. Příslušný kód pro uživatelský prostor sídlí na Githubu.

Jaderná podpora pro emulaci floating-point na ARM odstraněna

Správce ARM Russell King oznámil, že odstranil kód ARM nwfpe („NetWinder floating point emulator“) a VFP (vector floating point) z jádra kvůli nedávno odhalenému licenčnímu problému. Toto bude velký problém pro procesory ARMv4 a ARMv5, na kterých bez NWFPE už nepůjde spouštět uživatelský prostor. Dopad to může mít i na novější CPU – i v podobě nižšího výkonu u některých operací. Byly zahájeny práce na vývoji odpovídající náhrady.

Aktualizace: vypadá to, že Linus je proti odstranění, takže situace by se mohla změnit.

Další snaha o revoke()

Systémové volání revoke() má docela jednoduchý princip: uzavřít jakékoliv otevřené popisovače v cestě předané v argumentu a znemožnit přes tyto popisovače další přístup. Klasickou ukázkou je snaha zajistit, aby nějaký zlý program nedržel otevřené zařízení terminálu nebo konzole před tím, než je povoleno přihlášení, ale našla by se i další použití. Funkční implementaci revoke() by šlo například používat pro čisté odpojení popisovačů odkazujících na zařízení, jenž bylo ze systému odebráno; systémy souborů jako /proc by to také mohly použít pro odstranění již nepotřebných virtuálních souborů.

Má to jen jeden háček: Linux revoke() nepodporuje a všechny snahy o přidání v uplynulých letech skončily neúspěchem. Implementovat funkčnost za revoke() se ukazuje býti docela těžké, pokud to má být uděláno bezpečně. Poslední pokus o implementaci revoke může skončit podobně; neexistuje ani nějaký patch jako „proof-of-concept“. Ale protože za tímto úsilím stojí Al Viro, dá se očekávat, že šance na úspěch jsou lehce nadprůměrné.

Ne každý popisovač bude podporovat revoke(); v některých případech může být řádná implementace příliš složitá. V Alově návrhu, tam, kde je revokace podporovaná, existuje nová struktura svázaná s příslušným zařízením (nebo něčím jiným):

struct revokable {
	atomic_t in_use;		// number of threads in methods,
	spinlock_t lock;
	hlist_head list;
	struct completion *c;
	void (*kick)(struct revokable *);
};

Pole in_use sleduje to, kolik vláken aktivně vězí v metodách ve file_operations spojených s tímto objektem. Aby bylo toto sledování možné, bude nutné změnit každou relevantní metodu v jádře tak, aby volaly několik pomocných funkcí a hlídaly si revokované popisovače. Takže volání, které teď vypadá jako:

ret = file->f_op->read(...);

By pak vypadalo asi tak takto:

if (start_using(file)) {
	ret = file->f_op->read(...);
	stop_using(file);
} else {
	ret = -EIO;  /* File revoked */
}

Pomocné funkce start_using() a stop_using() inkrementují a dekrementují počítadlo in_use. Pokud je ale toto počítadlo záporné, pak je přístup revokován a start_using vrátí false; v takovém případě by se daná metoda ve file_operations neměla zavolat a měl by být vrácen příslušný chybový kód. Vnitřnosti těchto pomocných funkcí jsou pochopitelně o něco složitější; více najdete v Alově e-mailu. Jak Al upozorňuje, míst, odkud se volají metody ve file_operations, je v jádře hodně, takže tato konkrétní změna by byla relativně intruzivní.

Smyslem zpětného volání kick() je upozornit ovladač daného objektu, že přístup je revokován a že by jakékoliv čekající I/O operace měly být dokončeny. Procesům čekajícím na I/O by měla být vrácena chyba a I/O by mělo být zrušeno. Po zavolání kick() by se měl počet vláken pracujících s file_operations daného objektu rychle snížit na nulu.

Když je open() zavoláno na objektu podporujícím revokaci, pak příslušná struktura file obdrží ukazatel na strukturu, která vypadá takto:

struct revoke {
	struct file *file;
	struct revokable *revokable;
	struct hlist_node list;
	bool closing;
	struct completion *c;
};

Pole list se používá ke sledování všech otevřených souborů spojených s daným revokovatelným objektem. Posledním krokem v  implementaci open() je zavolání pomocné funkce make_revokable(), která alokuje strukturu revoke a připojí ji do seznamu ve struktuře revokable daného objektu.

Díky takovéto infrastruktuře je možné revoke() implementovat. Potřebné kroky jsou přibližně tyto:

1. Označit objekt jako revokovaný odečtením velkého čísla od in_use, aby počítadlo mělo zápornou hodnotu. To zabrání dalším voláním metod na file_operations dotčeného objektu.
2. Jestliže in_use indikuje, že na file_operations objektu aktuálně běží nějaká vlákna, pak zavolej kick(), aby došlo k ukončení a vyčkej, než se tak stane.
3. U každého otevřeného souboru zavolej metodu release() aby došlo k jeho uzavření a odstraň soubor ze seznamu.

Na konci tohoto procesu by k danému objektu neměly být otevřeny žádné soubory a žádná vlákna by neměla vykonávat souborové operace nad tímto objektem. To druhé je důležité; robustní a bezpečné implementování revoke() je možné jen tehdy, když si jádro může být jisté, že všechny předchozí reference na revokovaný objekt jsou opravdu pryč. Jakmile je to hotové, pak by mělo být možné uvolnit příslušné prostředky nebo umožnit novým procesům objekt otevřít.

Je tu ale jeden palčivý problém: co udělat s procesy, které použily mmap() pro namapování objektu do svého paměťového prostoru. Jednou možností je vynutit odmapování této paměti, odstranit příslušné tabulky stránek a příslušně upravit strukturu VMA (virtual memory area); proces by pak při pokusu o přístup k této paměti pravděpodobně obdržel signál SIGSEGV. Tento přístup je sice bezpečný, ale přináší riziko v podobě neočekávaných pádů programů. V případech, kdy je mapována paměť zařízení, může být lepším řešením při všech přístupech vracet 0xff (rozšířené na správnou šířku pro daný přístup). Správné zacházení s mmap() v těchto situacích zůstává otevřenou otázkou, která nemá na současných systémech podporujících revoke() precedens – revoke() na BSD funguje jen u zařízení, kde není mapována paměť.

Mezi příspěvkem typu RFC s dobrým nápadem a skutečnou, fungující implementací je slušná propast; může se proto stát, že i tento pokus o revoke() skončí nešťastně jako jeho předchůdci. Skutečnost, že Linux nemá fungující revoke(), je už roky vnímána jako jeho nedostatek; proto by bylo hezké, kdyby se to konečně podařilo dát dohromady. Tak to třeba tentokrát vyjde.

       

Komentáře

[Honz]

Jádro 3.8.6 je bezva...

[Xerces]

Bezva jako bezvadné, tj. bez vady? To by bylo bezva.

[Rovano]

Proč nemáš 3.8.8? Když už inovace...

[stativ]

Až na to, že pak už by to nebylo bezva, protože byla odstraněna podpora i386, ne i388.

[marek_hb]

jo jo - je - přestala mi fungovat jedna síťovka a u druhé klesla rychlost na 10% původní

jupí - to je paráda :)

[Franta]

V té licenci k NWFPE jde o tohle?

USE OF THIS SOFTWARE IS RESTRICTED TO PERSONS AND ORGANIZATIONS WHO CAN AND WILL TAKE FULL RESPONSIBILITY FOR ANY AND ALL LOSSES, COSTS, OR OTHER PROBLEMS ARISING FROM ITS USE.

IMHO to zní dost nebezpečně brát na sebe plnou zodpovědnost za všechny ztráty/škody a náklady způsobené použitím softwaru. Co když něco takového dodám zákazníkovi a on se se mnou bude soudit? Pak bych asi musel platit víc, než bych normálně čekal.

[luky]

Kdyz to dodate zakaznikovi, tak tu odpovednost prebira on, provozovatel.

[Franta]

A co když mu to dodám formou ASP/SaaS? Navíc podle českého práva je užitím díla mj. právo na rozmnožování díla, právo na rozšiřování originálu nebo rozmnoženiny díla, právo na pronájem originálu nebo rozmnoženiny díla…

[BFU]

Cele to NWFPE a VFP je kravina, RMK se jenom opet docasne zblaznil a lze to ignorovat.