lkml.org 
[lkml]   [2000]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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