Re: [PATCH tip/core/rcu 4/5] sys_membarrier: Add expedited option

From: Boqun Feng
Date: Thu Jul 27 2017 - 09:55:55 EST


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

Attachment: signature.asc
Description: PGP signature