linux-kernel - Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

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:	Thu, 6 May 2010 20:10:46 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	James Kosin <james.kosin.04@....edu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

2010/5/6 James Kosin <james.kosin.04@....edu>:
> On 5/6/2010 10:53 PM, Arve Hjønnevåg wrote:
>> On Thu, May 6, 2010 at 7:41 PM, James Kosin <james.kosin.04@....edu> wrote:
>>
>>> On 5/5/2010 8:10 PM, Tony Lindgren wrote:
>>>
>>>> * Brian Swetland <swetland@...gle.com> [100505 16:51]:
>>>>
>>>>> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@...mide.com> wrote:
>>>>>
>>>>>> * Brian Swetland <swetland@...gle.com> [100505 14:34]:
>>>>>>
>>>>>>> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@...land.harvard.edu> wrote:
>>>>>>>
>>> <<-- snip -->>
>>>
>>>>>>>> At no point does the user program have to communicate anything to the
>>>>>>>> modem driver, and at no point does it have to do anything out of the
>>>>>>>> ordinary except to enable and disable a suspend blocker.
>>>>>>>>
>>>>>>> Exactly -- and you can use the same style of overlapping suspend
>>>>>>> blockers with other drivers than input, if the input interface is not
>>>>>>> suitable for the particular interaction.
>>>>>>>
>>>>>> Would the suspend blockers still be needed somewhere in the example
>>>>>> above?
>>>>>>
>>>>> How often would we retry suspending?
>>>>>
>>>> Well based on some timer, the same way the screen blanks? Or five
>>>> seconds of no audio play? So if the suspend fails, then reset whatever
>>>> userspace suspend policy timers.
>>>>
>>>>
>>> Tony,
>>> Wouldn't this be handled by the idle task, or task manager?
>>>
>>> When all tasks are suspended and not doing anything that should be the
>>> first clue that a real suspend cycle could be attempted.
>>>
>>>
>> One if the benefit we get from using suspend is that an unprivileged
>> app that does not have access to suspend blockers cannot prevent
>> suspend. You lose this advantage if you trigger suspend only from the
>> idle task.
>>
>>
> If the process (privileged or unprivileged) doesn't want to suspend, why
> not just provide an interface to allow suspend to be turned off at the
> user level.  This could block the suspend cycle in itself, and you
> shouldn't need fine grained off/on cycles.  If an application really
> needs the system not to suspend then they (the user) should know the
> consequences and power requirements for such a task.
>
> I didn't say it had to be only from the idle task; but, that is the most
> logical place.  If the other threads are not idle then they really
> require work and will most likely already have a bock on the suspend anyway.
>

I think you missed my point. Unprivileged processes should not be
allowed to prevent suspend.

-- 
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/