Kernel Traffic po polsku #120 For 28 May 2001

Ext2 wykonuje getblk+wait_on_buffer dla nowych bloków metadanych zanim je wyzeruje. Dla systemów jednoprocesorowych wszystko jest w porządku, ale w systemach SMP możemy mieć do czynienia z następującym przeplotem zdarzeñ:

	CPU1	CPU2
getblk zwraca niezablokowane i niezainicjalizowane bh wait_on_buffer() nic nie robi
	czyta z urządzenia, blokuje je i rozpoczyna operacje We/Wy
zerujemy.
	dane dyskowe nadpisują nasze zera
zaznaczamy jako brudne bdflush zapisuje stare dane (_nie_ zera) z powrotem na dysk.

Wynik: śmieci w bloku metadanych. Proponowane rozwiązanie: lock_buffer()/unlock_buffer() dookoła memset()/mark_buffer_uptodate() zamiast wait_on_buffer() przed nimi.

Przypuśćmy, że root.disks jest właścicielem /dev/hda1 i uprawnienia do /dev/hda są ustawione na 640. System plików jest zamontowany w trybie rw.

Proces foo należy do pfy.staff. PFY należy do grupy disks, ale nie ma uprawnieñ superużytkownika. Twierdzę, że PFY może spowodować uszkodzenie systemu plików na /dev/hda1.

W tej chwili foo _może_ spowodować takie uszkodzenie, nawet jeśli nie posiada praw do zapisu do urządzenia.

Moim zdaniem to jest nieprawidłowe zachowanie. Ale nie twierdzę, że to jest rzeczywiste zagrożenie. Nie twierdzą, że PFY nie jest idiotą ani że jego zachowanie ma jakiś sens. Uważam, że sytuacja, w której może doprowadzić do takie sytuacji nie posiadając praw do zapisu do urządzenia jest niedopuszczalna.

Uważam, że wszystkie te argumenty nie mają większego sensu. Robienie takich rzeczy jak zrzut działającego systemu plików jest głupie i niebezpieczne (moim moim zdaniem _w ogóle_ robienie zrzutu jest głupie i niebezpieczne, ale to temat na oddzielną dyskusję), i tak naprawdę nie ma powodów żeby otwierać urządzenie blokowe, podczas gdy jest ono zamontowane. Co ważniejsze, nie sądzę, aby ktokolwiek tak robił.

Fakt, że _można_ coś takiego zrobić, powoduje poprawność łaty i zgadzam się z Alem co do kwestii "braku niespodzianki". Łatę już zaaplikowałem. Ale nikt nie powinien nigdy robić rzeczy, które mogą spowodować takie problemy.

Mam identyczne problemy od wersji 2.4.0. Mimo że sytuacja nieco się poprawiła w jądrze 2.4.4, to system dalej się zawiesza. Wygląda na to, że problem jest związany z zarządzaniem pamięcią i/lub swapem i występuje głównie na maszynach, które mają powyżej 128MB RAM-u. Niestety, nie przeprowadziłem dokładnych testów, żeby potwierdzić tę tezę.

Obserwowałem zużycie pamięci i zauważyłem, że coraz więcej swapu jest zużywane i nie jest on w ogóle zwalniany. Mogę zabić większość dużych aplikacji, takich jak netscape czy xemacs, a wielkość dostępnej pamięci i swapu wcale się nie zwiększa. Gdy po paru dniach swap się zapełnia, maszyna zawiesza się.

Gdy wyłączam swap zanim się wypełni, żeby go oczyścić i potem ponownie go włączam, system działa stabilnie.

Moja maszyna to AMD K6-400 z 256 MB RAM-u, ale na innych maszynach ten problem też występuje.

Jak pewnie większość z was wie, kilka tygodni temu zebraliśmy baty za naszą politykę dotyczącą tworzenia łat na jądro Linuksa, która spowodowała różnice pomiędzy kodem LVM zawartym w oficjalnym wydaniu jądra, a tym, które ostatnio wypuściliśmy.

Aby zapobiec tym różnicom, będziemy udostępniać mniejsze łaty, ale częściej. Już zaczęliśmy to robić publikując zbiór około 50 niezbędnych łat.

Mimo uprzejmości i pomocy Alana Coxa, upłynie kilka tygodni zanim uda się włączyć cały kod do jądra.

Powstaje problem. Próby uniknięcia dalszych niezgodności pomiędzy naszą wersją LVM, a tą z jądra Linuksa spowoduje opóźnienie w ukazaniu się LVM 1.0, co jest nieakceptowalne przez użytkowników LVM.

