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/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:11 EST