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* *fs_pin* *lifetime*. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
