Des Modules du Noyau Linux: utilisation des try_module_get / module_put

Je lisais le LKMPG ( Voir La Section 4.1.4. Annulation De L'Enregistrement D'Un Périphérique ) et il n'était pas clair pour moi lors de l'utilisation de la try_module_get /module_put fonctions. Certains des LKMPG des exemples d'utilisation, certains ne le font pas.

Pour ajouter à la confusion, try_module_get apparaît 282 fois en 193 fichiers dans le 2.6.24 source, mais dans Linux Pilotes de Périphériques ( LDD3 ) et Essentiel Linux Pilotes De Périphérique, ils s'affiche en même pas un seul exemple de code.

J'ai pensé que peut-être qu'ils étaient attachés à l'ancien register_chrdev interface ( remplacé en 2.6 par la cdev interface ), mais ils n'apparaissent ensemble dans les mêmes fichiers 8 fois:

find -type f -name *.c | xargs grep -l try_module_get | sort -u | xargs grep -l register_chrdev | sort -u | grep -c .

Alors, quand est-il approprié d'utiliser ces fonctions et sont-ils liés à l'utilisation d'une interface particulière ou d'un ensemble de circonstances?

Modifier

J'ai chargé le sched.c exemple de la LKMPG et tenté l'expérience suivante:

anon@anon:~/kernel-source/lkmpg/2.6.24$ tail /proc/sched -f &
Timer called 5041 times so far
[1] 14594

anon@anon:~$ lsmod | grep sched
sched                   2868  1 

anon@anon:~$ sudo rmmod sched
ERROR: Module sched is in use

Cela me mène à croire que le noyau maintenant-t-il son propre comptabilité et les gets /les met peut-être obsolètes. Quelqu'un peut-il vérifier?

il y a une occurrence de try_module_get dans le Chapitre 14, le paragraphe reference count manipulation (page 367)
Je voulais dire le LDD livre dans mon commentaire précédent

OriginalL'auteur Robert S. Barnes | 2009-11-16

  1. 17

    Vous devriez essentiellement jamais avoir à utiliser try_module_get(THIS_MODULE); assez bien l'ensemble de ces usages sont dangereux, car si vous êtes déjà dans votre module, il est trop tard pour augmenter le nombre de références -- il y aura toujours une petite fenêtre où vous êtes à l'exécution de code dans votre module mais je n'ai pas incrémenté le compteur de référence. Si quelqu'un enlève le module exactement dans cette fenêtre, vous êtes dans la mauvaise situation de l'exécution de code dans un déchargé module.

    L'exemple particulier est lié à LKMPG où le code n'est try_module_get() dans la méthode open() seraient traitées dans le moderne noyau par la mise en au .propriétaire du champ dans struct file_operations:

    struct file_operations fops = {
        .owner = THIS_MODULE,
        .open = device_open,
        //...
};

    cela rendra le VFS code prendre une référence pour le module avant qui l'appellent, ce qui élimine le dangereux fenêtre -- le try_module_get() va réussir avant l'appel .open(), ou la try_module_get() échouera et le VFS n'appellerai jamais dans le module. Dans les deux cas, nous n'avons jamais exécuter du code à partir d'un module qui a déjà été déchargé.

    Le seul bon moment pour utiliser try_module_get (), c'est quand vous voulez prendre une référence sur un différents module avant d'appeler ou de l'utiliser d'une certaine façon (par exemple le fichier de code ouvert, dans l'exemple que j'ai expliqué ci-dessus). Il y a un certain nombre d'utilisations de try_module_get(THIS_MODULE) dans le source du noyau, mais la plupart, si pas tous d'entre eux sont latentes bugs qui devraient être nettoyés.

    La raison pour laquelle vous n'étiez pas en mesure de décharger l'annexe a, par exemple, c'est que votre

    $ tail /proc/sched -f &

    garde /proc/sched ouvrir, et à cause de

            Our_Proc_File->owner = THIS_MODULE;

    dans les lueurs de l'aube.le code en c, ouverture /proc/sched incrémente le compteur de référence de l'annexe a, par module, ce qui représente 1 référence que votre lsmod montre. À partir d'un rapide écrémé du reste du code, je pense que si vous relâchez /proc/sched en tuant votre queue de commande, vous serait en mesure de retirer le sched module.

    --- Eh bien, comme je sais que récemment, tout en travaillant sur la surveillance pilote de périphérique, il y a une fonctionnalité appelée sans issue, ce qui signifie une fois que cet appareil est démarré, vous ne pouvez pas l'arrêter. Pour cette raison, ce module n'a pas pu être déchargé, donc, dans le pilote de périphérique open() de la mise en œuvre, un __module_get(THIS_MODULE) est utilisé avec le module de pilote de périphérique, nous le savons, lorsque le compteur de référence d'un module n'est pas zéro, vous ne pouvez pas décharger. En conclusion, c'est peut-être le cas où vous avez besoin d'utiliser module_get, module_put, etc. Merci.
    Un try_module_get de l'intérieur de la init_module fonction est sûr, mais une correspondance module_put aurait à faire à un moment plus tôt que cleanup_module.

    OriginalL'auteur Roland