Date: Fri, 23 Oct 1998 02:51:58 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: "Jukka A. Ukkonen" <jau@jau.tmt.tele.fi>, hackers@FreeBSD.ORG Subject: Re: question about getsid() Message-ID: <199810230951.CAA20536@salsa.gv.tsc.tdk.com> In-Reply-To: "Jukka A. Ukkonen" <jau@jau.tmt.tele.fi> "question about getsid()" (Oct 21, 4:19pm)
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810230951.CAA20536>