Kernel Traffic #174 For 2002/07/08

There were 316 different contributors. 141 posted more than once. 119 posted last week too.

Salvatore D'Angelo zaważył, że dwukrotne wywołanie gettimeofday() w 2.4.18 wydaje się pokazywać upływ czasu wstecz. Druga wartość nie zawsze była większa od pierwszej. Wysłał kod, który pokazywał to zachowanie mniej więcej co 10 raz. Matti Aarnio sprawdził i potwierdził istnienie problemu, ale zgłosił tylko jeden przypadek cofnięcia na około 216 milionów prób. Salvatore przyznał, że jego 10% było prawdopobnie zbyt optymistycznym założeniem. Powtórzył testy raz jeszcze i w wyniku osiągnął mniej więcej 0,01% procenta sukcesów. W tym miejscu Karim Yaghmour powiedział:

Na LKML była już dyskusja na ten temat. Tutaj: http://marc.theaimsgroup.com/?t=102348161100006&r=1&w=2

Wysłałem w tej kwestii następujący list: http://marc.theaimsgroup.com/?l=linux-kernel&m=102348249521519&w=2

Jak wtedy zauważyłem, stało się to zarówno na i386, jak i na PPC.

Gdzie indziej, Richard B. Johnson nie był w stanie powtórzyć problemu przy użuciu własnego programu, ale Frank van de Pol wziął jego program i u siebie odkrył kilkanaście cofnięć zegara. Zauważył "Może to dlatego, że mój komputer to SMP (podwójny pentium II)" . Richard odpowiedział " Cóż, ja też mam podwójny pentium, ale nie wymieszałem dwóch różnych procesorów tak jak Ty. Dziwię się, że Twoja kombinacja w ogóle działa! Może być dobrym 'testem' dla ciężkich-do-spowodowania wyścigów." Chris Friesen napisał zaś:

Przy użyciu tego kodu mogę wywołać błąd na 2.2.17 na moim G4, ale nie na 2.4.18 na G4 cPCI blade.

Spotkałem się z tym dawno (rok lub dwa temu) na 2.2, ale nigdy nie rozgryzłem do końca, bo nie był to błąd krytyczny i miałem wtedy inne rzeczy do roboty.

Biorąc pod uwagę, że związny z tym kod został prawie w całości napisany od nowa dla 2.4 (ja jestem temu winien), nie jest to dziwne.

Przepisanie miało na celu stworzenie kodu bardziej odpornego na utracone przerwania: wszystkie PPC na pewno poradzą sobie z maksymalnie (HZ-1) utraconymi przerwaniami, zanim zaczną dziać się złe rzeczy (było to konieczne, gdy sterowniki bufora ramki wyłączały przerwania na zbyt długo w czasie przełączania terminali). Jest też więcej mało widocznych poprawek: przy połączeniu z serwerem NTP, w niektórych przypadkach częstotliwość podstawy czasu była bardzo zależna od obciążenia (poprawiono to przez zastosowanie innego algorytmu liczenia wartości dekrementora) i inne dziwności.

Jeśli jesteś w stanie wywołać błąd na 2.4, jestem tym ekstremalnie zainteresowany.

Michael Kerrisk spytał, jak się miewają capabilities systemów plików w 2.4. Wiedział, że była przynajmniej ich częściowa obsługa w 2.2, ale zastanawiał się, czy prace jakoś się posunęły. Dax Kelson odpowiedział:

VFS w 2.5 wspiera Rozszerzone Atrybuty (od 2.5.3). Myślę, że capabilities będą przechowywane właśnie w RA. Więc infrastrukura jest na miejscu, ktoś, kto potrafi, musi tylko:

Określić jak capabilities będą przechowywane w RA
Nauczyć fs/exec.c używania capabilities
Napisać lscap(1)
Napisać chcap(1)
Zmienić wszystkie SUID-owe programy tak, aby używały capabilities
Ustawić odpowiednie capacilities za pomocą chcap(1) a następnie:
# find / -type f -perm -4000 -user root -exec chmod u-s {} \;
Zrelaksować się i podążać za kierunkiem wyznaczonym przez ten system operacyjny ze sloganem ,,Jedna zdalna dziura w domyślnej instalacji, w ciągu prawie 6 lat!''

Ale Jesse Pollard podał odnośnik i powiedział: "Właściwie to większość pracy została już wykonana przez project Linuksowego Modułu Bezpieczeństwa (z wyjątkiem #7)." Chris Wright uściślił " Projekt LMB wspiera capabilities w tym stanie, w jakim są teraz w jądrze. Połączenia z RA nadal brakuje. Oczywiście, chętnie przyjmiemy łatki ;-)" . A Jesse odpisał: "Oczywiście - miałem na myśli tylko pracę nad zlokalizowaniem miejsc w jądrze, gdzie będzie następować interakacja z RA. I w samym środku też. Dodatkowo, miejsca w systemie plików dostarczające lokalizacji lub dostępu do RA, jak tylko będą dostępne dla/w VFS (mam nadzieję, że tam trafią)."

