Re: [PATCH] pid: use READ_ONCE() in pid_alive()
From: Oleg Nesterov
Date: Mon Oct 05 2026 - 11:08:49 EST
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.