On Tue, 22 May 2001 04:48:38 -0700 (PDT),
John Baldwin <[EMAIL PROTECTED]> said:
John> On 22-May-01 Seigo Tanimura wrote:
>> For now, p_mtx protects p_pgrp in struct proc. This is quite
>> troublesome for the following reason:
John> Err, it doesn't really. It's mostly undecided at this point. Also, have you
John> looked at the BSD/OS code on builder? They have process groups and sessions
John> already locked not using global locks but using per-data structure locks.
If you do not protect both p_pgrp and p_pglist in struct proc by an
identical lock, you end up with breaking either setpgid(2) or kill(2)
for a process group. The following scenario depicts an example of the
breakage:
There is a process p that belongs to a process group G. A process q
issues setpgid(2) to move p into a process group H, when the process p
sends a signal to the process group to which p belongs by kill(2) with
pid of zero.
In this case, if p takes its new p_pgrp (which points to H) during
which q attempts to remove p from G (this is possible if we lock p and
G individually), p might fail to send the signal to p itself and the
processes in H might receive a spurious signal.
You might state that locking p_pgrp of p by p_mtx first and pg_members
in G by pg_mtx (process group mutex) next should solve that
problem. This method actually breaks kill(2) for a process group
because our start point is now not a process but a process group. In
this case, we should lock a process group first, followed by a
process. The result is a lock order reversal and potential deadlock
between setpgid(2) and kill(2).
Of course, not all members of struct pgrp needs to be locked by a
global lock. A lock per a process group is enough to protect
pg_sigiolst and pg_jobc. Implementation of per-data structure locks is
done for pgrp and in progress for session.
Finally, a fact missing in my last mail. psignal() actually checks for
the parent of a process, possibly sending SIGCHLD to it. This implies
that we have to slock proctree_lock so that the process hierarchy does
not change. Now that psignal() calls for both pgrpsess_lock and
proctree_lock, it should be cheaper to have only proctree_lock than
both of them.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
