smp_processor_id used in preemptable context ?

From: Vincent Ray <vray@kalrayinc.com>
To: kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: smp_processor_id used in preemptable context ?
Date: Thu, 28 Apr 2022 11:15:27 +0200 (CEST)	[thread overview]
Message-ID: <1168824437.12549419.1651137327677.JavaMail.zimbra@kalray.eu> (raw)

[-- Attachment #1.1: Type: text/plain, Size: 925 bytes --]

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, 

V Ray 

[-- Attachment #1.2: Type: text/html, Size: 1573 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies