[lkml]   [2010]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote:

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

Ok. So we stick the untrusted bits of userspace on the critical timer
list. Now we get a network packet that generates a wakeup event and gets
read by an application. What happens if that application can't fully
process the packet in a single timeslice?

Matthew Garrett |

 \ /
  Last update: 2010-05-13 21:57    [W:0.224 / U:8.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site