Date: Sat, 23 Nov 2002 10:17:14 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Christian Brueffer <chris@unixpages.org> Cc: freebsd-current@freebsd.org Subject: Re: Panic, possibly MAC related Message-ID: <Pine.NEB.3.96L.1021123101158.81249c-100000@fledge.watson.org> In-Reply-To: <20021123013021.GG1766@unixpages.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 Nov 2002, Christian Brueffer wrote:
> just got this panic on my notebook. Had to manually shut it down after a
> acpiconf -s 4. At the next bootup, the panic occured. At the moment I'm
> trying to boot into my system again to reproduce it.
In general, this panic occurs in the following situation: each mbuf packet
header has a label structure in it, and the Biba policy stores a per-label
allocated label blob using malloc'd memory. If the packet header is
copied using the copypacket abstractions, then the reference will be
duplicated as will the label data, so each resulting reference will be
separately handled and free'd. However, if the packet header data is
blindly copied without invoking the normal header replication code, then
the same pointer will sit in the new packet header as the old one. When
the two mbufs are free'd, the first one goes fine, but the second one is a
duplicate free. So somehow you managed to trigger a code path that
improperly copies packet headers. Do you have any information on what
process it was that was performing the recvfrom()? One of the code paths
that may present a problem in the base system implementation is a packet
copy for alignment purposes in the KAME code. Another possibility is that
we've seen a regression in existing handling of something like the
fragmentation code, broadcast/multicast, etc. Knowing what's in the
packet and what process it is would help a lot in debugging this. Also,
it would be useful to know what interface this mbuf originated from, if
possible.
So if it's reproduceable, you want to show the pcpu data to find the pid,
then us ps to identify the process. If you have gdb set up (either live
or a dump), seeing the mbuf ifnet pointer value would be valuable, as well
as knowing the domain, type, etc of the socket in question.
Thanks,
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
>
>
> Slab at 0xc26fffc8, freei 19 = 0.
> panic: Dublicate free of item 0xc26ff980 from zone 0xc0e8d000(128)
>
> Debugger("panic")
> Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
> db> tr
> Debugger(c03e24ca,c0475220,c03fb550,d1c9eae4,1) at Debugger+0x54
> panic(c03fb550,c26ff980,c0e8d000,c03e0944,6a8) at panic+0xab
> uma_dbg_free(c0e8d000,c26fffc8.c26ff980,6a8,0) at uma_dbg_free+0x122
> uma_zfree_arg(c0e8d000,c26ff980,c26fffc8,c043b620,80) at uma_zfree_arg+0x124
> free(c26ff980.c044ff60,d1c9eb80,c032a64d,c26ff980) at free+0xe1
> biba_free(c26ff980,c0450260,d1c9eba4,c024244f,c0ee0e30) at biba_free+0x1d
> mac_biba_destroy_label(c0ee0e30,0,c03e06f7,39a,c0ee0e00) at mac_biba_destroy_label+0x1d
> mac_destroy_mbuf(c0ee0e00,0,c261b000,0,d1c9ebc0) at mac_destroy_mbuf+0x7f
> m_free(c0ee0e00,0,d1c9ec6c,20e,0) at m_free+0x41
> soreceive(c278ba00,d1c9ec44,d1c9ec6c,0,0) at soreceive+0x666
> recvit(c261b000,6,d1c9ecb8,bfbff934,8090d10) at recvit+0x1ac
> recvfrom(c261b000,d1c9ed10,c0402882.407,6) at recvfrom+0xa9
> syscall(2f,2f,2f,8090c20,6) at syscall+0x28e
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (29, FreeBSD ELF32, recvfrom), eip = 0x280fdcc3, esp = 0xbfbff8dc, ebp = 0xbfbffbe8
> db>
>
> - Christian
>
> --
> http://www.unixpages.org chris@unixpages.org
> GPG Pub-Key : www.unixpages.org/cbrueffer.asc
> GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
> GPG Key ID : 0xA0ED982D
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021123101158.81249c-100000>