linux-kernel - Re: [PATCH] rtc: add in ability to push out an existing wakealarm using sysfs

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:	Wed, 22 May 2013 15:05:44 -0700
From:	Bernie Thompson <bhthompson@...omium.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	rtc-linux@...glegroups.com,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Rob Landley <rob@...dley.net>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, Doug Anderson <dianders@...omium.org>
Subject: Re: [PATCH] rtc: add in ability to push out an existing wakealarm
 using sysfs

On Wed, May 22, 2013 at 2:55 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
>
> On Fri, 10 May 2013 17:53:31 -0700 Bernie Thompson <bhthompson@...omium.org> wrote:
>
> > This adds in the ability for the rtc sysfs code to handle += characters
> > at the beginning of a wakealarm setting string. This will allow the user to
> > attempt to push out an existing wakealarm by a provided amount.
> >
> > In the case that the += characters are provided but the alarm is not active
> > -EVINVAL is returned.
> >
>
> Well that sounds useful, but I'm not personally in a position to
> confidently judge whether it's useful enough to merge the patch.  The
> changelog doesn't make a compelling case and everybody else has chosen
> to sit on their hands.
>
> So I really don't know what to do with this patch.
>

Thank you for looking at this, I was just talking with Doug on CC this
morning about
explaining why this is useful, at least for my purposes in
suspend/resume testing.
The basic test goes something like:

1. Set a wake alarm from userspace 5 seconds in the future

2. Start the suspend process (echo mem > /sys/power/state)

3. After ~2.5 seconds if userspace is still running (using another
thread to check
this), move the wake alarm 5 more seconds

If the "move" involves an unset of the wakealarm then there's a
period of time where the system is midway through suspending but has
no wake alarm. It will get stuck.

We'd rather not remove the "move" since the idea is to avoid a
cancelled suspend when the alarm fires _during_ suspend.  It is
difficult for the test to tell the difference between a suspend that
was cancelled because the alarm fired too early and a suspend that was
cancelled/failed for some other reason.
--
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/