Jaderné noviny – 4. 8. 2011: Řešení poškození dat v kódu NFS

15. 8. 2011 | Luboš Doležel | Jaderné noviny | 3447×

Aktuální verze jádra: stále 3.0. Citáty týdne: třikrát Linus Torvalds. Začleňovací okno jádra 3.1, část druhá. Sledování života SKB fragmentů.

Obsah

• Aktuální verze jádra: stále 3.0
• Citáty týdne: třikrát Linus Torvalds
• Začleňovací okno jádra 3.1, část druhá
• Sledování života SKB fragmentů

Aktuální verze jádra: stále 3.0

Začleňovací okno pro Linux 3.1 je stále otevřené. Čtěte níže pro shrnutí, co bylo zařazeno během posledního týdne.

Stabilní vydání: Linux 2.6.35.14 z řady s dlouhou údržbou byl vydán 1. srpna.

Stabilní jádro 2.6.39.4 vyšlo 3. srpna: Upozorňuji, že toto je POSLEDNÍ vydání v řadě 2.6.39. Všichni, co používají 2.6.39, by se teď měli přesunout na verzi 3.0. Údržba tohoto stromu skončila, zařiďte se prosím podle toho.

Stabilní jádro 3.0.1 je v současnosti ve stavu posuzování. Jeho vydání se dá očekávat 5. srpna nebo později.

Citáty týdne: třikrát Linus Torvalds

A je úplně fuk, jestli řeknete něco jako „No, ale já používám quilt, takže tam to bylo otestováno a já jsem teď naimportoval jeden velmi dobře otestovaný strom do -git, abych vám jej poslal.“ Krucinál, i když používáte quilt nebo něco jiného pro údržbu vašich sad patchů, VÍM ZATRACENĚ DOBŘE, ŽE JSTE JI NEOTESTOVALI NAD NEDÁVNÝM MIZERNÝM PŘETAŽENÍM NFS!

Takže jestli používáte quilt nebo něco jiného, tak svou sadu patchů naimportujte do něceho STABILNÍHO A ROZUMNÉHO. Začněte na vydané verzi 3.0, ta alespoň nemá náhodná přetažení, která mají známé problémy s kompilací. Použijte to k testování a neposílejte mi rebasnuté sady patchů, které jednoznačně nemohly být otestovány v této podobě a jsou postavené na jádře, které má ošklivé problémy.

-- Linus Torvalds (obsahuje další dávky rozmrzelostí)

Takže konflikty nejsou samy o sobě „špatné“. Chci je vidět, protože jsou pro mě jakýmsi varováním: zatímco individuální konflikt nemusí být nezbytně problémem, je to něco, čeho si chci být vědom.

Tudíž si nestěžuju – nebo mi to nepřijde znepokojivé – že tam byl konflikt. Tak to prostě chodí. Ale nechci, aby tyto konflikty podřízení správcové odstranili sloučením.

-- Linus Torvalds

Takže abych řekl pravdu, myslím si, že ten patch diskvalifikuje sám sebe. Nepřetáhnu něco, co má vyčistit věci, a přitom to přidává škaredosti na jiném místě.

-- Linus Torvalds

Začleňovací okno jádra 3.1, část druhá

Od posledního článku o začleňování kódu bylo do hlavní řady přetaženo kolem 1400 neslučovacích změn. To dává v době psaní tohoto článku celkem 6844 sad změn od verze 3.0. Linus Torvalds je stále na dovolené a počty začlenění jsou oproti předchozím vydáním o něco nižší, takže možná jich ještě dost přijde. Významné uživatelem zaznamenatelné změny zahrnují:

