linux-kernel - Re: [linux-pm] Attempted summary of suspend-blockers LKML thread

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]

Message-ID: <AANLkTinJ2jy18bAS-=abtDLaQWVmQdK1Oq105FcNDNyJ@mail.gmail.com>
Date:	Tue, 3 Aug 2010 15:08:54 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	James Bottomley <James.Bottomley@...e.de>
Cc:	paulmck@...ux.vnet.ibm.com, peterz@...radead.org,
	swetland@...gle.com, linux-kernel@...r.kernel.org,
	florian@...kler.org, linux-pm@...ts.linux-foundation.org,
	tglx@...utronix.de, alan@...rguk.ukuu.org.uk
Subject: Re: [linux-pm] Attempted summary of suspend-blockers LKML thread

2010/8/3 James Bottomley <James.Bottomley@...e.de>:
> On Mon, 2010-08-02 at 21:18 -0700, Arve Hjønnevåg wrote:
>> > o       A power-aware application must be able to efficiently communicate
>> >        its needs to the system, so that such communication can be
>> >        performed on hot code paths.  Communication via open() and
>> >        close() is considered too slow, but communication via ioctl()
>> >        is acceptable.
>> >
>>
>> The problem with using open and close to prevent an allow suspend is
>> not that it is too slow but that it interferes with collecting stats.
>
> Please elaborate on this.  I expect the pm-qos stats interface will
> collect stats across user open/close because that's how it currently
> works.  What's the problem?
>

The pm-qos interface creates the request object in open and destroys
it in release just like the suspend blocker interface. We need stats
for each client which is lost if you free the object every time you
unblock suspend.

Or are you talking about user space opening and closing the stats
interface (which does not cause any problems)?

>> The wakelock code has a sysfs interface that allow you to use a
>> open/write/close sequence to block or unblock suspend. There is no
>> limit to the amount of kernel memory that a process can consume with
>> this interface, so the suspend blocker patchset uses a /dev interface
>> with ioctls to block or unblock suspend and it destroys the kernel
>> object when the file descriptor is closed.
>
> This is an implementation detail only.

There is no way fix it without changing the user space visible
behavior of the API. The kernel does not know when it is safe to free
the objects.

> The pm-qos objects are long
> lived, so their stats would be too.  I would guess that explicit stat
> clearing might be a useful option.
>

Which pm-qos objects are you referring to? The struct pm_qos_object
that backs each pm-qos class is long lived (I don't know why this is
named pm_qos_object), but we need stats in struct pm_qos_request_list.

-- 
Arve Hjønnevåg
--
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/