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]

Message-Id: <201101081136.06682.rjw@sisk.pl>
Date:	Sat, 8 Jan 2011 11:36:06 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	linux-kernel@...r.kernel.org, Brian Swetland <swetland@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	"Linux-pm mailing list" <linux-pm@...ts.linux-foundation.org>
Subject: Re: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers

On Friday, January 07, 2011, John Stultz wrote:
> 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?

I think this problem is specific to Android where suspend is started
automatically from kernel space, so user space needs an interface to actively
prevent the kernel from starting suspend.

The mainline model is that suspend will always be started from user space,
so instead of telling the kernel not to suspend user space needs to avoid
starting suspend in the first place.  In this model the kernel code can simply
call pm_relax() as soon as _it_ doesn't need to prevent the system from
suspending any more (eg. it knows that user space has learnt of the alarm) and
it need not worry about the user space part (eg. whether or not user space
is still handling the alarm). 

Thanks,
Rafael
--
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/