W tej sytuacji, chciałbym poznać wasze zdanie w kwestii, czy jest do zaakceptowania, wypuścić wersję 1.0, *zanim* wszystkie łaty z 1.0 zostaną zaaplikowane do jądra (zakładając, że będziemy je udostępniać tak jak dotychczas)?

Będziemy czekać na odpowiedzi przez kilka dni i potem prześlemy naszą decyzję na listę.

Ta łata poprawia błąd w funkcji autoconfig_startech_uarts z pliku serial.c Problem polega na tym, aby wykryć XR16C850 i XR16C854 do rejestrów szybkości przesyłania danych zapisywane są zera. To powoduje, że Exar ST16C654 głupieje. Zapisanie i odtworzenie rejestrów szybkości przesyłu danych rozwiązuje problem.

Zakładam, że wykrywanie XR16C85[04] działa poprawnie i nie wymaga odtwarzania oryginalnej wartości szybkości przesyłu. Jeśli się mylę, poprawię łatę.

Linus Torvalds wystosował moratorium na temat przypisywania numerów nowym urządzeniom. Linus ma nadzieję, że uda się dojść do nowej i lepszej metody zarządzania numerami urządzeñ.

Alan Cox poprosił mnie abym zechciał zająć się bazą w jego gałęzi -ac. Zgodziłem się na tę propozycję, więc przestaję pracować nad bazą z jąder Linusa. Teraz pracuję nad -ac i bądźcie cierpliwi do czasu aż skoñczę z backlogiem.

Zauważcie proszę, że to nie moja decyzja (tak naprawdę to mam co do niej duże obawy). W szczególności, będę nadal nadzorował przestrzeñ nazw w /dev.

Oto moja propozycja rozwiązania.

Przebrnąłem już przez problemy ze sterownikiem sieciowym i chciałbym wypuścić aktualną jego wersję. Do tego potrzebuję numeru dla urządzenia. Ponieważ lista numerów urządzeñ jest już zamknięta, zastanawiałem się, czy takie rozwiązanie mogłoby zadziałać:

Rejestruję urządzenie wykorzystując istniejące API i dostaję dynamicznie przydzielony numer. Następnie eksportuję mały ramfs, w którym mam wszystkie węzły urządzeñ. Urządzenie /dev/snap/0, zamontowane pod /dev/snap byłoby pierwszym urządzeniem blokowym dla dynamicznie przypisanego numeru snapa. (IIRC, Al Viro ma szkielet kodu dla takiego systemu plików)

To rozwiązanie

1. zapobiega wzrostowi /proc [rozważałem proc_mknod() zanim Viro mi tego nie wyperswadował]
2. nie wymaga centralnej bazy numerów urządzeñ.
3. nie wymaga devfs. większość dystrybucji, afaik, nie włącza devfs a

przełączenie się na devfs, to nie chwila-moment, i aby devfsd stał się naprawdę użyteczny.

Nawet jeśli dev_t będzie miało 32 bity (albo 64 bity), to NIE ułatwi do zarządzania uprawnieniami czy czymkowiek w żaden sposób. Popatrzcie na bałagan, który jest w /dev w tej chwili. Pomyślcie, jak by to wyglądało rząd wielkości gorzej.

Duże numery urządzeñ _nie_ są rozwiązaniem. Zaakceptuję 32-bitowe numery, ale nie większe i więcej już _nie_ zaakceptuję podejścia "zarządzania ręcznego". Trochę upłynęło czasu zanim zdecydowałem się powiedzieć "Nie". Ale powiedziałem. Jeśli nie możecie zarządzać urządzeniem automatycznie przy pomocy skryptu, z powodu swojego lenistwa, nie będziecie mieli przypisanego numeru urządzenia.

Koniec dyskusji.

Zastanawiałem się czy pracować zarówno nad jądrami z serii -ac jak i Linusa, ale to jest dobry argument, żeby pozostać przy -ac i ignorować gałąź Linusa.

Zobaczymy co będzie...

Tę decyzję podejmie czas. Linus dał nam możliwość zabrania głosu. Rzeczą, na którą się na pewno nie zgodzę jest wykorzystanie niezgodności na temat kilku drobiazgów implementacyjnych, aby usprawiedliwić większe różnice pomiędzy oboma gałęziami jądra.

Więc tak - -ac może obsługiwać statyczne numery urządzeñ, ale całą resztę chcę mieć tak zgodną z gałęzią Linusa, jak tylko się da. Na pewno nie będę ignorował jego linii.

Linus, łata to pierwsza część nowego kodu dla rootfs. Próbowałem aby była jak najmniejsza - jedyne co robi, to dodanie bezwzględnego korzenia w ramfs i niezbędnych zmian dla mount_root/change_root/sys_pivot_root i follow_dotdot. Prawdziwy korzeñ montowany jest na górze ,,bezwzględnego''.

