Date: Wed, 12 Jan 2005 18:33:50 +0100 From: Jeremie Le Hen <jeremie@le-hen.org> To: freebsd-current@FreeBSD.org Subject: LOR in IPFilter Message-ID: <20050112173350.GA46508@obiwan.tataz.chchile.org>
next in thread | raw e-mail | index | archive | help
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@.
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@le-hen.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050112173350.GA46508>