linux-kernel - Re: [PATCH v3] ACPI / Sleep: Check low power idle constraints for debug only

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] [day] [month] [year] [list]

Date:   Sun, 13 Aug 2017 02:54:56 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Mario Limonciello <mario.limonciello@...l.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH v3] ACPI / Sleep: Check low power idle constraints for
 debug only

On Sun, Aug 13, 2017 at 2:00 AM, Srinivas Pandruvada
<srinivas.pandruvada@...ux.intel.com> wrote:
> On Sun, 2017-08-13 at 00:37 +0200, Rafael J. Wysocki wrote:
>> On Sat, Aug 12, 2017 at 5:59 PM, Srinivas Pandruvada
>> <srinivas.pandruvada@...ux.intel.com> wrote:
>> >
>> > On Sat, 2017-08-12 at 16:27 +0200, Rafael J. Wysocki wrote:
>> > [...]
>> >
>> > >
>> > > >
>> > > > +
>> > > > +struct lpi_constraints {
>> > > > +   char *name;
>> > > > +   int min_dstate;
>> > > If you store the handle here as well, you won't need to
>> > > look it up every time _check_constraints() is called.
>> > The reason I didn't keep handle here, I thought handle can be stale
>> > or
>> > change for PnP device on plug in and out. Is this not true?
>> The handles don't go away on hot remove as a rule.  That may only
>> happen if tables get unloaded, but basically the constraints should
>> not point to anything in a table that may go away.
>
> So we don't need to worry about this case where tables gets unloaded
> and replaced?

I wouldn't. :-)

We generally don't support that case entirely, so why bother?

> This is in a debug path, so additional overhead of path
> to handle conversion may not be significant.

Well, it still is wasted cycles ...