LOR in IPFilter

From: Jeremie Le Hen <jeremie_at_le-hen.org>
Date: Wed, 12 Jan 2005 18:33:50 +0100
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) _at_ kern/kern_timeout.c:257
    2nd 0x... ipf fragment rwlock (ipf fragment rwlock) _at_ 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_at_'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
Received on Wed Jan 12 2005 - 16:33:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:26 UTC