Messages in this thread | | | Date | Fri, 4 Feb 2000 18:33:41 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: 2.2.15pre5: still very unstable |
| |
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/
| |