Date: Sun, 24 Nov 2002 02:49:55 +0100 From: Christian Brueffer <chris@unixpages.org> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Panic, possibly MAC related Message-ID: <20021124014955.GK1766@unixpages.org> In-Reply-To: <Pine.NEB.3.96L.1021123101158.81249c-100000@fledge.watson.org> References: <20021123013021.GG1766@unixpages.org> <Pine.NEB.3.96L.1021123101158.81249c-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--aYrjF+tKt+ApYAdb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 23, 2002 at 10:17:14AM -0500, Robert Watson wrote: >=20 > On Sat, 23 Nov 2002, Christian Brueffer wrote: >=20 > > 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.=20 >=20 > 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. >=20 > 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. >=20 > Thanks, >=20 > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories >=20 Hi, seems like I'm finally able to reproduce the panic. It seems to happen when I play around with acpi stuff, especially the hw.acpi.cpu* settings. Unfortunately this has the side effect, that the panic occurs at every boot, so I haven't found a way to get back into the system yet (unset acpi_load at the loader prompt doesn't help). I'm not too familiar with kernel debugging too, so you would probably have to tell me what to type in. - Christian --=20 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 --aYrjF+tKt+ApYAdb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE94DBDbHYXjKDtmC0RAonkAKCl8NZ6AknVnjwWMQ/9zqqY+5/+zACfS27s 1GBuWj+024Gd01NISSDwBS8= =Aey7 -----END PGP SIGNATURE----- --aYrjF+tKt+ApYAdb-- 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?20021124014955.GK1766>