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

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: <20100513194205.GC3428@atomide.com>
Date:	Thu, 13 May 2010 12:42:05 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Paul Walmsley <paul@...an.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	magnus.damm@...il.com, Theodore Ts'o <tytso@....edu>,
	mark gross <mgross@...ux.intel.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Geoff Smith <geoffx.smith@...el.com>,
	Brian Swetland <swetland@...gle.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Benoît Cousson <b-cousson@...com>,
	linux-omap@...r.kernel.org, Vitaly Wool <vitalywool@...il.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

* Matthew Garrett <mjg@...hat.com> [100513 12:20]:
> On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote:
> > The suspend blocks seems like a hack to spam filter good and bad
> > apps from timer usage point of view. Applications are categorized
> > as good or bad depending if they grab a susped blocker or not.
> > 
> > I believe categorizing the apps should be instead done with some
> > timer flags or cgroups instead.
> 
> I agree, but we have no mechanism for implementing that in a race-free 
> way. We don't even have a realistical proposal for what that mechanism 
> would look like. Should we refuse bread today for the promise of cake 
> tomorrow?

Well this is an interesting problem, and once solved will be handy
for all kind of things. My worry is that if it's integrated in it's
current form it will be totally out of control all over the place :(

Still hoping we can come up with some clean way that avoid the patching
all over the place part.. How about the following, can you please check
if it would help with your example of guaranteed handling of event:

1. In the kernel, we add one more timer queue for critical timers.
   The current timer queue(s) stay as it is.

2. We allow selecting the timer based on some flag, the default
   behaviour being the current default timer queue.

3. Then we add next_timer_interupt_critical() to only query the
   critical timers along the lines of the current next_timer_interrupt().

4. We implement a custom pm_idle that suspends the system based on
   some logic and checking if next_timer_interrupt_critical() is
   empty. If the next_timer_interrupt_critical() does not return
   anything, we assume it's OK to suspend the system.

Now to me it sounds if your the input layer and userspace handle
both grab the timers with the critical flags, it should be guaranteed
that the events get handled before the system is suspended.

Regards,

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