Re: [RFC PATCH] introduce sys_membarrier(): process-wide memory barrier

Steven Rostedt
2010-01-07T19:40:48Z

On Thu, 2010-01-07 at 11:16 -0800, Paul E. McKenney wrote:

> > Note, we are not suggesting optimizations. It has nothing to do with
> > performance of the syscall. We just can't allow one process to be DoSing
> > another process on another cpu by it sending out millions of IPIs.
> > Mathieu already showed that you could cause a 2x slowdown to the
> > unrelated tasks.
>
> I would have said that we are trying to optimize our way out of a DoS
> situation, but point taken. Whatever we choose to call it, the discussion
> is on the suggested modifications, not strictly on the original patch. ;-)

OK, I just want to get a better understanding of what can go wrong. A
sys_membarrier() is used as follows, correct? (using a list example)

<user space>

list_del(obj);

synchronize_rcu(); -> calls sys_membarrier();

free(obj);

And we need to protect against:

<user space>

read_rcu_lock();

obj = list->next;

use_object(obj);

read_rcu_unlock();

where we want to make sure that the synchronize_rcu() makes sure that we
have passed the grace period of all takers of read_rcu_lock(). Now I
have not looked at the code that implements userspace rcu, so I'm making
a lot of assumptions here. But the problem that we need to avoid is:

CPU 1 CPU 2
----------- -------------

<user space> <user space>

rcu_read_lock();

obj = list->next

list_del(obj)

< Interrupt >
< kernel space>
<schedule>

<kernel_thread>

<schedule>

< back to original task >

sys_membarrier();
< kernel space >

if (task_rq(task)->curr != task)
< but still sees kernel thread >

< user space >

< misses that we are still in rcu section >

free(obj);

< user space >

use_object(obj); <=== crash!

I guess what I'm trying to do here is to understand what can go wrong,
and then when we understand the issues, we can find a solution.

-- Steve