Gdy w 1991 roku Linus Torvalds napisał na comp.os.minix o swoim systemie operacyjnym, nikt nie spodziewał się, że odniesie on duży sukces – nawet sam Torvalds zaznaczył “po prostu hobby, nie będzie duży i profesjonalny jak GNU”. Prawie piętnaście lat później Linux jest uważany za poważnego gracza w świecie systemów operacyjnych – jednak ta popularność ma też swoje wady.
Coraz więcej osób zwraca uwagę na pogarszającą się jakość systemu. Główną tego przyczyną jest duża ilość zmian wprowadzanych w jądrze, wynikająca z presji użytkowników i deweloperów na wprowadzanie nowej funkcjonalności. Użytkownicy systemu chcą nowych sterowników, nowych technologii, poprawienia wydajności już istniejących rozwiązań – deweloperzy pracujący nad Linuksem chcą tego samego. Ilość wprowadzanych zmian jest kolosalna – nie spotykana w innych projektach – nie służy to jednak stabilności.
Dlaczego powinniśmy spróbować zmienić ten stan rzeczy? Linux jest dobrym systemem – wielu ludzi zarabia na życie wykorzystując go do wykonywania swojej pracy. Każdemu zależy na tym aby system którego używa był wysokiej jakości. Jak często spotykamy się z sytuacją gdy chcemy przeprowadzić wdrożenie w firmie i napotykamy duże problemy, bo jeden ze sterowników nie działa tak jak trzeba?
Prostym sposobem na rozwiązanie przynajmniej części problemów ze stabilnym (przewidywalnym) działaniem systemu jest testowanie jego wersji rozwojowych. Niestety, ilość osób, które wykonują tę czynność jest za mała w stosunku do ilości wprowadzanych zmian. Aby temu zaradzić zacząłem pracę nad sformowaniem LTG – Linux Testers Group. Założenie jest proste – nie trzeba być inżynierem lotnictwa, żeby wiedzieć, że w samolocie w którym podczas startu odrywają się skrzydła coś poszło nie tak – każdy może znaleźć błąd w systemie. Celem LTG jest dostarczenie ludziom, którzy decydują się na testowanie Linuksa, wszystkich informacji potrzebnych do wykonywania tego zadania.
Poznajmy głównego wroga – jego imię to Oops, a wygląda tak:
BUG: unable to handle kernel paging request at virtual address eaa34b3c printing eip: b0161cdd *pde = 0048a067 *pte = 3aa34000 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file: /devices/pci0000:00/0000:00:1d.1/usb3/idVendor Modules linked in: snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer ide_cd cdrom intel_agp agpgart snd i2c_i801 hw_random soundcore snd_page_alloc unix CPU: 0 EIP: 0060:[<b0161cdd>] Not tainted VLI EFLAGS: 00010282 (2.6.16-rc1-mm3 #4) EIP is at do_path_lookup+0x22b/0x259 eax: eaa34b20 ebx: eb328000 ecx: 00000000 edx: eb328f4c esi: ffffff9c edi: fffffffe ebp: eb328f24 esp: eb328f0c ds: 007b es: 007b ss: 0068 Process udevd (pid: 731, threadinfo=eb328000 task=eb30ca80) Stack: <0>00000000 eb5cb000 b015fab1 eb5cb000 eb5cb000 00000000 eb328f40 b01621f3 eb328f4c ffffff9c afbf6dec afbf6dec 00000100 eb328f9c b015bf69 eb328f4c eaa34b20 b23d5f28 00000000 eb329003 b015f8ce 00000000 00000001 00000000 Call Trace: [<b0103917>] show_stack_log_lvl+0xaa/0xb5 [<b0103a54>] show_registers+0x132/0x19d [<b0103d91>] die+0x171/0x1fb [<b02ab110>] do_page_fault+0x3be/0x568 [<b010343f>] error_code+0x4f/0x54 [<b01621f3>] __user_walk_fd+0x2d/0x41 [<b015bf69>] sys_readlinkat+0x26/0x93 [<b015bfe9>] sys_readlink+0x13/0x15 [<b01028bf>] sysenter_past_esp+0x54/0x75 Code: 00 83 c0 04 e8 9a 82 14 00 8b 03 c7 80 e4 01 00 00 00 00 00 00 8b 55 08 8b 45 ec e8 55 fa ff ff 89 c7 8b 55 08 8b 02 85 c0 74 24 <8b> 50 1c 85 d2 74 1d b8 00 f0 ff ff 21 e0 8b 00 83 b8 d4 04 00
Po znalezieniu oopsa należy wysłać informację o nim na LKML – Linux Kernel Mailing List. Najprostszy raport składa się przeważnie z naszego głównego bohatera, pliku konfiguracyjnego jądra, z którym było kompilowane, oraz ze sposobu odtworzenia błędu – jeżeli jest znany.
Następnie opiekun podsystemu, w którym wystąpił błąd kompiluje daną wersję jądra z naszym plikiem konfiguracyjnym. Włącza debugger “gdb vmlinux” i wpisuje magiczną komendę “list *0xb0161cdd”, gdzie “b0161cdd” jest wartością rejestru EIP wziętą z linijki “EIP: 0060:[<b0161cdd>] Not tainted VLI“ z naszego oopsa. Następnie otrzymuje fragment kodu w którym błąd się ujawnił
(gdb) list *0xb0161cdd 0xb0161cdd is in do_path_lookup (/usr/src/linux-mm/fs/namei.c:1124). 1119 1120 fput_light(file, fput_needed); 1121 } 1122 read_unlock(¤t->fs->lock); 1123 current->total_link_count = 0; 1124 retval = link_path_walk(name, nd); 1125 out: 1126 if (nd && nd->dentry && nd->dentry->d_inode) 1127 audit_inode(name, nd->dentry->d_inode, flags); 1128 out_fail:
Teraz wykorzystując swoje hackerskie czary mary i dobrą znajomość kodu Linuksa deweloper próbuje naprawić błąd. Następnie otrzymamy do przetestowania poprawkę. Czasami udaje się naprawić błąd za pierwszym razem, czasami nie – jednak później możemy mieć satysfakcję, ponieważ przyczyniliśmy się do poprawy jakości Linuksa.
Wszystkich zainteresowanych zapraszam do współpracy. Michał Piotrowski, LTG – Linux Testers Group
Archiwalny news dodany przez użytkownika: Michał Piotrowski.
Kliknij tutaj by zobaczyć archiwalne komentarze.