Kernel Traffic #172 For 2002/06/24

STOP!

Co to za szaleństwo?

Jest dostępne cholerne wołanie systemowe muteksa, nie wprowadzaj śmieci do /dev.

Czy potoki tworzymy przez otwieranie /dev/pipe? Nie. Czy używamy głównych i pobocznych numerów gniazd i wiążemy z nimi /dev? Nie. W wyniku takiego postępowania _nigdy_ nie było z obydwoma żadnych problemów administratorskich.

_Niezależnie_ od wszystkiego, musisz mieć wołanie systemowe wiążące konkretny deskryptor z futeksem, zatem zrób jedynie słuszną rzecz: zaalokuj _tu_ deskryptor i pozbądź się tego głupiego i okropnego /dev/futex, które przysparza Ci tylko kłopotów, utrudnia amdinistrację systemem, wymaga dodatkowego kodu i dzięki któremu dostaniesz oznaczenie za głupotę.

Podajcie mi _jedną_ zaletę sytuacji, w której to coś jest eksponowane jako nazwa pliku?

Cała sprawa z hasłem ,,wszystko jest plikiem'' nie polega na tym, że mamy pewne losowe nazwy plików (gniazda i potoki pokazują naprawdę, że ,,plik'' i ,,nazwa pliku'' nie mają ze sobą nic wspólnego), ale na fakcie, że możemy używać tych samych operacji na różnych rzeczach.

Ale nie ma absolutnie żadnego powodu, by otwierać /dev/futex z poziomu skryptu powłoki czy czegoś podobnego, bo to nic nie daje. Cały czas musicie wiązać deskryptor z prawdziwym obiektem.

W skrócie, nazwa ,,/dev/futex'' (albo ,,/proc/futex'') nie ma _żadnego_ znaczenia. Nie ma sensu tego robić. Nic się nie dzieje pomiędzy wołaniami FUTEX i jedyna rzecz, którą można osiągnąć przez wyeksponowanie tego jako nazwy, to spowodowanie problemów ludziom, którzy nie chcą montować /proc albo tym, którzy akurat nie mają takiego urządzenia w swoim /dev.

Nie sądzę, żeby był to problem wycinania czegokolwiek, bardziej jest to chyba problem próbowania współdzielenia pewnego kodu. pipefs, sockfs, a teraz to: wszystkie one robią w dużej części dokładnie to samo i nie ma nic, co mówiłoby, że powinny mieć one na przykład oddzielne super_operations, jako, że są identyczne.

Kiedy mamy te same super_operations, mamy także naprawdę te same funkcje ,,fill_super''. Jedyna rzecz, która dzieli te superbloki to nazwa, tak żeby w /proc było ładnie. Zatem w porządku byłoby mieć po prostu

>sb = create_anon_fs("futex");

i dzielić cały kod struktury między futeksami/potokami/sockfs.

Co wciąż pozostawia Ci:

get_unused_fd();
get_empty_filp();
filp->f_dentry = dget(sb->s_root);
.. wypełnij ..
fd_install(fd, filp);

ale wtedy mówimy o pojedynczych linijkach narzutu.

nie chodzi o to, że przy ,,exit()'' zmieni się wydajność, ale przede wszystkim dlatego, że NIE ŚLEDZIMY BLOKAD w jądrze.

W tej chwili jądro nie wykonuje _żadnej_ pracy nad blokadami, które nie są w konflikcie. Nie wie _nic_ o procesie, który pierwszy zastosował blokadę.

Każde śledzenie byłoby _ekstremalnie_ drogie. Obecnie pobranie niekonfliktującej blokady zabiera około 15 cykli procesora w przestrzeni użytkownika.

Próba poinformowania jądra o założeniu takiej blokady zabiera około 1us na P4 (narzut na wołanie systemowe), tzn. mówimy o 18000 cykli. Minimum 18 TYSIĘCY cykli. W porówaniu z obecnymi 15. To więcej niż trzy rzędy wielkości wolniej niż w obecnym kodzie, a przede wszystkim traci się cały powód robienia czegoś takiego w przestrzeni użytkownika.

O, zgadzam się, możesz debugować blokady w przestrzeni użytkownika, ale to nie jądro będzie to robić, za to będzie zależeć od czegoś w stylu: ,,jeśli blokada się przeterminuje, to mogę bezpośrednio sprawdzić, czy ten, kto ostatnio ruszał tę blokadę (którego ID wątku zostało zapamiętane w pamięci po pobraniu blokady) ciągle działa i spróbować po nim posprzątać''.

W ten sposób działa sporo kodu blokowania w systemie plików, oczywiście dla rzeczy w /var/lock/xxx.

Nie ma potrzeby angażowania w to jądra.

Ale to musi zależeć od dobrego zachowania wszystkich wątków, które biorą udział w blokowaniu.

