Rien d'officiel en tout cas.
Je pense que ça se fera au fur et à mesure, parce que aucune personne seule ne peut corriger chaque endroit où se trouve le Bkl.
Quand bien même il y a une aversion générale pour ce vérrou, son retrait dépend beaucoup de la motivation qu'ont les mainteneurs ayant des affinités avec les sous-systèmes concernés.
Je m'explique, le Bkl n'est pas seulement un verrou géant, c'est aussi et surtout une horreur sans nom:
- C'est un verrou qui peut être acquis et réaquis autant de fois par une même tâche autant de fois qu'elle le désire.
Par exemple, un spinlock ou un mutex du noyau linux n'autorisera _jamais_ un usage récursif.
L'usage typique est:
mutex_lock(&lock);
//code partie protégée
mutex_unlock(&lock);
On pourrait éventuellement s'attendre à ce que ce code soit légal dans un même
thread, car c'est possible de l'implémenter. Mais non et heureusement.
Or le Bkl autorise ça pour une même tâche, il y a même un indicateur dans la structure des tâches du noyau pour indiquer la profondeur courante du Bkl pour une tâche donnée
C'est horrible parce que le code qui a été écrit en suivant cette liberté désinvolte est maintenant très difficile à corriger. Il ne suffit plus de remplacer le bkl par un simple verrou normal, il faut carrément parfois réorganiser le code.
Un cas typique c'est reiserfs qui possède des pans entiers dépendants de cette logique de récursivité.
- Le bkl est libéré pour la tâche courante lorsque celle-ci appelle schedule() O_o
Ca signifie qu'à chaque fois qu'une tâche détenant le bkl veut dormir, elle lâche le bkl et n'importe qui peut le reprendre. Et quand la tâche se réveille (quand schedule() retourne) le bkl est relocké pour la tâche courante.
Ca non plus ça n'a rien à voir avec un mutex ou spinlock normal. Ca veut dire que si l'auteur du code a prévu un appel à schedule(), qu'est ce qu'il avait en tête: dormir en attendant une ressource? Dormir pour relâcher un peu le verrou et le donner à quelqu'un d'autres pendant quelques temps?
- $ git-grep -E "[^n]lock_kernel\(\)" | grep -v "Documentation" | wc -l
590
Il y a 590 appels au bkl egrainés un peu partout dans le noyau. Souvent, chaque sous-système possède ses propres spécialistes qui sont les plus compétents pour résoudre ce vieux schéma de synchronisation, pour intégrer un vrai schéma de protection des données bien réfléchi.
Mais le problème c'est que c'est chiant. Il faut parfois repenser la structure du code, repenser des interdépendances avec d'autres zones qui détiennent le Bkl etc...
Je pense que si tout le monde s'y mettait, ça se passerait bien mais bon c'est tout simplement chiant.
Ceci étant la branche kill-the-BKL d'Ingo Molnar est plutôt bien vue.
Il s'agit de transformer le bkl en un mutex géant (faisant ainsi perdre les propriétés de récursivité et de relâche par schedule()) et donc permettre à lockdep de vérifier les problèmes qui surviennent. Ca permet d'identifier les zones à problèmes particulières.
[^] # Re: le BKL
Posté par fweisbec . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 10.
Je pense que ça se fera au fur et à mesure, parce que aucune personne seule ne peut corriger chaque endroit où se trouve le Bkl.
Quand bien même il y a une aversion générale pour ce vérrou, son retrait dépend beaucoup de la motivation qu'ont les mainteneurs ayant des affinités avec les sous-systèmes concernés.
Je m'explique, le Bkl n'est pas seulement un verrou géant, c'est aussi et surtout une horreur sans nom:
- C'est un verrou qui peut être acquis et réaquis autant de fois par une même tâche autant de fois qu'elle le désire.
Par exemple, un spinlock ou un mutex du noyau linux n'autorisera _jamais_ un usage récursif.
L'usage typique est:
mutex_lock(&lock);
//code partie protégée
mutex_unlock(&lock);
Mais si tu essaies:
mutex_lock(&lock)
//gnagnagna bidule chouette
mutex_lock(&lock); <--- ici un blocage (deadlock)
//gnagnagna2 prout
mutex_unlock(&lock);
mutex_unlock(&lock);
On pourrait éventuellement s'attendre à ce que ce code soit légal dans un même
thread, car c'est possible de l'implémenter. Mais non et heureusement.
Or le Bkl autorise ça pour une même tâche, il y a même un indicateur dans la structure des tâches du noyau pour indiquer la profondeur courante du Bkl pour une tâche donnée
// current->lock_depth = -1
lock_kernel(); // current->lock_depth = 0
//pouet
lock_kernel(); // current->lock_depth = 1 (on ne deadlock pas)
//flet
unlock_kernel(); // current->lock_depth = 0
unlock_kernel(); // current->lock_depth = -1
C'est horrible parce que le code qui a été écrit en suivant cette liberté désinvolte est maintenant très difficile à corriger. Il ne suffit plus de remplacer le bkl par un simple verrou normal, il faut carrément parfois réorganiser le code.
Un cas typique c'est reiserfs qui possède des pans entiers dépendants de cette logique de récursivité.
- Le bkl est libéré pour la tâche courante lorsque celle-ci appelle schedule() O_o
Ca signifie qu'à chaque fois qu'une tâche détenant le bkl veut dormir, elle lâche le bkl et n'importe qui peut le reprendre. Et quand la tâche se réveille (quand schedule() retourne) le bkl est relocké pour la tâche courante.
Ca non plus ça n'a rien à voir avec un mutex ou spinlock normal. Ca veut dire que si l'auteur du code a prévu un appel à schedule(), qu'est ce qu'il avait en tête: dormir en attendant une ressource? Dormir pour relâcher un peu le verrou et le donner à quelqu'un d'autres pendant quelques temps?
- $ git-grep -E "[^n]lock_kernel\(\)" | grep -v "Documentation" | wc -l
590
Il y a 590 appels au bkl egrainés un peu partout dans le noyau. Souvent, chaque sous-système possède ses propres spécialistes qui sont les plus compétents pour résoudre ce vieux schéma de synchronisation, pour intégrer un vrai schéma de protection des données bien réfléchi.
Mais le problème c'est que c'est chiant. Il faut parfois repenser la structure du code, repenser des interdépendances avec d'autres zones qui détiennent le Bkl etc...
Je pense que si tout le monde s'y mettait, ça se passerait bien mais bon c'est tout simplement chiant.
Ceci étant la branche kill-the-BKL d'Ingo Molnar est plutôt bien vue.
Il s'agit de transformer le bkl en un mutex géant (faisant ainsi perdre les propriétés de récursivité et de relâche par schedule()) et donc permettre à lockdep de vérifier les problèmes qui surviennent. Ca permet d'identifier les zones à problèmes particulières.