This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]