Come interpretare gli indirizzi in un kernel oops

Question

Ho un kernel oops in un driver di periferica Linux che ho scritto. Voglio determinare quale linea è responsabile per oops. Ho il seguente risultato, ma non so come interpretarlo.

Significa che il mio codice si è bloccato durante l'istruzione su write_func + 0x63? Come posso correlare il valore in EIP alla mia funzione? Cosa significano i valori dopo il backslash?

[10991.880354] BUG: unable to handle kernel NULL pointer dereference at (null) 
[10991.880359] IP: [<c06969d4>] iret_exc+0x7d0/0xa59 
[10991.880365] *pdpt = 000000002258a001 *pde = 0000000000000000 
[10991.880368] Oops: 0002 [#1] PREEMPT SMP 
[10991.880371] last sysfs file: /sys/devices/platform/coretemp.3/temp1_input 
[10991.880374] Modules linked in: nfs lockd fscache nfs_acl auth_rpcgss sunrpc hdrdmod(F) coretemp(F) af_packet fuse edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf microcode dm_mod ppdev sg og3 ghes i2c_i801 igb hed pcspkr iTCO_wdt dca iTCO_vendor_support parport_pc floppy parport ext4 jbd2 crc16 i915 drm_kms_helper drm i2c_algo_bit video button fan processor thermal thermal_sys [last unloaded: preloadtrace] 
[10991.880400] 
[10991.880402] Pid: 4487, comm: python Tainted: GF   2.6.37.1-1.2-desktop #1 To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M. 
[10991.880408] EIP: 0060:[<c06969d4>] EFLAGS: 00210246 CPU: 0 
[10991.880411] EIP is at iret_exc+0x7d0/0xa59 
[10991.880413] EAX: 00000000 EBX: 00000000 ECX: 0000018c EDX: b7837000 
[10991.880415] ESI: b7837000 EDI: 00000000 EBP: b7837000 ESP: e2a81ee0 
[10991.880417] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 
[10991.880420] Process python (pid: 4487, ti=e2a80000 task=df940530 task.ti=e2a80000) 
[10991.880422] Stack: 
[10991.880423] 00000000 0000018c 00000000 0000018c e5e903dc e4616353 00000009 df99735c 
[10991.880428] df900a7c df900a7c b7837000 df80ad80 df99735c 00000009 e46182a4 e2a81f70 
[10991.880433] e28cd800 e09fc840 e28cd800 fffffffb e09fc888 c03718c1 e4618290 0000018c 
[10991.880438] Call Trace: 
[10991.882006] Inexact backtrace: 
[10991.882006] 
[10991.882012] [<e4616353>] ? write_func+0x63/0x160 [mymod] 
[10991.882017] [<c03718c1>] ? proc_file_write+0x71/0xa0 
[10991.882020] [<c0371850>] ? proc_file_write+0x0/0xa0 
[10991.882023] [<c036c971>] ? proc_reg_write+0x61/0x90 
[10991.882026] [<c036c910>] ? proc_reg_write+0x0/0x90 
[10991.882031] [<c0323060>] ? vfs_write+0xa0/0x160 
[10991.882034] [<c03243c6>] ? fget_light+0x96/0xb0 
[10991.882037] [<c0323331>] ? sys_write+0x41/0x70 
[10991.882040] [<c0202f0c>] ? sysenter_do_call+0x12/0x22 
[10991.882044] [<c069007b>] ? _lock_kernel+0xab/0x180 
[10991.882046] Code: f3 aa 58 59 e9 5a f9 d7 ff 8d 0c 88 e9 12 fa d7 ff 01 d9 e9 7b fa d7 ff 8d 0c 8b e9 73 fa d7 ff 01 d9 eb 03 8d 0c 8b 51 50 31 c0 <f3> aa 58 59 e9 cf fa d7 ff 01 d9 e9 38 fb d7 ff 8d 0c 8b e9 30 
[10991.882069] EIP: [<c06969d4>] iret_exc+0x7d0/0xa59 SS:ESP 0068:e2a81ee0 
[10991.882072] CR2: 0000000000000000 
[10991.889660] ---[ end trace 26fe339b54b2ea3e ]--- 

Answer 1

Tutte le informazioni di cui hai bisogno è proprio lì:

[10991.880354] BUG: unable to handle kernel NULL pointer dereference at (null) 

Questa è la ragione.

[10991.880359] IP: [<c06969d4>] iret_exc+0x7d0/0xa59 

Questo è il puntatore di istruzioni al momento dell'errore. Torneremo su questo momentaneamente.

[10991.880365] *pdpt = 000000002258a001 *pde = 0000000000000000 

Queste sono voci della tabella di pagina fisica. la tabella dei descrittori e la voce del descrittore di pagina. Naturalmente, quest'ultimo è NULL, poiché è un puntatore NULL. I valori sopra riportati sono raramente utili (solo nei casi in cui è richiesta la mappatura della memoria fisica)

Questo è il codice di oops. PREMETTO SMP mostra che il kernel è preempibile e compilato per SMP, piuttosto che UP. Questo è importante per i casi in cui il bug è da qualche condizione di gara, ecc

[10991.880371] last sysfs file: /sys/devices/platform/coretemp.3/temp1_input 

che non è necessariamente il colpevole, ma spesso è. i file sys vengono esportati da vari moduli del kernel, e spesso un'operazione di I/O sul file sys porta all'esecuzione del codice del modulo difettoso.

[10991.880374] Modules linked in: ... [last unloaded: preloadtrace] 

Il kernel non è necessariamente a conoscenza del modulo da incolpare, quindi fornisce tutti i moduli. Inoltre, potrebbe benissimo essere che un modulo scaricato di recente non abbia pulito e lasciato dei residui (come alcuni timer o callback) nel kernel - che è un caso classico per oops o panico. Quindi il kernel riporta anche l'ultimo scaricato.

[10991.880402] Pid: 4487, comm: python Tainted: GF   2.6.37.1-1.2-desktop #1 To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M. 

Se il thread di errore è un thread in modalità utente, si ottiene il PID e la riga di comando. bandiere "Tainted" sono il modo del kernel di dire che non è un difetto del kernel (il sorgente del kernel è aperto e "pura". "Taint" deriva dai moduli non-GPL blasfemi, e altri.

[10991.880408] EIP: 0060:[<c06969d4>] EFLAGS: 00210246 CPU: 0 
[10991.880411] EIP is at iret_exc+0x7d0/0xa59 

Che dà si il puntatore all'istruzione ha provocato l'errore, sia direttamente che in simbolo + sotto forma di offset. la parte dopo la barra è la dimensione della funzione.

[10991.880413] EAX: 00000000 EBX: 00000000 ECX: 0000018c EDX: b7837000 
[10991.880415] ESI: b7837000 EDI: 00000000 EBP: b7837000 ESP: e2a81ee0 
[10991.880417] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 

I registri sono mostrati qui. il vostro NULL è probabile EAX.

[10991.880420] Process python (pid: 4487, ti=e2a80000 task=df940530 task.ti=e2a80000) 
[10991.880422] Stack: 
[10991.880423] 00000000 0000018c 00000000 0000018c e5e903dc e4616353 00000009 df99735c 
[10991.880428] df900a7c df900a7c b7837000 df80ad80 df99735c 00000009 e46182a4 e2a81f70 
[10991.880433] e28cd800 e09fc840 e28cd800 fffffffb e09fc888 c03718c1 e4618290 0000018c 

Viene visualizzata l'area vicino al puntatore dello stack. Il kernel non ha idea di cosa significano questi valori, ma sono lo stesso risultato che otterresti da gdb che visualizza $ rsp. Quindi sta a te capire cosa sono. (Ad esempio, c03718c1 è un indirizzo di ritorno del kernel, probabilmente - così puoi andare in/proc/kallsyms per capirlo, o fare affidamento sul fatto che sia nella traccia, così com'è, dopo).Questo vi dice che tutti i dati fino ad esso è lo stack frame

Ora, perché si ha l'analisi dello stack delle chiamate, è possibile mettere insieme i frammenti:

[10991.880423] 00000000 0000018c 00000000 0000018c e5e903dc e4616353 --> back to write_func 

[   ] ..................................................... 00000009 df99735c 
[10991.880428] df900a7c df900a7c b7837000 df80ad80 df99735c 00000009 e46182a4 e2a81f70 
[10991.880433] e28cd800 e09fc840 e28cd800 fffffffb e09fc888 c03718c1 --> back to proc_file_write 

[10991.882046] Code: f3 aa 58 59 e9 5a f9 d7 ff 8d 0c 88 e9 12 fa d7 ff 01 d9 e9 7b fa d7 ff 8d 0c 8b e9 73 fa d7 ff 01 d9 eb 03 8d 0c 8b 51 50 31 c0 <f3> aa 58 59 e9 cf fa d7 ff 01 d9 e9 38 fb d7 ff 8d 0c 8b e9 30 

Anche in questo caso, kernel non può smontare per tu (è opprimente, e potrebbe benissimo prendere dal panico, dargli una pausa!). Ma puoi usare gdb per smontare questi valori.

Quindi ora sai tutto. Si può effettivamente smontare il proprio modulo e capire dove esattamente in write_func il puntatore NULL è dereferenziato. (Probabilmente lo passi come argomento per qualche funzione).