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 <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
