[lkml]   [2000]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] preemptive kernel, preemptive-2.3.52-A7

On Tue, 14 Mar 2000, Linus Torvalds wrote:

> It's trivial to force it to be runnable at pre-emption time instead.
> Simple rule: whenever the process gets scheduled for any reason except
> an explicit call to schedule(), it must obviously have been RUNNING.
> Problem solved.

i actually had this in one version - removed it because i considered it to
be 'hiding' potential bugs.

but these are actually two orthogonal issues here: 1) current->state at
preemption time, and 2) current->state when a copy_*user() function is
called. If 2) is not TASK_RUNNING that i believe is clearly a bug.

in case 1) the process can obviously be non-TASK_RUNNING so the preemption
code should set TASK_RUNNING unconditionally. Simple.

in case 2) the n_tty.c and random.c fixes i posted were fixing real bugs i
believe (they might not be the correct fix though). Eg. one buggy code
path which leads to a stuck process in n_tty.c:

current->state = TASK_INTERRUPTIBLE;
copy_from_user(); <=--- causes page fault on user-space page

- MM calls into readpage() to fill in the page

- readpage tries to get the block index

- lowlevel FS code does a getblk()

- getblk() does a refill_freelist()

- refill_freelist() marks us |= SCHED_YIELD and calls

potentially causing the process to get 'stuck'. Nothing ever wakes the
process up if the copy_from_user happens prior tty space going below
minimum_to_wake. _typically_ there might be some event waking up that
waitqueue, but i believe it's a volatile concept to call any potentially
rescheduling function with no TASK_RUNNING.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.115 / U:3.888 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site