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

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:


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

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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to