linux-kernel - Re: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers

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, 06 Jan 2011 18:30:20 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Arve Hjønnevåg <arve@...roid.com>
Cc:	linux-kernel@...r.kernel.org, Brian Swetland <swetland@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alessandro Zummo <a.zummo@...ertech.it>, rjw@...k.pl
Subject: Re: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers

On Thu, 2011-01-06 at 16:58 -0800, Arve Hjønnevåg wrote:
> 2011/1/6 John Stultz <john.stultz@...aro.org>:
> > So otherwise, do you see any reason why android might not be able to
> > adapt this code to replace the android alarm timers?
> >
> 
> The user-space interface does not look appealing, but I don't see any
> reason why the in-kernel interface(s) cannot be shared. Our user-space
> code has a single thread that waits for alarms to trigger, while the
> alarms can be modified from any thread.

So its something like nanosleep(), only other threads can extend or
shorten the sleep time?

Could you explain some of the rational for such an interface, so I can
better understand the need?

>  As far as I can tell, using
> the posix interface would either require a thread per alarm (up to 5)
> or using signals. Both make the user-space code more complicated, and

Yea, it probably would need signals, but I'd have to grok the use case a
little better. And its possible it would complicate the user-space code
some, but on the other hand, it would be using a more standard kernel
interface. The other option is extending the posix interface to try to
better match the need.

> it is not clear if either of them provide a clear hand-off between
> where the kernel needs to block suspend because the alarm has not been
> delivered to user-space and where user-space needs to block suspend
> because it is handling the alarm.

Indeed. I'm still looking into the pm_wake details to see the
limitations there. Some method of inheriting a stay_awake seems to be
needed, but sounds pretty ugly. Alternatively we may need some method or
callback to the kernel to detect that a signal has been handled by
userland (allowing the pm_relax to occur).

Rafael: Any thoughts here?

thanks
-john

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