Re: insmod: /lib/modules/2.2.17/block/xd.o: init_module: Device or resource busy

[Marc Lefranc <mlefranc@libertysurf.fr>]

On Tue, 28 Nov 2000 18:07:42 +0100, 
Georges Mariano <georges.mariano@inrets.fr> wrote :
> 
> (ne peut on pas avoir plus que le pid ??)

Dans le source du module, voir la fonction trace_open :

static int trace_open (struct inode *inode, struct file *file)
{
    struct task_struct *tsk = current;
    
    printk (KERN_INFO "trace: process %d %s try open block major %d\n",
	    tsk->pid, tsk->comm, major);
    return -ENODEV;
}

On voit que ce code extrait l'information au moyen de current (au
fait, pourquoi ne pas écrire directement current->pid ? Ici, tsk ne
change pas de valeur) qui est une variable fondamentale du noyau,
pointant vers une structure décrivant la tâche en cours d'exécution à
l'instant où trace_open est parcourue.

Il faut s'imaginer trace_open comme une sous-routine du processus
courant, appelée lorsque ce dernier essaie de faire un open sur un
périphérique de makeur 13. La seule différence avec une routine
ordinaire est que le processus est alors en « mode noyau » et a alors
tous les privilèges.

Il suffit donc de jeter un coup d'oeil à la définition d'une
task_struct pour voir comment extraire l'information recherchée. Et
tout est possible puisque par définition, toute l'information sur
cette tâche se trouve dans cette structure.

Voir donc /usr/src/linux/include/linux/sched.h, ligne 230 dans un
2.2.18pre17. En ce qui concerne Les infos les plus intéressantes, les
plus facilement disponibles sont probablement celles qu'Edouard a
utilisées :

- current->comm, le nom de la  commande (char[16)
- current->pid, le pid (pid_t, cad int)

Pour les arguments de la commande (i.e. la ligne de commande),
s'inspirer de la routine get_arg dans fs/proc/array.c : il faut en
fait lire directement dans la mémoire du processus. 

Pour les variables d'environnement, voir la routine get_env dans le
même fichier.

Marc

P.S. Sinon, si tu veux être sûr d'attraper le coupable, tu disposes de
toute l'information nécessaire pour lui faire faire un core dump : ça
ne passera pas inaperçu (tiré de la routine de traitement de SIGABRT) !


 lock_kernel();
 if (current->binfmt
     && current->binfmt->core_dump
     && current->binfmt->core_dump(signr, regs))
         exit_code |= 0x80;
 unlock_kernel();