Comment 6 for bug 1876230

Sorry to jump in, I wrote the membarrier syscall LTP interface test (https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/membarrier/membarrier01.c) when I was at Linaro and felt attracted to reading all this during my bug triage day =).

So, for MEMBARRIER_CMD_PRIVATE_EXPEDITED, you said at the description:

" It only targets threads which share the same mm as the thread calling the membarrier syscall "

And it occurred to me right away:

"Are there any dependencies using liburcu and Shared Mem IPC" ?

Mainly because the private expedited only guarantees the barrier - for the RCU graceful period - among sibling tasks sharing the same address space and thread id (which share the same mm) -> of course this explains why it is much faster, specially in an OS containing tons of running tasks.. or even worse: in a VM with tons of running tasks PLUS vcpus coming in and out the real ones.

So, I think my message here, specially for the SRU team, as this is changing the behavior of librcu library for a LTS version, is:

- apart from feedback given by @mruffell, to also check if any of librcu consumers are depending on a full membarrier - driven by kernel - for ** shared pages among different processes **

before accepting this as a SRU. Or else we're changing synchronization primitives of all dependencies and this would not be good =o).

I think this criteria may also help in the SRU acceptance ^