On 26.08.21 11:40, Dongjiu Geng wrote: > Hi, > I see cpu_public->cpu_suspended is protected by spinlock, but I > see there is no concurrency problem for the cpu_public->cpu_suspended. > check_events() is the only place to change cpu_public->cpu_suspended > variableļ¼ other CPU can not change is variable, also check_events() > is > not preempted in the current CPU, because IRQ is masked in the current > CPU. So there is no need to add spin_lock for > cpu_public->cpu_suspended variable. >
The lock protects (among other things) the consistent view on and modifications of suspend_cpu and cpu_suspended. You have on CPU setting suspend_cpu as a request and another CPU being the target, evaluating it and setting cpu_suspended when actually having reached that state. You can't remove the lock without risking racing between the two CPUs. Maybe not all of them will lead to inconsistent states, but some can, and arguing that those will not happen in reality is much harder (if possible at all) than placing these locks here. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/e6df60db-8a0c-a0e6-7880-547edbcf1c6d%40siemens.com.
