Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet (traces)

[Attilio Rao]

2008/3/25, Max Laier <max at love2party.net>:
> Hi Alex,
>
>  so it's basically back to square one.  We only have LORs between the pfil
>  R/W lock (read instance) and mutexes that don't have any lock order with
>  the pfil R/W lock (write instance) at all.  This means the deadlock can't
>  be explained by the LORs that are reported (unless there is something I'm
>  missing).  Unless somebody who is seeing these kind of deadlocks can
>  actually break into a debugger to identify the locks at play, everything
>  else is just speculation.
>
>  I will fix the fastroute LOR with the patch you have been testing,
>  eventhough it didn't fix your problem.  For the remaining issue, we need
>  more IPFW or lock primitives knowledge (extending CC-list).
>
>  Note that the first LOR features a recursive pickup of the pfil R/W lock.
>  I remember that Attilio committed a patch to forbid this for CURRENT.
>  Could this be the cause of a deadlock?  Would it make sense to MFC
>  rm_locks and try if they hold up under this scenario?

I decided to not commit this patch to CURRENT basing on the Robert's
feedback that read recursion in network stack is (will be?)
fundamental.
Likely, it should not explain the deadlock still.
As you point out, the better thing would be using a machine with stock
CVS + DDB + INVARIANTS and check the state of threads and the state of
locks.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein