[PATCH review 11/11] mnt: Honor MNT_LOCKED when detaching mounts
viro at ZenIV.linux.org.uk
Sat Jan 10 05:51:48 UTC 2015
On Fri, Jan 09, 2015 at 11:32:47PM -0600, Eric W. Biederman wrote:
> I don't believe rcu anything in this function itself buys you anything,
> but structuring this primitive so that it can be called from an rcu list
> traversal seems interesting.
Without RCU, what would prevent it being freed right under us?
The whole point is to avoid pinning it down - as it is, we can have
several processes call ->kill() on the same object. The first one
would end up doing cleanup, the rest would wait *without* *affecting*
Note that I'm using autoremove there for wait.func(), then in the wait
loop I check (without locks) wait.task_list being empty. It is racy;
deliberately so. All I really care about in there is checking that
wait.func has not been called until after rcu_read_lock(). If that is
true, we know that p->wait hadn't been woken until that point, i.e.
p hadn't reached rcu delay on the way to being freed until after our
rcu_read_lock(). Ergo, it can't get freed until we do rcu_read_unlock()
and we can safely take p->wait.lock.
RCU is very much relevant there.
More information about the Containers