impossibile "rmmod" il modulo

Sto lavorando con un grande software embedded (processore ARM, embedded linux 2.6.31, busybox) che coinvolge sia il kernel che lo user space code. C'è un modulo del kernel normalmente caricato per primo e demone che stabilisce il socket netlink con il modulo.impossibile "rmmod" il modulo

Il problema qui è che dopo aver ucciso il demone, non sono più in grado di scaricare il modulo dalla memoria:

% rmmod _module.ko 
% rmmod: _module.ko: Resource temporarily unavailable

L'analisi ha dimostrato che l'errore (valore di ritorno è -11, cioè EAGAIN?) viene restituito da try_stop_module() richiamato in syscall delete_module() definizione in kernel/module.c. Funzione try_stop_module() a sua volta chiama stop_machine() e questo è il punto in cui mi sono bloccato, come

Non sono sicuro di cosa sta succedendo esattamente lì. Penso che la causa principale sia da qualche parte nel daemon che apre le connessioni al modulo e ovviamente qualcos'altro e non chiude/pulisce correttamente all'uscita (apparentemente alcuni riferimenti/blocchi non vengono rilasciati?)

Qualcuno ha Qualche idea su cos'altro guardare e sondare?

fonte

2012-12-12 Mark

Solo una stupida idea ... rmmod -f ... forzare lo scarico? –

Prima di tutto dovresti essere un superutente per farlo. Inoltre puoi usare rmmod -f ma questa opzione può essere estremamente pericolosa: non ha alcun effetto a meno che non sia stato impostato CONFIG_MODULE_FORCE_UNLOAD quando il kernel è stato compilato. Con questa opzione, è possibile rimuovere i moduli che vengono utilizzati o che non sono progettati per essere rimossi o contrassegnati come non sicuri.

Leggere anche man rmmod.

fonte

2012-12-13 10:51:18 ymn

grazie per i commenti. Sono a conoscenza della modalità 'forzata', tuttavia sulla mia piattaforma busybox rmmod non è compilato con questa opzione, e il mio scopo è quello di capire quali descrittori sono ancora tenuti e correggerli, questo è ovviamente un bug nel modulo o/e il demone. – Mark

Un'altra cosa: il problema principale qui è che il numero di riferimenti al modulo, cioè quanti processi stanno usando il modulo (il terzo campo di/proc/net/modules), non è zero e quindi il modulo può essere scaricato. Prima di eseguire il demone, il contatore di riferimento è 0, dopo che il daemon è stato lanciato, il contatore sale a 6, anche se mi aspetterei solo 3 dato che apre tre socket. Quindi, dopo aver ucciso il damon, il contatore scende a 3, quindi il modulo non può essere scaricato. Ci sono modi per scoprire quali altri descrittori, ecc. Vengono tenuti aperti? – Mark

Verificare se tutte le interfacce relative al modulo non sono "su".

se una qualsiasi delle interfacce collegate al modulo è "su", quindi rmmod fallirà e ritornerà con -11.

Quindi prima di chiamare rmmod, controllare le interfacce attive utilizzando il comando 'netcfg'. quindi utilizzare ifconfig, rendere l'interfaccia come 'ifconfig <interface_name> down'

quindi provare a eseguire rmmod <module_name>. funzionerà !!

1.netcfg <lists out all interfaces> 
2.ifconfig <interface_name> down 
3.rmmod <module_name>

fonte

2014-09-02 16:06:12

risposta

Problemi correlati