Od jakiegoś już czasu chciałem znaleźć sposób na to, aby program mógł stwierdzić, czy któryś z buforów gniazd jest przepełniany ze względu na zbyt duży ruch przychodzący. W końcu zdecydowałem się to zakodować i wypróbować.

Okazuje się, że było to dość proste do dodania, choć wymagało to dodania dwóch nowych pozycji do sockios.h.

Najprościej mówiąc, wewnątrz sock_queue_rcv_skb() i sock_queue_err_skb() licznik odbiornika jest zwiększany bezwarunkowo, a póżniej, jeśli nie ma miejsca w buforze gniazda, zwiększamy także licznik dla wiadomości odrzuconych ze względu na brak pamięci.

Statystyki są przechowywane jako część struktury socket_stats, co czyni możliwym dodanie innych liczników w przyszłości.

Dodałem dwa polecenia ioctl do gniazda ioctl w celu dostępu i zerowania licznikół. GIOSOCKSTATS jest wykorzystywane do dostępu do statystyk, a SIOCZEROSOCKSTATS jest przeznaczone do zerowania. Nie próbowałem nawet zerować ich niepodzielnie, ale nie sądzę, aby to było krytyczne.

Łata została zapisana i przetestowana dla 2.4.18, ale powinna przynajmniej się aplikować (z przesunięciami) do 2.5.20.

Linuksowy styl kodowania _stara_ się unikać używania typedef. To nie jest żelazna zasada (i tak naprawdę zaaplokowałem tę łatkę, bo z drugiej strony wyglądała w porządku), ale dość powszechnie używa się explicite ,,struct xxxx'' zamiast ,,xxxx_t''.

Nie lubię abstrakcyjnych typów, jeśli nie ma ku temu prawdziwych powodów. Oszczędzanie na pisaniu typów nie jest wystarczającym powodem - jeśli prędkość pisania na klawiaturze jest głównym problemem w trakcie kodowania, to robisz coś naprawdę źle.

(Podobnie, jeśli próbujesz kompresować linie tak, by były krótsze, to masz inny problem, który nie ma nic wspólnego z nazwami typów).

Czy kod wygląda ,,ładniej'' z ,,_t'' niż ze ,,struct ''? Nie wiem. Osobiście tak nie uważam, nienawidzę też konwencji ,,_p'' (a jeszcze bardziej samego ,,p'') przy oznaczaniu wskaźników.

Ukrywanie faktu, że coś jest strukturą ma złe skutki, gdy ludzie nie zdają sobie z tego sprawy: alokowanie struktur na stosie jest czymś, czego powinniście być świadomi (i uważnie używać), przy przekazywaniu ich jako paramtrów funkcji lepiej pisać wyraźnie, że jest to ,,wskaźnik do struktury''.

Są _pewne_ wyjątki. Na przykład, "pte_t" itp. może swobodnie być strukturą na większości architektur i to jest w porządku: jest wyraźnie zaprojektowana by być nieprzezroczystą (i ciągle dość małą) rzeczą. To jest przykład, w którym są jasne _powody_ abstrakcji typu, nie abstrakcji dla samej siebie.

Ale najbardziej liczy się decyzja opiekuna. Osobiście nie chcę żeby zwyczaj typedef się rozprzestrzenił, ale nie przeszkadza mi, gdy jest tego trochę, a ludzie, którzy opiekują się własnym kodem zwykle mają tu ostatnie słowo.

Cóż, to więcej niż tylko ,,struct xx''. To dotyczy ogólnie typedef.

Na przykład, niektórzy ludzie lubią pisać takie rzeczy:

typedef unsigned int counter_t;

a potem używają ,,counter_t'' we wszystkich miejscach. Moim zdaniem to jest nie tylko okropne, ale też głupie i nieproduktywne. To powoduje, że trudniej jest pisać w sposób przenośny rzeczy takie, jak na przykład ,,printk()'' (,,powinienem użyć %u, %l, czy po prostu %d?'') i ogólnie nie daje żadnej nowej wartości. To tylko _ukrywa_ informację, czy ten typ jest ze znakiem, czy bez.

Nie ma nic złego w używnaniu po prostu czegoś takiego, jak ,,unsigned long'' bezpośrednio, nawet jeśli jest to o parę znaków dłuższe niż by się chciało. A jeśli naprawdę przejmujesz się liczbą wykorzystywanych bitów, używaj ,,u32'' albo czegoś takiego. Nie twórzcie bezużytecznych typów, z których nie ma dodatkowych korzyści.

Tak naprawdę to przez takie rzeczy zdarzają się prawdziwe _problemy_, gdy ludzie używają ,,off_t'', czego nie można łatwo potraktować ,,printk'' na różnych architekturach (ten sam problem był z size_t). Powinniśmy byli po prostu używać ,,unsigned long'' (i ,,unsigned long long'' dla loff_t) w jądrze i byłby spokój.

