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.orgReceived 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