ze względu na regularne domaganie się pieniędzy przez jednego z adminów OPN, co stoi w sprzeczności z regulaminem sieci, w której znajduje się kernelnewbies.org, zdecydowałem się na przeniesienie kanału IRC #kernelnewbies do innej sieci.

Będzie można nas znaleźć tu:

irc.oftc.net / #kernelnewbies

Kernelnewbies to projekt mający na celu nauczanie podstaw budowy systemu operacyjnego poprzez zapewnienie informacji i utrzymywanie listy pocztowej oraz kanału IRC, gdzie aktualni i przyszli deweloperzy mogą ze sobą rozmawiać. Więc informacji na http://kernelnewbies.org/

Zdajesz sobie sprawę, że dopóki nie _zmusisz_ ludzi do unikania tego kanału w OPN, wszyscy będą się tam udawać?

Dlaczego?

Ponieważ #kn, który nie jest na OPN, nie jest #kn

Mam nadzieję, że inne umrą powolną, bolesną śmiercią, dla dobra wszystkich.

Stephen Frost uznał taki stosunek za bardzo głupi, mówiąc: "To głupie, jeśli #kn miałby być na OPN to by nie istniał z powodu regulaminów - tak, jak to wskazał riel." Co do zmuszania ludzi do nieużywania kanału na Openprojects Network, dodał: "Uh, myślę, że musisz podziękować ircopom OPN za ustawienie +m. Wiem, że zrobił to Chanserv zaraz po odejściu riela." Ktoś anonimowy zauważył, że Rik musiał był to zrobić sam przed odejściem. Gdyby zrobił to Chanserv, nikt nie mogłby wejść na kanał. Stephen odpowiedział: "Ircopi również mogą. Wydaje mi się bardzo prawdopodobne, że zrobione to zostało przez lilo" [Rob Levin] "po tym jak wspomniałem, że kanał został przeniesiony." . Stephen dodał: " O ile mogę powiedzieć, riela już wtedy nie było. Dodatkowo, jeśli zrobisz /m chanserv info na #kernelnewbies, zobaczysz, że ,,Blokada Opcji'' jest ustawiona tylko na +s, a +M tam *nie* ma. " Gerhard Mack odpowiedział:

Nieprawda.. lilo był zdziwiony, gdy zorientował się, że kanał jest moderowany.

Powienieneś zapytać go bezpośrednio, zamiast szerzyć dezinformację.

Abstrahując, któryś z pozostałych opów usunął +m i kanał funkcjonuje normalnie.

Stephen odpowiedział "To nie jest dezinformacja, tak mi się wydawało i, szczerze mówiąc, nadal tak sądzę."

Matthias Andree zapytał o stan obsługi bariery zapisu i o to, czy jest gdzieś jakaś strona, na której można śledzić dokumentację i nowe łatki. Jens Axboe napisał, że nie wie nic o żadnej takiej stronie, ale podsumował: "Mamy stabilną obsługę IDE (to znaczy w warstwie blokowej obsługa bariery działa, implementacja IDE działa). Wątpię, czy kiedykolwiek zrobimy obsługę SCSI w 2.4, byłoby to zbyt inwazyjne na to, by być bezpieczne." Matthias smutno potrząsnął głową pisząc, że potrzebuje obsługi SCSI. Pomyślał na głos, że w najbliższej przyszłości prawdopodobnie zacznie używać 2.5 na swoim systemie.

W porządku, wiem, że wiele osób tego nie lubi, ale znam innych, którzy tego czasem potrzebują. Nie przesyłam tego w celu globalnego włączenia, ale dla zainteresowanych.

Co to jest? To programowy emulator kodów rozkazu dla x86, które nie są obsługiwane przez procesor. Dostępne emulacje to:

BSWAP, CMPXCHG, XADD na 386 (instrukcje 486)
CMOV na wszystkie procesory x86 (instrukcje pentium-pro)

To nie jest pomyślane jako zastępnik poprawnej kompilacji, ale może się nam wszystkim zdarzyć, że będziemy próbowali uratować zniszczony system albo wystartować z dysku i skopiować niektóre programy na dyskietkę i potem dostać komunikat ,,Illegal instruction'', bo programy te zostały skompilowane przy użyciu źle skonfigurowanego kompilatora. Miałem raz gcc, które domyślnie produkowało kod na i686 i sporo przeżyłem próbując wykonać e2fsck nim skompilowane na moim notebooku z k6!

