LOR when booting CURRENT (ip_divert.c, PFil hook read/write
jhb at freebsd.org
Tue Aug 1 15:45:44 UTC 2006
On Monday 31 July 2006 16:46, Christian S.J. Peron wrote:
> Robert Huff wrote:
> > Yar Tikhiy writes:
> >> FWIW, the LOR still is there. I was seeing it yesterday while
> >> fiddling with the ipfw and natd rc.d scripts.
> >> lock order reversal:
> >> 1st 0xc1a36090 inp (divinp)
> >> 2nd 0xc0a51918 PFil hook read/write mutex (PFil hook read/write mutex)
> > For the record, I'm (still) getting this also.
> > Robert Huff
> > _______________________________________________
> > freebsd-current at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> This appears to be similar to the LOR associated with IPFW and ucred
> based rules, I think. Although this is a lock order reversal and it
> probably isn't a false positive, it should be reasonably harmless,
> because the pfil hook lock is a reader lock, thus different threads can
> acquire it (at this point) con-currently, presumably preventing a dead
> lock from actually occurring here.
> iirc witness it not aware of the reader/writer semantics, so it makes
> sense that it will be dropping a warning here. But I can look at this in
> further detail when I get a bit of time.
No, a LOR is a LOR. Readers vs writers don't matter for ordering reasons.
Talk yourself through it and you'll see. The reason is that a writer can
always block on a reader, and a reader will block if there's a writer already
holding the lock.
While you can end up in some situations where a LOR might not deadlock at the
time if both threads involved are getting read locks, at some point a thread
will need to get a write lock (otherwise you wouldn't need a lock!) and then
you can get a deadlock between the thread with the write lock and a thread
acquiring the locks in reverse order even if that second thread is only
getting a read lock. Specifically, given mtx A, and rwlock B, while it may
be safe for a thread to rlock B and lock A while another thread does lock A
and rlock B w/o triggering deadlock, if a thread does lock A and then wlock
B, then when another tried tries to rlock B and then lock A you will get
More information about the freebsd-current