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

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) 
_at_ /usr/src/sys/modules/ipdivert/../../netinet/ip_divert.c:350
> >>   2nd 0xc0a51918 PFil hook read/write mutex (PFil hook read/write mutex) 
_at_ /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.

-- 
John Baldwin