2.2.1{3,4,5pre*} VM bug found

2.2.1{3,4,5pre*} VM bug found

[Rik van Riel]

Hi Alan,

I've found the bug that makes the VM subsystem in the
latest 2.2 kernels go belly-up (or mess up processes).

Sometimes a process with tsk->state != TASK_RUNNABLE
calls __get_free_pages(). When we're (almost) out of
memory, the process will wake up kswapd and try to
free some memory itself.

In 2.2.15pre4 or when the call to try_to_free_pages()
generates disk I/O, the task will call schedule().
Since the task state != TASK_RUNNABLE, schedule() will
immedately remove it from the run queue ...

The task itself will still be somewhere `in the middle
of' __get_free_pages() and has no chance of ever
returning to whatever it was doing. Of course it still
reacts on signals, so you can easily kill it (unless
it happens to be your X server).

I will prepare a fix for this after I've had some
sleep ... you'll hear back from me tomorrow.

regards,

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 2.2.1{3,4,5pre*} VM bug found

[Andrea Arcangeli]

On Tue, 25 Jan 2000, Rik van Riel wrote:

>calls __get_free_pages(). When we're (almost) out of
>memory, the process will wake up kswapd and try to

You'll block also before to go out of memory if the allocation rate is
high enough.

>In 2.2.15pre4 or when the call to try_to_free_pages()
>generates disk I/O, the task will call schedule().
>Since the task state != TASK_RUNNABLE, schedule() will
>immedately remove it from the run queue ...

Before calling schedule() you always gets registered in a waitqueue so
you can't deadlock or wait too much.

If something there is the opposite problem. If you do:

	__set_current_state(TASK_UNINTERRUPTIBLE);
	get_page(GFP_KERNEL);
	XXXXXXXXXXXXXXXXXXXX
	schedule();

then at point XXXXXXX you may become a task running and you don't block
anymore.

Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 2.2.1{3,4,5pre*} VM bug found

[Rik van Riel]

On Tue, 25 Jan 2000, Andrea Arcangeli wrote:

> Before calling schedule() you always gets registered in a
> waitqueue so you can't deadlock or wait too much.
> 
> If something there is the opposite problem. If you do:
> 
> 	__set_current_state(TASK_UNINTERRUPTIBLE);
> 	get_page(GFP_KERNEL);
> 	XXXXXXXXXXXXXXXXXXXX
> 	schedule();
> 
> then at point XXXXXXX you may become a task running and you don't
> block anymore.

The problem in this case is that schedule() may be called
from within get_page(GFP_KERNEL). This already was possible
in 2.2.14 and before (if the task had to wait for I/O on
try_to_free_pages()), but the explicit schedule() in my
stuff in 2.2.15pre4 amplified the problem and made it
visible.

A fix for this problem is in one of my other emails and
at my web page:  http://www.surriel.com/patches/

regards,

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 2.2.1{3,4,5pre*} VM bug found

[Stephen C. Tweedie]

Hi,

On Tue, 25 Jan 2000 04:27:43 +0100 (CET), Rik van Riel
<riel@nl.linux.org> said:

> Sometimes a process with tsk->state != TASK_RUNNABLE
> calls __get_free_pages(). When we're (almost) out of
> memory, the process will wake up kswapd and try to
> free some memory itself.

> In 2.2.15pre4 or when the call to try_to_free_pages()
> generates disk I/O, the task will call schedule().
> Since the task state != TASK_RUNNABLE, schedule() will
> immedately remove it from the run queue ...

Shouldn't be a problem.  Anywhere that we stall in try_to_free_pages()
to wait for disk IO, we obviously have to set task->state to
TASK_UNINTERRUPTIBLE, as we're about to block.  If we do that as a
result of disk IO, then we have necessarily already scheduled a wakeup
event which will set the task state back to runnable.

So, the only risk is that the call to try_to_free_pages() has the
unexpected side effect of setting the task state to TASK_RUNNABLE.  That
isn't a problem: the only effect it will have on the caller is to make a
call schedule() return sooner than expected.  

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 2.2.1{3,4,5pre*} VM bug found

[Stephen C. Tweedie]

Hi,

On Wed, 26 Jan 2000 01:48:43 +0100 (CET), Rik van Riel
<riel@nl.linux.org> said:

> The problem in this case is that schedule() may be called
> from within get_page(GFP_KERNEL). This already was possible
> in 2.2.14 and before (if the task had to wait for I/O on
> try_to_free_pages()), but the explicit schedule() in my
> stuff in 2.2.15pre4 amplified the problem and made it
> visible.

It's not only possible, it is explicitly legal.  It always has been.
You _must_ call it with GFP_ATOMIC if you can't afford to block (or,
alternatively, call it without __GFP_IO, or with the PF_MEMALLOC flag).

> A fix for this problem is in one of my other emails 

It's not a problem.  If callers are expecting GFP_KERNEL to be atomic,
then _that_ is a problem, but it is perfectly all right for GFP_KERNEL
allocations to block.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/