From owner-freebsd-current  Mon May 21 23:37:33 2001
Delivered-To: freebsd-current@freebsd.org
Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247])
	by hub.freebsd.org (Postfix) with ESMTP
	id 22C1337B43C; Mon, 21 May 2001 23:37:28 -0700 (PDT)
	(envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp)
Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1])
	by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f4M6bDD40713 ;
	Tue, 22 May 2001 15:37:14 +0900 (JST)
Message-Id: <200105220637.f4M6bDD40713@rina.r.dl.itc.u-tokyo.ac.jp>
Date: Tue, 22 May 2001 15:37:13 +0900
From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>
To: jhb@FreeBSD.org
Subject: New strategy of locking a process group
Cc: current@FreeBSD.org,
	Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>
User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd)
Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-current.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-current>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-current>
X-Loop: FreeBSD.ORG

For now, p_mtx protects p_pgrp in struct proc. This is quite
troublesome for the following reason:

In some cases, we grab a p_pgrp via struct proc in order to, say,
access the session information of the process group. In other cases,
we traverse the members of a process group in order to, say, send a
signal to the process group. Those cases imply that it is likely to
end up with lock order reversal if we adopt p_mtx to protect a process
group.

The lock of process groups should hence not in a certain struct but
global. Although proc.h suggests locking by proctree_lock, it is
actually not a good candidate of the process group lock because the
hierarchy of processes does not affect the process group membership of
a process provided that security constraints satisfy.

I have thus introduced a new sx lock, pgrpsess_lock to protect data
regarding process groups, namely the following ones:

global:
	pgrphashtbl

struct proc:
	p_pglist, p_pgrp

struct pgrp:
	pg_hash, pg_members, pg_session

pg_session is here for the case where we attempt to confirm whether
two processes or process groups belong to an identical session, eg:

	if (p->p_session == curproc->p_session) {...}

The lock order of pgrpsess_lock is between proctree_lock and p_mtx for
now.

The major impact of pgrpsess_lock is that you must slock pgrpsess_lock
to call psignal() and issignal() (not only pgsignal()!) because both
of them may read the data of a process group.

We may also have to introduce something like pfind_lockpgrp(), which
locks pgrpsess_lock upon returning. This eliminates a sequence of
PROC_UNLOCK() - sx_slock(&pgrpsess_lock) - PROC_LOCK() to avoid
unlocking a process.

Implementation of pgrpsess_lock is almost finished. The rest of the
work includes protection of the members in struct pgrp and session not
covered by pgrpsess_lock.

-- 
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