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) >>>> > _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. > > 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 TeamReceived on Tue Aug 01 2006 - 14:14:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:58 UTC