From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 29 08:46:37 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B41A03E5; Thu, 29 Nov 2012 08:46:37 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep19.mx.upcmail.net (fep19.mx.upcmail.net [62.179.121.39]) by mx1.freebsd.org (Postfix) with ESMTP id C4BB98FC16; Thu, 29 Nov 2012 08:46:35 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep19-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20121129084628.QFBW26940.viefep19-int.chello.at@edge04.upcmail.net>; Thu, 29 Nov 2012 09:46:28 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id VLmU1k00M2xdvHc04LmURT; Thu, 29 Nov 2012 09:46:28 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 07CAE6D465; Thu, 29 Nov 2012 09:46:28 +0100 (CET) Date: Thu, 29 Nov 2012 09:46:27 +0100 From: Stefan Farfeleder To: Andriy Gapon Subject: Re: ACPI panic Message-ID: <20121129084627.GA1450@mole.fafoe.narf.at> References: <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> <50B33693.2060000@FreeBSD.org> <20121126093704.GB1469@mole.fafoe.narf.at> <50B34484.1090807@FreeBSD.org> <20121126104737.GC1469@mole.fafoe.narf.at> <50B34EEA.4000209@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50B34EEA.4000209@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 08:46:37 -0000 On Mon, Nov 26, 2012 at 01:13:46PM +0200, Andriy Gapon wrote: > > Also, I've just realized that the check is racy... > Could you please move the whole check block (between and excluding > AcpiUtAcquireMutex and AcpiUtReleaseMutex) down right below the following lines: > > Status = AcpiUtAcquireMutex (ACPI_MTX_CACHES); > if (ACPI_FAILURE (Status)) > { > return (Status); > } Sorry for the delay. I'm now running the patch below. I still got the cycle panic, this time with a 4-objects cycle. It looks like an object gets released twice but I don't understand why the "freeing a free object" check fails to trigger. Stefan Index: components/utilities/utcache.c =================================================================== --- components/utilities/utcache.c (revision 243234) +++ components/utilities/utcache.c (working copy) @@ -244,6 +244,28 @@ return (Status); } + char *Curr; + char *Next; + int Depth; + Depth = Cache->CurrentDepth; + Next = Cache->ListHead; + while (Next) + { + Curr = Next; + Next = *(ACPI_CAST_INDIRECT_PTR (char, + &(((char *) Curr)[Cache->LinkOffset]))); + if (*(const unsigned char *) Curr != 0xCA) { + panic("detected use after free %p\n", Curr); + } + if (Object == Curr) { + panic("freeing a free object %p", Object); + } + Depth--; + if (Depth < 0) { + panic("cycle in a cache list"); + } + } + /* Mark the object as cached */ ACPI_MEMSET (Object, 0xCA, Cache->ObjectSize); @@ -312,6 +334,10 @@ Cache->CurrentDepth--; + if (*(const unsigned char *) Object != 0xCA) { + panic("detected use after free %p\n", Object); + } + ACPI_MEM_TRACKING (Cache->Hits++); ACPI_DEBUG_PRINT ((ACPI_DB_EXEC, "Object %p from %s cache\n", Object, Cache->ListName));