From owner-cvs-all@FreeBSD.ORG Wed Sep 20 17:24:03 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7047616A40F; Wed, 20 Sep 2006 17:24:03 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CBA443D5C; Wed, 20 Sep 2006 17:23:55 +0000 (GMT) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id k8KHNnXI085559; Wed, 20 Sep 2006 19:23:50 +0200 (CEST) (envelope-from mb@imp.ch) Date: Wed, 20 Sep 2006 19:23:49 +0200 (CEST) From: Martin Blapp To: John Baldwin In-Reply-To: <200609201109.13271.jhb@freebsd.org> Message-ID: <20060920192017.R1494@godot.imp.ch> References: <200609191925.k8JJPBaH091145@repoman.freebsd.org> <200609191714.46864.jhb@freebsd.org> <20060920012110.P1494@godot.imp.ch> <200609201109.13271.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 157.161.9.65 Cc: cvs-src@FreeBSD.org, Martin Blapp , cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_proc.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2006 17:24:03 -0000 >> mtx_init(&sess->s_mtx, "session", NULL, MTX_DEF); >> PROC_LOCK(p); >> p->p_flag &= ~P_CONTROLT; >> PROC_UNLOCK(p); >> PGRP_LOCK(pgrp); >> sess->s_leader = p; >> sess->s_sid = p->p_pid; >> sess->s_count = 1; >> sess->s_ttyvp = NULL; >> sess->s_ttyp = NULL; So we need GIANT too after the text 'else' ... What do you think ? > Well, I'd rather use whatever lock we end up using for t_session instead > of assuming it's going to be proctree_lock, so I'd like to leave t_session > only under Giant for now until we really know what we are doing. Ok. Should I back out tty.c rev. v. 1.258 or just going to work on the tty lock directly and replace it with whatever lock we use in CURRENT ? I'll only MFC the other part ... Martin