From owner-freebsd-current Mon Oct 7 4:20:33 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8E3237B401; Mon, 7 Oct 2002 04:20:31 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4223143E4A; Mon, 7 Oct 2002 04:20:31 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021007112030.XKIL27763.sccrmhc02.attbi.com@InterJet.elischer.org>; Mon, 7 Oct 2002 11:20:30 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id EAA33253; Mon, 7 Oct 2002 04:12:47 -0700 (PDT) Date: Mon, 7 Oct 2002 04:12:46 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Stefan Farfeleder , John Baldwin , Juli Mallett , current@FreeBSD.ORG Subject: Re: [PATCH] Re: Junior Kernel Hacker page updated... In-Reply-To: <3DA1668D.E8153F43@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Oct 2002, Terry Lambert wrote: > Stefan Farfeleder wrote: > > > > I'm confused why marker - if it was removed by TAILQ_REMOVE - hasn't > > kn_tqe.tqe_next and kn_tqe.tqe_prev set to (void *)-1. because that only happens if the debug code in queue.h is enabled, which it is not.. > > OK, what this means is that the marker queue entry was removed > by something else going in there. > > THis shouldn't happen. > > Try adding this before the initialization of the marker data: > > bzero(&marker, sizeof(marker)); > > That should keep it from matching any removal criteria. THe only > way this could keep crashing after this mod is if the queue is > being destroyed out from under you. > > The implication here is that the queue should be protected by the > object lock for the object for which the pointer to the queue > instance is an element. > > Fixing this would be very hard (IMO). > > The next step (assuming it still panics) is to add: > > #define KQ_FREE 0x80 > > ...and set it into kq_state on a kqueue that has been freed and/or > deallocated somewhere (then check to see if it's set, after the > panic). Ugly, but it will tell you whether or not that's what's > happening (scanning a dead queue). > > The worst case is scanning a dead queue quose memory has been > reused for some other purpose. 8-(. > > I can't personally repeat the problem, so you're elected to do > the legwork on this one. 8-(. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message