LOR in IPFilter

Jeremie Le Hen jeremie at le-hen.org
Wed Jan 12 09:33:54 PST 2005


Hi,

I recompiled my kernel with source tree upgraded around
2005.01.12.00.00.00 and I get the following LOR (pasted by hand) :

%%%
  lock order reversal
    1st 0x... dont_sleep_in_callout (dont_sleep_in_callout) @ kern/kern_timeout.c:257
    2nd 0x... ipf fragment rwlock (ipf fragment rwlock) @ contrib/ipfilter/netinet/ip_frag.c:529
  KDB: stack backtrace:
  kdb_backtrace()
  witness_checkorder()
  _sx_xlock()
  ipfr_fragexpire()
  ipfr_slowtimer()
  ithread_loop()
  fork_exit()
  fork_trampoline()
%%%

I looked a bit at the source and I understood that when DIAGNOSTIC is
defined, then the softclock() function from kern_timeout.c use a kind a
dummy mutex to prevent the callout function from sleeping.
Unfortunately the ipfr_fragexpire() from ip_frag.c use a sx_lock...

(voir en quoi consitent les sx_lock)

On the other hand, I have serious feeling that I'm somewhat the culprit
since:

    o I know that the use of sx(9) locks have already been discussed [1]
      with Darren Reed but I can't find it on bz@'s page referencing
      all known LORs [2].
    o No such report appeared on current at .
    o I don't remember any significant commit in either ip_frag.c or
      kern_timeout.c since my last kernel update on 2004/12/28.
    o Looking at the code path [3] shows off that the ipfr_fragexpire()
      function must be automatically called when the module loader
      function is called, thus this LOR should already have been
      triggered IMHO.

Regards,

[1] http://lists.freebsd.org/pipermail/cvs-src/2004-December/thread.html#37421
[2] http://sources.zabbadoz.net/freebsd/lor.html
[3] ipfilter_modevent() -> iplattach() -> timeout(&ipfr_slowtimer) ;
    ipfr_slowtimer() -> ipfr_fragexpire()
-- 
Jeremie Le Hen
jeremie at le-hen.org


More information about the freebsd-current mailing list