Date: Sat, 5 Oct 2002 03:00:35 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: jmallett@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., [for review]] Message-ID: <200210051000.g95A0ZvU023752@gw.catspoiler.org> In-Reply-To: <20021005002021.A14635@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Oct, Juli Mallett wrote:
> diff -Nrdu -x *CVS* -x *dev* sys/kern/kern_exit.c kernel/kern/kern_exit.c
> --- sys/kern/kern_exit.c Tue Oct 1 12:15:51 2002
> +++ kernel/kern/kern_exit.c Sat Oct 5 01:20:57 2002
> @@ -209,12 +210,12 @@
> PROC_LOCK(p);
> if (p == p->p_leader) {
> q = p->p_peers;
> + PROC_UNLOCK(p);
> while (q != NULL) {
> - PROC_LOCK(q);
> psignal(q, SIGKILL);
> - PROC_UNLOCK(q);
> q = q->p_peers;
> }
> + PROC_LOCK(p);
> while (p->p_peers)
> msleep(p, &p->p_mtx, PWAIT, "exit1", 0);
> }
This scary looking fragment of code in exit1() is relying on the lock on
p->p_leader being continuously held to prevent the p_peers list from
changing while the list traversal is in progress. The code in
kern_fork.c and elsewhere in kern_exit.c holds a lock on p_leader while
the list modifications are done.
The existing code looks like it could deadlock if q is locked because it
is in fork() or exit(). Process p will block when it tries to lock q,
and q will block when it tries to lock its p_leader, which happens to be
p.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210051000.g95A0ZvU023752>