• Cíl iSCSI [iSCSI target] LIO byl zařazen.
Toto je poněkud kontroverzní, jednak proto, že soupeřící implementace cíle SCST byla odstrčena ve prospěch LIO, ale také protože zde byly pochyby o tom, jestli má být autentizace CHAP dělána v jádře, nebo v uživatelském prostoru. Navzdory námitkám Jamese Bottomleyho byla začleněna verze, která dělá autentizaci v jádře.
• pNFS nyní podporuje IPv6.
• eCryptfs má nyní podporu pro šifrované klíče.
• md má nyní podporu pro správu vadných bloků.
• Bylo přidáno tools/power/cpupower s nástroji pro monitorování správy výkonu u vícero architektur. Nakonec to nahradí nástroje specifické pro Intel v tools/power/x86.
• dm nyní podporuje oddělená zařízení pro metadata pro lepší ošetřování selhání a kontrolu funkčnosti pole.
• Nově podporovaný hardware zahrnuje:
  • Audio/video: kodeky Cirrus Logic CS421x, tunery Xceive XC4000, ATMEL Image Sensor Interface (ISI), USB snímací zařízení Endpoints SE401, integrované řadiče snímacích zařízení Marvell Armada 610, tunery NXP TDA18271c2, backendy pro zpracování videa TI DM644x, videozařízení rodiny Samsung S5P, senzory OmniVision OV5642, demodulátory Micronas DRX-K DVB-C/T.
  • Různá zařízení: akcelerometry Freescale MMA8450, tříosé gyroskopické senzory InvenSense MPU3050, akcelerometry Kionix KXTJ9, hlídací [watchdog] časovače Xilinx, řadiče LED blesků ADP1653, přemosťovací zařízení Digital Devices Octopus, teplotní senzory Maxim MAX1668 a kompatibilní, teplotní senzory NTC NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473 a NCP15WL333, dvojité teplotní senzory National Semiconductor LM95245, senzory pro správu, monitorování, řízení výkonu a ochranu National Semiconductor LM25066, LM5064 a LM5064, nabíječky baterií Maxim MAX8998/LP3974 PMIC a Maxim MAX8997/MAX8966 PMIC, čipy pro správu výkonu TI TPS95612, regulátory výkonu TI TPS65912, podsvícení AnalogicTech AAT2870, regulátory výkonu AnalogicTech AAT2870, DMA řadiče Cirrus Logic EP93xx.

Změny viditelné vývojářům jádra zahrnují:

• Několik ARM SoC a ovladačů zařízení má podporu stromů zařízení.
• Bylo přidáno jádro ovladačů hlídacích [watchdog] časovačů.
• SLUB slab alokátor už v průběhu rychlé cesty kódu nevyžaduje zámky na architekturách, které podporují cmpxchg.
• Non-volatilní úložiště EFI může být nyní použito jako backend pro pstore pro trvalé ukládání zpráv z logu nebo jiné informace.

Jednou významnou sadou patchů, která nebude tentokrát zařazena, je Nativní linuxový nástroj pro KVM. Torvalds se rozhodl, že pro zařazení je ještě nutné jej přesvědčit.

Budete mě ještě muset přesvědčit, že to za to stojí, když vezmu v úvahu, že už teď *můžete* dělat testování jádra pomocí existujících virtualizačních prostředí, která jsou v ostatních ohledech mocnější. Ale k tomu, obávám se, dostanete příležitost až během příštího začleňovacího okna.

Už jsem se rozhodl přetáhnout jednu kontroverzní věc (to kolem iscsi-target), nebudu dělat během jednoho začleňovacího okna dvě ;)

Obvyklé dvoutýdenní začleňovací okno by normálně skončilo 5. srpna, ale Torvaldsova dovolená s tím může zahýbat (oběma směry). Příští týden se podíváme na další důležitá přetažení, bude-li k tomu důvod.

Sledování života SKB fragmentů

V květnu se v Jaderných novinách zkoumal patch „stabilních stránek“, jehož cílem je zajištění, že stránky pod probíhajícím I/O nemohou být upravovány (jádrem nebo uživatelským prostorem), dokud se I/O nedokončí. Blokové I/O ale není jediným kontextem, ve kterém se tento typ problému objevuje; paměť, která byla dána síťovému stacku by rovněž měla být stabilní, dokud se přenos nedokončí. Bohužel je těžké zjistit, kdy síťový stack skutečné dokončil práci se stránkou, což ponechává systém náchylný k možným poškozením dat.

Ian Campbell v červnu popsal, jak se mohou věci pokazit. Představte si stránku plnou dat, která má být zapsána do souboru na souborovém systému připojeném přes NFS. Kód NFS sestaví síťovou I/O operaci reprezentovanou strukturou sk_buff („SKB“) a předá ji síťové vrstvě pro odeslání. Třeba je server pomalý nebo je v síti nepodřádek; tak či tak přicházejí od vzdáleného NFS serveru potvrzení pomalu – tak pomalu, že se síťová vrstva rozhodne odeslat požadavek znovu. Zatímco data čekají ve frontě pro opětovné odeslání (třeba už byla předána ovladači rozhraní), od serveru přišel ACK (potvrzení). Síťová vrstva řekne NFS klientovi, že operace byla dokončena. Stránka, která byla použita pro odeslání dat, by pak mohla být přepsána jinými daty – ačkoliv opětovné odeslání dat ještě nebylo provedeno. To by mohlo vést k (opětovnému) odeslání poškozených dat. Tento problém je obzvláště akutní u zápisů O_DIRECT – kde aplikace čeká na dokončení operace – ale může se objevit i jindy.

