Messages in this thread | | | Date | Fri, 04 Feb 2000 13:31:57 +0100 | From | Manfred Spraul <> | Subject | Re: 2.2.15pre5: still very unstable |
| |
Rik van Riel wrote: > > On Fri, 4 Feb 2000, Andrea Arcangeli wrote: > > > (BTW, the trap code is obviously wrong since it should simply make the > > state a not clobbered information instead of running GFP in atomic mode > > I have thought about this and we cannot do that. >
There are 2 different problems:
* callers of gfp()/kmalloc()/get_user() that call these functions with !TASK_RUNNING, but which will set the state to TASK_RUNNING _without_ calling schedule() inbetween. For them, it doesn't really matter, we don't need to change them.
E.g. sys_wait4(): it calls put_user(), then set_current_state(TASK_RUNNING), then it returns without calling schedule().
* callers that assume that TASK_{,UN}INTERRUPTIBLE remains effective across these calls. We must fix them, and as far as I understood Andrea's post, he agrees:
Andrea wrote: > Using GFP in the wrong way instead would mean to call GFP with __GFP_WAIT > set and assuming that the state of the task can't be clobbered after GFP > returned. But none of the case trapped by 2.2.15pre are been found by me > to be wrong and so none bug is been found by the trap code in GFP so far. >
I found 2 places:
* __pollwait(). IMHO a real bug. * write_chan() in drivers/char/n_tty.c. I'm not sure if this one is critical.
-- Manfred
- 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/
| |