Powinniśmy też byli mieć jeden format dla wypisywania ,,u32/u64'' itp, ale to już inna kwestia i problem polegający na tym, że gcc tego nie zrozumie, zatem dodawanie nowych formatów jest _ciężkie_ z punktu widzenia opiekunów kodu.

PS. I nigdy _przenigdy_ nie róbcie ,,wskaźnikowania'' częścią typu. Ludzie, którzy piszą:

typedef struct urb_struct * urbp_t;

(czy jak tam to się nazywało) powinni być zastrzeleni. Byłem _bardzo_ szczęśliwy, gdy zobaczyłem, że usunięto te śmieci z jądra, ze sterowników USB.

Nie istnieje coś takiego jak nierekursywne rozwiązywanie linków symbolicznych.

Przechodzenie po dowiązaniach symbolicznych jest z natury rekursywne, ponieważ musimy móc przejrzeć dowiązanie symboliczne w środku innego.

Zatem albo jest rekursywne w C (wołający w końcu sam siebie woła), albo rekursja jest ręcznie linearyzowana (funkcja wołająca ręcznie śledzi zawartość stosu używając list albo przez rozwiązywanie nazw ścieżek w miejscu albo coś, zamiast używania stosu C).

Obydwa sposoby sa rekursywne, jedyna kwestia tu to to, czy rekursja jest obsługiwana przez język czy ręcznie i czy stan tymczasowy jest trzymany na stosie, czy explicite w strukturach danych.

Nie widzę żadnych korzyści z obsługiwania tego ręcznie, ponieważ nie jest to nawet bardzo głęboka rekursja i ponieważ nawet jeśli wykonasz rekursywną część ręcznie, przy użyciu listy, _ciągle_ potrzebujesz ograniczać jej głębokość, by zapobiec atakom DoS.

Tak naprawdę to unikamy zbyt głębokiego śledzenia linków symbolicznych, nawet w _nierekursywnym_ przypadku (zobacz ,,total_link_count'') właśnie z powodu problemu z DoS.

Czy moglibyśmy pozwolić na głębszą rekursję, jeśli robilibyśmy to ręcznie? Jasne. Czy są jakieś realne zalety posiadania 15 poziomów rekursji nad 5 poziomami? Ja nie widzę żadnych.

Problem spowodowany jest rekursywną wycieczką przez system plików. Nagłe zużycie przestrzeni na stosie wynosi (N * najbardziej_zachłanny_system_plików) i musi być dopasowany do obliczeń w najgorszym przypadku. To wielka dziura w tym ściśle zastrzeżonym zasobie, więc redukcja N do 1 jest warta świeczki.

Co więcej, z praktycznych względów znacznie łatwiej jest ustanowić zasadę dla deweloperów systemu plików, która mówi: ,,nie należy w żadnym przypadku użyć więcej niż N bajtów na stosie na najdłuższej ścieżce'' zamiast ,,w żadnym przypadku nie używaj więcej niż N bajtów stosu, z wyjątkiem ścieżki rozwiązywania dowiązań symbolicznych, w którym to przypadku sprawdź limit rekursywnych dowiązań symbolicznych, by wiedzieć jak przeanalizować ścieżkę''.

Tak naprawdę sama wycieczka po systemie plików nie jest rekursywna. W danej chwili _aktywne_ jest tylko jedno poszukiwanie, więc głębokość stosu jest całkiem nieźle ograniczana. Wydaje mi się, że w pewnym momencie była rzędu 64 bajtów na wołanie na x86. Nie wygląda to tak źle, jak ludzie sobie to wyobrażają.

(Ale tak, x86 ma gęstszy stos niż wiele innych architektur)

Nie mam nic przeciwko temu, żeby ludzie testowali łatkę Andriesa, nie _obchodzi_ mnie to. Kłócę się mniej o samą łatkę, a bardziej o _religijną_ i bezmyślną reakcję na doskonałą konstrukcję programistyczną (ograniczoną rekursję).

PS. Tak, system plików może robić głupie rzeczy i sprawiać, że funkcja na pierwszym poziomie wołań ma ogromny stos: przykład był dla normalnego ,,page_symlink''.

W poprzednim liście chciałeś się bawić semantycznymi sztuczkami ze słowem rekursywny, choć świetnie rozumiałeś co miałem na myśli pisząc ,,nierekursywny'' (i sam używałeś tej samej terminologii we wcześniejszych listach).

Teraz się waham, czy powinienem reagować na powyższe stwierdzenia. Być może tym razem są to semantyczne sztuczki ze słowem aktywny, ale wygląda to trochę tak, że nie zrozumiałeś całej sytuacji.

