Messages in this thread | | | Date | Thu, 27 Jul 2017 21:55:51 +0800 | From | Boqun Feng <> | Subject | Re: [PATCH tip/core/rcu 4/5] sys_membarrier: Add expedited option |
| |
Hi Paul,
I have a side question out of curiosity:
How does synchronize_sched() work properly for sys_membarrier()?
sys_membarrier() requires every other CPU does a smp_mb() before it returns, and I know synchronize_sched() will wait until all CPUs running a kernel thread do a context-switch, which has a smp_mb(). However, I believe sched flavor RCU treat CPU running a user thread as a quiesent state, so synchronize_sched() could return without that CPU does a context switch.
So why could we use synchronize_sched() for sys_membarrier()?
In particular, could the following happens?
CPU 0: CPU 1: ========================= ========================== <in user space> <in user space> {read Y}(reordered) <------------------------------+ store Y; | read X; --------------------------------------+ | sys_membarrier(): <timer interrupt> | | synchronize_sched(); update_process_times(user): //user == true | | rcu_check_callbacks(usr): | | if (user || ..) { | | rcu_sched_qs() | | ... | | <report quesient state in softirq> | | <return to user space> | | read Y; --------------------------------------+----+ store X; | {read X}(reordered) <-------------------------+
I assume the timer interrupt handler, which interrupts a user space and reports a quiesent state for sched flavor RCU, may not have a smp_mb() in some code path.
I may miss something subtle, but it just not very obvious how synchronize_sched() will guarantee a remote CPU running in userspace to do a smp_mb() before it returns, this is at least not in RCU requirements, right?
Regards, Boqun [unhandled content-type:application/pgp-signature] | |