Re: [PATCH] pid: use READ_ONCE() in pid_alive()

[Oleg Nesterov <oleg@redhat.com>]

On 10/04, David Laight wrote:
>
> I was wondering if the (partial) rcu protection of these lists was worth
> the trouble.

At the top of my head, probably not... At least right now. We can improve
this, say we can change attach_pid() to use hlist_add_behind_rcu(). This way
the lockless do_each_pid() won't "obviously race" with fork(). But this won't
solve other problems.

> If the 'add code' all the readers and have to hold the lock then does that
> leave anything other than task exit doing an rcu-delete.
> I wouldn't have though acquiring the lock in the task exit code would
> be noticeable.

Still can't understand. The exiting task does take tasklist when it calls
detach_pid().

> > I don't think it can. Say, __kill_pgrp_info() is a "typical" user of
> > do_each_pid_task(). What can it do if it detects that get_nulls_value()
> > doesn't match after the main loop? The signal was already sent.
>
> It would have to check each entry to ensure it was on the correct list.
> (That probably doesn't need the 'nulls' variant.)
> The problem is that the rescan will do things twice.
> This is ok for a search, but probably not for sending a signal.

Yes, exactly.

Oleg.