Re: ipfw: LOR/panic with uid rules

On Fri, 26 Sep 2008, Stefan Ehmann wrote:

> lock order reversal:
> 
> 1st 0xc4c9ee94 tcp_sc_head (tcp_sc_head) _at_ 
> /usr/src/sys/kern/kern_mutex.c:137
> 
> 2nd 0xc0e59fd8 PFil hook read/write mutex (PFil hook read/write mutex) _at_ 
> /usr/src/sys/net/pfil.c:74
> 
> KDB: stack backtrace:
> 
> db_trace_self_wrapper(c0bad7c2,c45aca48,c082cf95,4,c0ba916b,...) at 
> db_trace_self_wrapper+0x26
> 
> kdb_backtrace(4,c0ba916b,c0bb97db,c4879d08,c45acaa4,...) at 
> kdb_backtrace+0x29
> 
> _witness_debugger(c0bb0077,c0e59fd8,c0bb97f3,c4879d08,c0bb97db,...) at 
> _witness_debugger+0x25
> 
> witness_checkorder(c0e59fd8,1,c0bb97db,4a,0,...) at witness_checkorder+0x810
> 
> _rm_rlock_debug(c0e59fd8,c45acaec,c0bb97db,4a,c089e366,...) at 
> _rm_rlock_debug+0x38
> 
> pfil_run_hooks(c0e59fc0,c45acb78,c4b0a000,2,0,...) at pfil_run_hooks+0x3f
> 
> ip_output(c4cbba00,0,0,0,0,...) at ip_output+0x872
> 
> syncache_respond(c5376b00,0,0,0,c45acc48,...) at syncache_respond+0x3a9
> 
> syncache_timer(c4c9ee94,1,c0bab9c2,16b,c0cf3034,...) at syncache_timer+0x147

I believe this is an accepted LOR to do with using an rwlock in this way in 
pfil.

> #10 0xc07eccd6 in _rw_rlock (rw=0xc0e5acec, file=0xc103ceed 
> "/usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c", line=2020) at 
> /usr/src/sys/kern/kern_rwlock.c:283
> 
> #11 0xc103b92a in ipfw_chk (args=0xc47328a8) at 
> /usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2020

This surprises me -- can in principle we've passed down 'inp' so there should 
be no need to look it up.  In higher frames, 'inp' is definitely non-NULL, so 
what happened here?  Could you print out the values of the local variables in 
the check_uidgid() frame?  Especially, 'inp' and 'lookup'?

> #12 0xc103c4c8 in ipfw_check_out (arg=0x0, m0=0xc47329cc, ifp=0xc4b0a000, 
> dir=2, inp=0xc50fe420) at 
> /usr/src/sys/modules/ipfw/../../netinet/ip_fw_pfil.c:253

See non-NULL inp here.

Robert N M Watson
Computer Laboratory
University of Cambridge