Re: Unwarranted assumption in tst-waitid, or a kernel bug?

[Oleg Nesterov <oleg at redhat dot com>]

On 09/21, Roland McGrath wrote:
>
> As far as I can tell, Linux has never had a guarantee like this.  From a
> cursory look at the code in a few versions, I think the differences
> you've seen between kernel versions are due to scheduling changes, not
> that the actual local constraints in the exit/SIGCHLD/wait code paths
> have changed at all.

Agreed.


Paul, I guess that this test-case "fails" after kill(pid, SIGSTOP),
right?

SIGKILL case is different, we set ->exit_state and notify the parent
atomically under tasklist_lock. But even in this case imho we shouldn't
rely on current behaviour.

> The sequence of events in the kernel is that first the process makes
> itself available for wait (i.e. stopped or zombie), then it sends
> SIGCHLD, and finally it wakes up blocked wait calls that might be
> affected.

Yes, and sys_wait4() can succeed right after "available for wait" and
return to user-mode.

Afaics, this was always true. May be you see the difference because
wait_task_stopped() was changed to avoid tasklist, or probably some
scheduler changes (like child-runs-first tweaks).

I am a bit surprised it never fails on 2.6.18. I think you can add
a small delay into finish_stop() (before it takes tasklist_lock),
then I believe it should fail the same way.

Oleg.