Date: Tue, 22 May 2001 21:58:10 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: jhb@FreeBSD.org Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, current@FreeBSD.org Subject: RE: New strategy of locking a process group Message-ID: <200105221258.f4MCwAD85296@rina.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: In your message of "Tue, 22 May 2001 04:48:38 -0700 (PDT)" <XFMail.010522044838.jhb@FreeBSD.org> References: <200105220637.f4M6bDD40713@rina.r.dl.itc.u-tokyo.ac.jp> <XFMail.010522044838.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 May 2001 04:48:38 -0700 (PDT), John Baldwin <jhb@FreeBSD.org> 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 <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105221258.f4MCwAD85296>