SKB mohou mít destruktor, takže by si člověk mohl myslet, že stačí počkat, dokud síťová vrstva nedokončí práci se strukturou před uvolněním dotčených stránek (stránky). Ale síťová vrstva funguje podivným a záhadným způsobem a skutečnost, že dokončila práci se SKB, neznamená, že dokončila práci s daty odkazovanými v SKB. V síťové vrstvě často dochází ke „klonování“ SKB a stránky dat se mohou dokonce přesouvat mezi SKB. Síťový kód spravuje počty referencí přímo, takže zde není riziko, že by stránky byly systémem použity k něčemu jinému. Ale toto nepomáhá vyšším vrstvám, které nemají jak zjistit, kdy už je bezpečné oznámit dokončení operace.

Vyřešení tohoto problému vyžaduje významné změny v nízkoúrovňovém kódu pro práci se SKB. Ianova sada patchů začíná definicí několika pomocných funkcí pro sledování referencí stránek z SKB. Aktuální síťový kód volá get_page() a put_page() přímo; po opatchování budou tato volání obalena funkcemi jako skb_frag_ref(). Pro to, aby jádro síťového kódu a kód ovladačů používaly tyto funkce, je nutných docela dost změn.

Jakmile je toto hotové, sada patchů zavede koncept „fragmentových destruktorů“ v SKB:

struct skb_frag_destructor {
	atomic_t ref;
	int (*destroy)(void *data);
	void *data;
};

Nízkoúrovňové funkce, které přidávají fragmenty do SKB, jsou upraveny, aby přijímaly dodatečný argument s destruktorem. Destruktor je vždy volitelný; kód, který nepotřebuje používat destruktory, může prostě předat nulový ukazatel.

V tento moment je pro přístupové funkce přidané dříve v této sadě patchů snadné inkrementovat a dekrementovat počty referencí, jakmile jsou přítomny destruktory. Jakmile se počet referencí (ref) dostane na nulu, bude zavolána poskytnutá funkce destroy(). Přidání počítadla referencí do destrukturou je užitečná optimalizace: při nepřítomnosti destruktorů může být režie spojená s údržbou počtu referencí přeskočena. Stojí taktéž za zmínku, že vícero segmentů v SKB může sdílet tentýž destruktor; v tomto případě bude funkce destroy() zavolána, pouze pokud síťový kód dokončil práci se všemi těmito fragmenty.

Další optimalizací je to, že při přítomnosti destruktoru už nebude síťový kód inkrementovat a dekrementovat počty referencí spojené se stránkami ve fragmentech. V této situaci se předpokládá, že volající kód bude držet referenci po dobu operace, takže oddělené počítání referencí na této úrovni není potřeba.

Posledním krokem je využít těchto schopností. Interní funkce kernel_sendpage() získá extra parametr pro ukazatel na destruktor, pokud by volající funkce chtěla nějaký použít. Kód sunrpc je přepracován tak, aby nesignalizoval dokončení operací, dokud síťový kód neindikuje, že dokončil práci s dotčenou pamětí. A to řeší celý problém – alespoň pro NFS; už by se neměly objevovat potíže se znovupoužíváním stránek, zatímco jsou stále pod probíhajícím síťovým I/O. V jádře jsou další místa, která mohou – a asi také budou – tuto funkčnost v budoucnu využívat; tato práce byla původně motivována problémy, na které se narazilo při implementaci nekopírovaného [zero-copy] I/O pro klienty Xenu. Ian věří, že subsystémy jako iSCSI by z tohoto mechanismu mohly taktéž profitovat.

Patch byl přijat docela dobře. V budoucnu se bude řešit reorganizace části práce, ale nyní se nezdá být nutné dělat větší změny. Tato vlastnost se pravděpodobně objeví v jádře 3.2.

       

Komentáře