Date: Tue, 22 May 2001 15:37:13 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: jhb@FreeBSD.org Cc: current@FreeBSD.org, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Subject: New strategy of locking a process group Message-ID: <200105220637.f4M6bDD40713@rina.r.dl.itc.u-tokyo.ac.jp>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105220637.f4M6bDD40713>