Re: [PATCH 2/3] task: RCU protect tasks on the runqueue

[Peter Zijlstra]

On Tue, Sep 03, 2019 at 01:13:22PM -0500, Eric W. Biederman wrote:

> I think this is where I am looking a things differently than you and
> Peter.  Why does it have to be ___schedule() that changes the value
> in the task_struct?  Why can't it be something else that changes the
> value and then proceeds to call schedule()?

If you call schedule() you will pass through plenty that already implies
smp_mb() before writing the ->curr pointer. If you care about that case,
adding RELEASE semantics to that store gains you absolutely nothing
except a marginally slower kernel.

> If we use RCU_INIT_POINTER if there was something that changed
> task_struct and then called schedule() what ensures that a remote cpu
> that has a stale copy of task_struct cached will update it's cache
> after following the new value rq->curr?  Don't we need
> rcu_assign_pointer to get that guarantee?

That whole construct doesn't really make sense: one it is very rare to
change task_struct content for !current tasks (and if we do, it must be
with atomic ops, because then there can be concurrency), secondly when
calling schedule() there is no guarantee on what @next will be.