linux-kernel - Re: WARNING: CPU: 0 PID: 2623 at drivers/pnp/pnpacpi/core.c:96 pnpacpi_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Jul 2014 11:13:55 -0700
From:	Vinson Lee <vlee@...pensource.com>
To:	William Dauchy <wdauchy@...il.com>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Zdenek Kabelac <zkabelac@...hat.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: WARNING: CPU: 0 PID: 2623 at drivers/pnp/pnpacpi/core.c:96 pnpacpi_set_resource

On Tue, Jul 29, 2014 at 2:53 AM, William Dauchy <wdauchy@...il.com> wrote:
> Hi Vinson,
>
> On Mon, Jul 28, 2014 at 9:11 PM, Vinson Lee <vlee@...pensource.com> wrote:
>> The warning first happens with 3.14-rc1. The warning does not occur with 3.13.0.
>
> Hitting the same issue here with a similar trace on 3.14.x. Did you
> start bisecting?
>
> Regards,
> --
> William


I bisected the warning that I'm seeing to this commit.

commit 202317a573b20d77a9abb7c16a3fd5b40cef3d9d
Author: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
Date:   Fri Nov 22 21:54:37 2013 +0100

    ACPI / scan: Add acpi_device objects for all device nodes in the namespace

    Modify the ACPI namespace scanning code to register a struct
    acpi_device object for every namespace node representing a device,
    processor and so on, even if the device represented by that namespace
    node is reported to be not present and not functional by _STA.

    There are multiple reasons to do that.  First of all, it avoids
    quite a lot of overhead when struct acpi_device objects are
    deleted every time acpi_bus_trim() is run and then added again
    by a subsequent acpi_bus_scan() for the same scope, although the
    namespace objects they correspond to stay in memory all the time
    (which always is the case on a vast majority of systems).

    Second, it will allow user space to see that there are namespace
    nodes representing devices that are not present at the moment and may
    be added to the system.  It will also allow user space to evaluate
    _SUN for those nodes to check what physical slots the "missing"
    devices may be put into and it will make sense to add a sysfs
    attribute for _STA evaluation after this change (that will be
    useful for thermal management on some systems).

    Next, it will help to consolidate the ACPI hotplug handling among
    subsystems by making it possible to store hotplug-related information
    in struct acpi_device objects in a standard common way.

    Finally, it will help to avoid a race condition related to the
    deletion of ACPI namespace nodes.  Namely, namespace nodes may be
    deleted as a result of a table unload triggered by _EJ0 or _DCK.
    If a hotplug notification for one of those nodes is triggered
    right before the deletion and it executes a hotplug callback
    via acpi_hotplug_execute(), the ACPI handle passed to that
    callback may be stale when the callback actually runs.  One way
    to work around that is to always pass struct acpi_device pointers
    to hotplug callbacks after doing a get_device() on the objects in
    question which eliminates the use-after-free possibility (the ACPI
    handles in those objects are invalidated by acpi_scan_drop_device(),
    so they will trigger ACPICA errors on attempts to use them).

    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
    Tested-by: Mika Westerberg <mika.westerberg@...ux.intel.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/