Hi Linux hackers !
I'm reading some code in net/core/dev.c and something puzzles me : somewhere in __dev_queue_xmit, we have :
int cpu = smp_processor_id(); /* ok because BHs are off */
and, indeed, a few lines up there is :
/* Disable soft irqs for various locks below. Also
* stops preemption for RCU.
*/
rcu_read_lock_bh();
Now I'm wondering : is this really ok ?
From what I understand, this code can very well run in user context, with hard IRQs ON, and in fact it should, according to the following comment :
* When calling this method, interrupts MUST be enabled. This is because
* the BH enable code must have IRQs enabled so that it will not deadlock.
* --BLG
Then I guess it could be preempted at any time, especially with aggressive versions of preemptions ?
And if so, are we not at risk that our thread is migrated to an other CPU just after smp_processor_id returned ?
Cheers,
int cpu = smp_processor_id(); /* ok because BHs are off */
and, indeed, a few lines up there is :
/* Disable soft irqs for various locks below. Also
* stops preemption for RCU.
*/
rcu_read_lock_bh();
Now I'm wondering : is this really ok ?
From what I understand, this code can very well run in user context, with hard IRQs ON, and in fact it should, according to the following comment :
* When calling this method, interrupts MUST be enabled. This is because
* the BH enable code must have IRQs enabled so that it will not deadlock.
* --BLG
Then I guess it could be preempted at any time, especially with aggressive versions of preemptions ?
And if so, are we not at risk that our thread is migrated to an other CPU just after smp_processor_id returned ?
Cheers,
V Ray
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