Pozwól mi przedstawić fakty, zamiast martwić się o semantykę.

Procedura link_path_walk() w namei.c będzie wołała do_follow_link() w przypadku dowiązania symbolicznego, a ta procedura wywoła dentry->d_inode->i_op->follow_link(), powiedzmy, nfs_follow_link(), które zawoła calls vfs_follow_link(), które znowu będzie wołało link_path_walk(), itd.

Możesz teraz zobaczyć, że na stosie N wołań znajduje się także N ramek z foofs_follow_link(). Zatem, tak, w sposób w który używam słowa rekursywny, procedury takie jak nfs_follow_link() są naprawdę rekursywne: w końcu wołają same siebie.

Zeszłej niedzieli, czy coś koło tego, podałem łatkę demonstracyjną, która przenosi systemy plików poza pętlę. Wtedy rozwiązywanie odwołań symbolicznych jest ciągle rekursywne, ale liczba wołań foofs_follow_link() spadnie do co najwyżej jednego.

Wczoraj pokazałem, że równie łatwo jest zapobiec rekursji w ogóle.

To są zupełnie niezależne stadia, ktoś mógłby rozważyć wykonywanie jednego, a drugiego nie.

Tak. Ale czy przyjrzałeś się ramkom stosu tych rzeczy? To jest mniej więcej 16 bajtów dla ext2_follow_link (bo to po prostu bezpośrednio woła coś z warstwy VFS), 20 bajtów dla vfs_follow_link() i 56 dla link_path_walk.

(tia, to oczywiście nie są tylko 64 bajty tylko 92. Może po prostu źle policzyłem zeszłym razem. Albo może link_path_walk jest inne).

O, i sądzę, że prawdziwe ->follow_link wrzuca na stos 8 bajtów argumentów.

Zatem rekursja o głębokości 5 zabiera ~500 bajtów przestrzeni na stosie.

O to mi chodzi: _jedyna_ różnica między ,,bezpośrednią rekursją'' a ,,ręczną rekursją'' polega na tym gdzie i jak trzymamy te pośrednie bajty. Można pozwolić kompilatorowi, żeby zrobił to za Ciebie, nie ma w tym nic z gruntu ,,diabelskiego''.

I jak to sam zauważyłeś, ograniczenie rekursji do 5 poziomów to naprawdę znacznie więcej niż ludzie zwykle używają.

Ale hej, ludzie, jeśli chcecie linearyzować rekursję, to łatwo mnie przekonać liczbami. Zrobiłem kiedyś pomiary wykorzystania stosu (właśnie dlatego, że jakiś czas temu się o to martwiłem) i nie zmartwiły mnie liczby, które uzyskałem. Nie martwi mnie też liczba ,,5'', po prostu dlatego, że _nigdy_ nie dostałem żadnej skargi na to, przynajmniej żadnej nie pamiętam.

Są jednak inne liczby, na przykład wydajność (czasem linearyzacja rekursji przegrywa, czasem wygrywa), albo ktoś wykonujący obliczenia na ia-64 i pokazujący, że 100 bajtów na poziom na x86 daje naprawdę mniej więcej tyle co 2kB na ia-64 i jest zupełnie nieakceptowalne.

Ale próba sprzedania mi tego czegoś pod hasłem ,,rekursja jest zła i musi być stłumiona'' po prostu się nie uda.

Zdałem sobie sprawę, że prawdopodobnie nie zrozumiałeś całej sprawy. Odbyła się dyskusja na temat dużych zmiennych na stosie odnalezionych przez Checkera i o tym, jak Checker mógł mieć trudności uzyskując maksymalny rozmiar stosu właśnie w trakcie tej rekursji.

Zauważyłem, że usunięcie tej rerkusji jest trywialnym zadaniem, jeśli kogoś to interesuje, ale Al nazwał takie stwierdzenia nieprawdziwymi, więc trzy dni temu wykonałem połowę pracy (usuwając systemy plików z pętli), a Al napisał, że to jeszcze nic, prawdziwe usunięcie rekursji byłoby piekłem. Zatem usunąłem tę rekursję wczoraj wieczorem. Projekt w wersji demonstracyjnej.

(A Ty znalazłeś się w cc: tylko dlatego, że zauważyłem coś, co wydawało mi się drobnym błędem przy zliczaniu odwołań w obecnym kodzie.)

Nie miałem żadnego sygnału od Ala do tej pory, ale po cichu żywię nadzieję, że niedługo wróci i napisze mi, że mój kod jest obrzydliwy i zawiera siedemnaście błędów, ale on to zrobił poprawnie, kodując to elegancko, a kod jest szybki i łatwo się nim opiekować.

W międzyczasie, nie, to nie było przesłanie łatki, pokazałem to, by wywołać dyskusję i jeszcze dlatego, że Al chciał zobaczyć kod.