Re: 2.2.15pre5: still very unstable

From: Andrea Arcangeli (andrea@suse.de)
Date: Fri Feb 04 2000 - 12:33:41 EST


On Fri, 4 Feb 2000, Ingo Molnar wrote:

>i believe it's a bug to set the task state and not call schedule
>atomically within a short timeframe. (tty.c is such a case) So i think

It doesn't look a bug to me. The interface is like this and looks nice to
me:

        add_wait_queue();
        for (;;) {
                set_current_state(TASK_INTERRUPTIBLE);
                if (!(nr -= read_data(nr)))
                        break;
                schedule();
        }
        remove_wait_queue();
        __set_current_state(TASK_RUNNING);

The above construct allow read_data to just lazily try to read something
and then return what he found without care about races. It's also an
obviously right construct and it relaxes very much the event handling
locking. The common case won't loop if not necessary and so it provides an
high performance lockless(except for the waitqueue that would be
there anyway unless you want to poll :)/cliless fast path.

>those places which have this behavior should be fixed - and not the
>functions which are called and might block should be hacked to set the
>task state. I just chose the quick solution.

If we want to change the copy_user/GFP interface to enforce the caller to
be in TASK_RUNNING state to avoid having to set the task-running by hand
in the need_reshed _slow_ path for the lowlatency stuff ok, but that
changes doesn't seems related to declaring the above construct as buggy.

Also I would very much prefer to do such changes only in 2.3.x since in
2.2.x there's nothing wrong in calling copy_user or GFP with task not in
running state (with my three patches applyed of course ;). An your
lowlatency is just 100% correct in 2.2.x thus there's nothing of left
unfixed for 2.2.x.

Other things like wait_on_buffer/page() and other blocking things
obviously doesn't (and will never) care about the TASK_RUNNING thing
(just like GFP and copy_user in 2.2.x).

Andrea

-
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