linux-kernel - Re: [PATCH 0/8] Suspend block api (version 7)

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: <AANLkTikm69OKbRUvqiqGh4KRMn7u166tyt4kx0-bjR3Z@mail.gmail.com>
Date:	Tue, 18 May 2010 15:21:09 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Brian Swetland <swetland@...gle.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/8] Suspend block api (version 7)

2010/5/18 Rafael J. Wysocki <rjw@...k.pl>:
> On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> 2010/5/18 Rafael J. Wysocki <rjw@...k.pl>:
>> > On Tuesday 18 May 2010, Arve Hjønnevåg wrote:
>> >> On Mon, May 17, 2010 at 2:44 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
>> >> > On Monday 17 May 2010, Brian Swetland wrote:
>> >> >> On Mon, May 17, 2010 at 1:40 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
>> >> >> > On Monday 17 May 2010, Arve Hjønnevåg wrote:
>> >> >> >>
> ...
>>
>> > Now, to make it more "user-friendly", we can simply use
>> > queue_delayed_work() with a reasonable delay instead of queue_work() to queue
>> > the suspend work (the delay may be configurable via sysfs).
>> >
>>
>> I can add a delay (and the timeout support code does add a delay as an
>> optimization) to the unknown wakeup case, but this does not fix the
>> problem of a user turning on opportunistic suspend with a user space
>> framework that does not use suspend blockers. If the kernel uses
>> suspend blockers to make sure the wakeup event makes it to user space,
>> but user space does not block suspend, then the system will suspend
>> before the event is processed.
>
> But the user can still manually write to /sys/power/state. :-)
>

Does adding or removing a delay change this? It seems in only changes
how quickly the user can finish that write.

I'm not convinced adding a configurable delay here is necessary. Once
the driver that enabled the wakeup event has been updated to block
suspend until this event gets to user space, then this delay will
never be triggered. The kernel cannot tell the difference between a
user enabling opportunistic suspend but not wanting it and
opportunistic suspend aware user space code deciding that this wakeup
event should be ignored.

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