ipfw: LOR/panic with uid rules
Robert Watson
rwatson at FreeBSD.org
Sun Sep 28 14:30:44 UTC 2008
On Fri, 26 Sep 2008, Stefan Ehmann wrote:
> > > #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'?
>
> Something seems to be broken or I'm doing something wrong. I can't access
> the locals:
Dear Stefan:
Could you update to ip_fw2.c:1.195? I've fixed an issue there that caused
ipfw to look up the inpcb even thought it was passed down in the case that a
TCP connection was in TIMEWAIT:
revision 1.195
date: 2008/09/27 19:28:28; author: rwatson; state: Exp; lines: +2 -1
SVN rev 183418 on 2008-09-27 19:28:28Z by rwatson
When an inpcb doesn't have a socket but the inpcb is passed to ipfw
in the transmit path, such as TCPS_TIMEWAIT, fail the credential
extraction immediately rather than acquiring locks and looking up
the inpcb on the global lists in order to reach the conclusion that
the credential extraction has failed.
This is more efficient, but more importantly, it avoids lock
recursion on the inpcbinfo, which is no longer allowed with rwlocks.
This appears to have been responsible for at least two reported
panics.
MFC after: 3 days
Reported by: ganbold
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the freebsd-current
mailing list