It's said that "SCHEDULE_SOFTIRQ may move us to another processor",
which I don't find it very clear, nor that much representative of
what the situation actually is.
We have two possible situations:
- context_switch() is a "terminal function" (i.e., it jumps,
rather than returning normally. This happens on x86;
- context_switch() "just" returns, and another step of the
loop is executed. This happens on ARM.
The real reason why we need to re-sample smp_processor_id() is
that, on ARM, where the function return, we get back inside
of the loop, with (potentially) a different stack (because
context_switch() changed what's in the stack pointer register).
And in this case, what's in the new stack, at the address of
the local variable 'cpu', may not be consistent.
State this in the comment.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
Changes from v1:
* v1 had a patch that was getting rid of the call to smp_processor_id(), but
that is wrong (on ARM). So, it has been replaced with this, which only
adjust the comment.
---
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Tim Deegan <tim@xen.org>
for ( ; ; )
{
/*
- * Initialise @cpu on every iteration: SCHEDULE_SOFTIRQ may move
- * us to another processor.
+ * When handling SCHEDULE_SOFTIRQ, schedule() is called. It then
+ * calls context_switch() which, either, jumps away (on x86), or
+ * returns here in the loop (on ARM). To be safe, in the case where
+ * it returns, we need to re-sample smp_processor_id() at every
+ * iteration, as context_switch() may have changed what's in
+ * the stack pointer register.
*/
cpu = smp_processor_id();