Re: Anomalies while handling p_nstopchild count

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Sat, 10 Oct 2015 11:15:20 -0400
   From: christos%zoulas.com@localhost (Christos Zoulas)

   On Oct 10,  2:37pm, campbell+netbsd-tech-kern%mumble.net@localhost (Taylor R Campbell) wrote:
   -- Subject: Re: Anomalies while handling p_nstopchild count

   | I don't think that's why he put that there -- it's just that the lock
   | order is proc_lock first, then p->p_lock for any p.  This is the
   | optimistic reverse-order locking fragment that the mutex(9) man page
   | suggests.

   Yes, but if you know proc_lock is not being held, calling tryenter is
   not an optimization! The man page should be clarified that the example
   checks and corrects the lock order *if it was broken*. Unless I am missing
   something obvious...

proc_lock may be held by another thread even if the caller is
guaranteed not to hold it.  The other thread may furthermore be
waiting on p->p_lock, in which case acquiring p->p_lock here would
lead to deadlock -- but mutex_tryenter would simply fail.

The optimization is to optimistically assume nobody else is holding
proc_lock and do mutex_tryenter.  Otherwise, we back out and acquire
both locks in the correct order.