Messages in this thread | | | Date | Tue, 14 Mar 2000 22:11:51 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: [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 schedule()
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.
Ingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |