From owner-freebsd-hackers Fri Oct 23 02:52:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA12546 for freebsd-hackers-outgoing; Fri, 23 Oct 1998 02:52:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA12541 for ; Fri, 23 Oct 1998 02:52:41 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id CAA11688; Fri, 23 Oct 1998 02:52:01 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id CAA21918; Fri, 23 Oct 1998 02:52:00 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id CAA20536; Fri, 23 Oct 1998 02:51:59 -0700 (PDT) From: Don Lewis Message-Id: <199810230951.CAA20536@salsa.gv.tsc.tdk.com> Date: Fri, 23 Oct 1998 02:51:58 -0700 In-Reply-To: "Jukka A. Ukkonen" "question about getsid()" (Oct 21, 4:19pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Jukka A. Ukkonen" , hackers@FreeBSD.ORG Subject: Re: question about getsid() Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Oct 21, 4:19pm, "Jukka A. Ukkonen" wrote: } Subject: question about getsid() } When looking at the 3.0 getsid() code in kern_prot.c I became } a little hesitant about whether the following code will always } work... } } int } getsid(p, uap) } struct proc *p; } struct getsid_args *uap; } { } if (uap->pid == 0) } goto found; } } if ((p == pfind(uap->pid)) == 0) } return ESRCH; } found: } p->p_retval[0] = p->p_pgrp->pg_session->s_leader->p_pid; } return 0; } } } } What will happen if the process leader has already died? } Will the original session leader's process struct still be } around available for reference or will the code fail? It looks to me like the code will follow a stale pointer off into space. I suspect the result will be a bogus return value rather than a panic. } My own implementation of the same thing added a new field } `s_sid' to the session struct, because I suspected problems } doing it the way the current 3.0 code does. } This new field is in my version initialized during setsid() } using the PID of the session leader, but the code does not } assume the process struct for the session leader being } available later, because `s_sid' content will be returned } by getsid(). That sounds reasonable. fork1() in kern_fork.c should also be fixed so that it avoids reusing the process id of the former session leader until after the session is gone. This is similar to how it already avoids reusing a process group id. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message