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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1294337041.4518.87.camel@work-vm>
Date:	Thu, 06 Jan 2011 10:04:01 -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>
Subject: Re: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers

On Wed, 2011-01-05 at 20:07 -0800, Arve Hjønnevåg wrote:
> On Wed, Jan 5, 2011 at 6:15 PM, John Stultz <john.stultz@...aro.org> wrote:
> > Its possible that I've missed some subtleties of the Android
> > alarm driver interface, and that some of the interface decisions
> > I've made may not allow Android to use this interface directly,
> > I'd be very interested if those details could be pointed out,
> > and hopefully we can find a good solution to get this useful
> > functionality upstream.
> >
> 
> I don't know how suited the posix interface is for this, but I think
> it is critical to prevent suspend while an alarm is pending. If an
> alarm is important enough to wake the system up from suspend, it is
> probably not safe to suspend right after it triggered. The android
> alarm driver holds a wakelock until user-space calls back in to wait
> for the next alarm, while in-kernel alarms are called from interrupt

Hrm. I was hoping to avoid wakelock discussions for now. What happens if
an app sets a single alarm and then never calls back in? I assume
closing the device drops the wakelock?

> context. The apis provided in include/linux/pm_wakeup.h should provide
> the functionality you need to prevent suspend until the alarms have
> been fully processed, but I have not tried this api yet.

Ok. I'll have to check out the pm_wakeup.h api and see if it can be
used.

> It would also be useful to still allow in-kernel alarms to be
> activated from atomic context (we currently do this in a couple of
> drivers to avoid using a second wakelock).

This is useful. I think I was being overly cautious using a mutex
instead of a spinlock for the base lock since I was worried about
calling into the RTC code which require mutexes, but we only do that at
suspend, so it should be ok to use a spinlock there. I'll revise and add
that in.

So otherwise, do you see any reason why android might not be able to
adapt this code to replace the android alarm timers?

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/