Re: panic: mutex Giant not owned at src/sys/security/mac/mac_net.c:355

On Thu, 22 Apr 2004, Simon L. Nielsen wrote:

> On 2004.04.22 17:19:32 -0400, Robert Watson wrote:
> > 
> > On Thu, 22 Apr 2004, Simon L. Nielsen wrote:
> > 
> > > I have a reproduceable panic when I have MAC enabled in my kernel and I
> > > try to run tcpdump on the interface I have logged in on via ssh (I'm not
> > > really sure why it only happens in this case and in other cases).  I run
> > > "tcpdump -n -i sis0" and the panic as shown below.  I do not have any
> > > MAC policies loaded. 
> > > 
> > > The problem is (if I understand the code correctly) that MAC calls
> > > BPFD_LOCK_ASSERT, which rwatson added NET_ASSERT_GIANT to, but since the
> > > sis interrupt handler is marked INTR_MPSAFE then GIANT isn't aquired
> > > before bpf_mtap (and therefor mac_check_bpfdesc_receive) is called.
> > > 
> > > I'm not really sure what the correct fix is, but if bpf is locked, is
> > > GIANT really required for it?
> > 
> > Are you running a main line kernel with debug.mpsafenet turned on?
> 
> Main line kernel (I assume you mean no special patches), but
> debug.mpsafenet is turned off. 
> 
> [root_at_soekris:~] sysctl debug.mpsafenet
> debug.mpsafenet: 0

In the main line kernel with debug.mpsafenet turned off, INTR_MPSAFE is
supposed to be ignored for network interrupts, resulting in inbound
network stack code running with Giant held.  Is there any chance that the
interrupt thread is being shared with another device?  dmesg output would
be useful, along with some devinfo output.  It could be there's a problem
resulting in Giant not being held under those circumstances, or that Giant
is being dropped somewhere it shouldn't be. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Senior Research Scientist, McAfee Research