Bardziej interesujące rzeczy znajdują się w następnych częściach. Gdy już mamy rootfs, możemy pozbyć się większości śmieci z fs/super.c dotyczących montowania prawdziwego korzenia i przechodzenia do niego po initrd. W szczególności możemy pozbyć się flagi umount_root w do_umount i kill_super(), co pozwoli na bardziej klarowną obsługę montowania vfs. Postaram się podesłać tę część w małych i czytelnych kawałkach.

Jest to przezroczyste dla przestrzeni użytkownika - jedynym widzialnym efektem jest dodatkowa linijka w /proc/mounts. Co więcej, jest to przezroczyste dla jądra - jedyne funkcje, które może czekać zmiana to te, które wykonują pierwsze montowanie.

Być może lepiej by było gdyby jedna rzecz była wykonywana nieco inaczej - ponieważ potrzebujemy rootfs przy butowaniu, zadeklarowałem w pliku fs/Config.in CONFIG_RAMFS jako define_bool CONFIG_RAMFS y. Jeśli ramfs urośnie (tzn. osiągnie granicę zasobów z łat zaaplikowanych w -ac), może będzie lepiej jeśli zaszyjemy minimalny wariant w jądrze (nazywając go rootfs) i zmienimy ramfs tak, żeby używał metod rootfs. Ale ponieważ jest to odrębna kwestia, zdecydowałem się na razie zrobić prostszą wersję.

• łata upraszcza poprawianie błędów związanych z wyścigiem procesów w fs/super.c i będziemy tego potrzebowali w 2.4 (albo przynajmniej zostanie przeniesione z 2.5 do 2.4 w pewnym momencie)
• zapewnia wsteczną zgodność.
• pozwala usunąć mnóstwo śmieci z rd.c w poprawny sposób, nie zmieniając zachowania kodu

Uważam, że łata się nadaje dla 2.4, ale ja oczywiście nie jestem obiektywny (głównie dla tego, że wiem jak dużo kodu będzie można oczyścić zachowując zgodność, włączając w to binarną zgodność na poziomie jądra). W każdym razie decyzję pozostawiam wam.

Udokumentowałem procedurę inicjalizującą jądro Linuksa na platformy x86/i386/IA-32. Dokumentacja jest dość pokaźnych rozmiarów, więc być może jest zbyt szczegółowa i będę musiał część materiału wyrzucić jeśli zajdzie taka potrzeba.

Komentarze, reakcje, poprawki i uzupełnienia są mile widziane. Jak napisałem we wstępie, mam nadzieję, że części z Was (czy też raczej nas) dokumentacja się przyda.

Dokumentację można obejrzeć pod adresem http://rddunlap.home.att.net/linit/lin240_init_x86.html

Od dziś jest dostępna wersja 0.3.2 JFS.

Wersja z 18 maja 2001 (jfs-0.3.2-patch.tar.gz) zawiera poprawki do systemu plików i jego programów użytkowych.

Zmiany w wersji 0.3.2

• Usunięto ostrzeżenie z fsck, gdy partycja jest montowana w trybie tylko do odczytu
• Rozwiązany problem z assert(mp->count) [plik jfs_metapage.c, linia 675] zgłaszanym jako problem z twardymi linkami (dtDeleteUp unieważniał niewłaściwe metapage_t).
• Rozwiązany problem z segmentation fault przy tworzeniu twardych linków.
• Rozwiązany problem z zwisami dbench, gdy blokady transakcji nie były zwalniane.
• Montowanie systemu plików tylko do odczytu i jego przemontowywanie powinno działać już poprawnie.

Więcej szczegółów na temat poprawek w README.

Ten błąd bezwarunkowo deaktywuje pytanie konfiguracyjne -- jest to tak stary błąd, że rozpropagował się na pliki konfiguracyjne do trzech portów, niezauważony przez żadną z osób dokonujących przeniesienia.

Taki błąd nie miałby prawa zdarzyć się w CML2, ponieważ kompilator zgłosiłby ostrzeżenie o niezdefiniowanym symbolu BLK_DEV_ST. Mam wielką ochotę wygłosić sarkastyczny komentarz w kierunku ludzi, którzy cały czas uważają, że CML jest zupełnie zbędny. Ale się powstrzymam. Tym razem.

Zatem niedociągnięcia w narzędziach dla CML1 usprawiedliwiają powstanie CML2?

Zapewne następny znaleziony błąd w interpreterze Pythona 2 zaowocuje napisaniem CML3 w FORTRANIE.