Noyau Linux : Spinlock SMP : Pourquoi il y a un preempt_disable() dans la version spin_lock_irq SMP ?

Question

Le code original dans le noyau de Linux est :

static inline void __raw_spin_lock_irq(raw_spinlock_t *lock)
{
    local_irq_disable();
    preempt_disable();
    spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
    LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
}

Je pense qu'il n'y a pas de chemin d'exécution qui peut préempter le chemin actuel après que l'IRQ local soit désactivé.

Comme toutes les IRQs matérielles courantes sont désactivées, il ne devrait pas y avoir de softirq et pas non plus de tic pour donner un coup de pied à la roue du planning. Je pense que le chemin actuel est sûr. Alors pourquoi il y a un preempt_disable() ?

Answer 1

D'après ce que je sais, preempt_disable() ont été ajoutés à un certain nombre de primitives de verrouillage, dont les suivantes spin_lock_irq par Dave Miller le 4 décembre 2002, et publié dans la version 2.5.51. Le message de livraison n'est pas utile ; il dit juste "[SPINLOCK] : Corrige les macros spin/rwlock non-SMP."

Je crois que le Verrouillage correct sous un noyau préemptible La documentation explique cela suffisamment bien. La dernière section intitulée "PREVENIR LA PREEMPTION EN UTILISANT LE DISABLING D'INTERRUPTION" commence,

It is possible to prevent a preemption event using local_irq_disable and
local_irq_save.  Note, when doing so, you must be very careful ...

Answer 2

J'ai survolé le patch mentionné par Sharp et a trouvé que désactiver irq peut désactiver la préemption implicitement mais est risqué.

Cependant, gardez à l'esprit qu'il est risqué de compter sur la désactivation des irq. risquée. Tout spin_unlock() qui diminue le nombre de préemptions à 0 peut déclencher une reprogrammation. Même un simple printk() peut déclencher un tel réordonnancement. un tel réordonnancement. Ne comptez donc sur la désactivation implicite de la préemption que si vous savez que ce genre de chose ne peut pas se produire dans votre chemin de code. Le site meilleure politique est de ne compter sur la désactivation implicite de la préemption que pour de courtes périodes de temps. pour de courtes périodes et seulement tant que vous restez dans votre propre code.