[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E368CB39A9@ORSMSX101.amr.corp.intel.com>
Date: Thu, 14 Feb 2013 02:31:22 +0000
From: "Moore, Robert" <robert.moore@...el.com>
To: "Rafael J. Wysocki" <rjw@...k.pl>, Toshi Kani <toshi.kani@...com>
CC: ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Jiang Liu <liuj97@...il.com>, Yinghai Lu <yinghai@...nel.org>,
Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
Myron Stowe <mstowe@...hat.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: RE: [Update][PATCH] ACPI / hotplug: Fix concurrency issues and
memory leaks
> > > I thought about that, but actually there's no guarantee that the
> > > handle will be valid after _EJ0 as far as I can say. So the race
> > > condition is going to be there anyway and using struct acpi_device
> > > just makes it easier to avoid it.
> >
> > In theory, yes, a stale handle could be a problem, if _EJ0 performs
> > unload table and if ACPICA frees up its internal data structure
> > pointed by the handle as a result. But we should not see such issue
> > now since we do not support dynamic ACPI namespace yet.
>
> I'm waiting for information from Bob about that. If we can assume ACPI
> handles to be always valid, that will simplify things quite a bit.
If a table is unloaded, all the namespace nodes for that table are removed from the namespace, and thus any ACPI_HANDLE pointers go stale and invalid.
Bob
Powered by blists - more mailing lists