To samo dotyczy sytuacji, w której wyjmujesz dysk z systemu i starasz się wystartować z niego na innym. Nie będę marnował więcej czasu na szukaniu przykładów.

Używam emulacji 486 na mojej zaporze ogniowej na 386 od paru lat i jestem z niej całkiem zadowolony. Wyczyściłem trochę kod i dodałem obsługę cmov. Powiększy to Wasze bzImage o mniej niż 1kB.

Tak jak to wyżej napisałem, *NIE* ma to na celu zastąpienia ponownej kompilacji dla właściwego procesora. Emulacja jest dość wolna, ze względu na czas, który procesor zużywa na przetwarzanie pułapek. Udało mi się zmierzyć, że zabiera to 450 cykli dla cmov, co jest istotnym narzutem, ale ciągle jest akceptowalne, jeśli robi się to od czasu do czasu (1us na moim k6/450).

Myślałem nad dodaniem pewnych informacji statystycznych, takich jak liczba złapanych pułapek, globalnie i przez każdy proces, ale w końcu zdałem sobie sprawę, że to przesada w przypadku czegoś, co nie powinno być stale używane.

Nie miałem czasu by wypróbować na tym VMWare. Możliwość udostępnienia CMOV i innych instrukcji dla systemów ,,gości'' mogłaby być interesująca.

Denis Vlasenko zauważył pewne fragmenty kodu, które nie były tak dobrze zoptymalizowane, jak by mogły być i podesłał kilka łatek, by je przyspieszyć. Willy przyjrzał się modyfikacjom Denisa i miał kilka obiekcji. Dodał, że jego intencją było bardziej uzyskanie poprawności, niż szybkości i że jeśli szybkość byłaby prawdziwym problemem, to chciałby przenieść większość kodu do asemblera. Bill Davidsen odparł: "To brzmi nieźle, pomysł polega na tym, żeby to w ogóle działało, przejrzystość jest dobra, trudno sobie wyobrazić kogoś, kto uruchamiałby to przez długi czas zamiast kompilować kod dla właściwego typu maszyny." Denis sądził, że kwestia szybkości może stać się poważna i może sprawić, że przypadkowi użytkownicy Linuksa odniosą wrażenie, że ten system jest wolny. Przedyskutowali różne sposoby profilowania kodu, albo przynajmniej dodanie ostrzeżenia o przewidywanym spowolnieniu i wątek urwał się.

Paul Menage napisał: "Ta łatka usuwa zabezpieczenie wywołania metody super_operations ->statfs() BKL i zmienia ją na blokadę systemów plików, jeśli jest potrzebna. Wszystkie systemy plików nie będące w głównym drzewie mogą potrzebować zakładać BKL w swoich metodach statfs(), jeśli jest ona niezbędna dla synchronizacji." Dodał: "Wszystkie zmodyfikowane systemy plików zostały skompilowane oprócz wyłączonego umsdos; przetestowany naprawdę został tylko ext2 i shmfs." Matthew Wilcox zasugerował, że można było usunąć więcej wystąpień Dużej Blokady Jądra (Big Kernel Lock), a Paul odpowiedział: "Jestem pewien, że można wywalić więcej wystąpień BKL, ale wolałem nie ryzykować kompletnego rozwalenia całości, ze względu na to, że nie jestem do końca zaznajomiony z regułami blokowania poszczególnych systemów plików - zostawiłem BKL w innych miejscach niż te, w których używano zmiennych danych. Łatki, które zmniejszają użycie BKL w poszczególnych systemach plików mogą być podsyłane (mam nadzieję, że po wystarczających wyjaśnieniach to, albo coś takiego jak to, zostanie nałożone." Ale później i w innym podwątku, podesłał rozszerzoną łatkę usuwającą BKL z jeszcze większego obszaru kodu. Różni ludzie podesłali jeszcze więcej propozycji miejsc w systemie plików, które mogą sobie radzić bez BKL.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	24 cze 2002 - 30 cze 2002	(22 posts)	gettimeofday() zwraca czas z przeszłości
2.	26 cze 2002 - 28 cze 2002	(6 posts)	Status capabilities systemów plików
3.	26 cze 2002 - 28 cze 2002	(7 posts)	#kernelnewbies przenosi się do innej sieci
4.	27 cze 2002 - 28 cze 2002	(7 posts)	Stan obsługi Bariery Zapisu dla 2.4 i 2.5
5.	29 cze 2002 - 2 lip 2002	(14 posts)	Emulator opcode dla niezgodnych procesorów
6.	2 lip 2002 - 3 lip 2002	(9 posts)	Usuwanie BKL w trakcie

Kernel Traffic #174 For 2002/07/08

By Zack Brown

Translated By: Maja Królikowska and Tomasz Torcz