LOR when booting CURRENT (ip_divert.c, PFil hook read/write mutex) [#181]

Christian S.J. Peron csjp at FreeBSD.org
Tue Aug 1 16:14:29 UTC 2006

John Baldwin wrote:
> 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) 
> @ /usr/src/sys/modules/ipdivert/../../netinet/ip_divert.c:350
>>>>   2nd 0xc0a51918 PFil hook read/write mutex (PFil hook read/write mutex) 
> @ /usr/src/sys/net/pfil.c:73
>>> 	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 
> deadlock.
This is true.

However, I am not disputing the validity of witness here, don't get me 
wrong. I think in this case, the LOR between pfil and INP should be 
harmless, because I can not think of any place in our code where we will 
pickup the pfil write lock then an INP lock (or vice versa) since the 
the only place we are picking up write locks for pfil is when we load or 
unload hooks.

Christian S.J. Peron
csjp at FreeBSD.ORG
FreeBSD Committer
FreeBSD Security Team

More information about the freebsd-current mailing list