On Sun, 30 Jul 2000, Mike Galbraith wrote:
>
> I keep running into a deadlock with it looping forever trying to
> free memory, triggered by blocking in getblk->refill_freelist->..
> try_to_free_buffers->sync_page_buffers->zzzzz (kflushd runs forever).
Hmm.. I just noticed something. The above really shouldn't happen in the
first place.
The "refill_freelist()" function allocates memory with GFP_BUFFER, which
should not allow the above kind of "try_to_free_buffers()" behavior.
As far as I can tell, we should really honour the fact that GFP_IO isn't
set, and we mustn't do any IO.
So maybe the loopback device problem is actually due to a real bug
independent of the loopback device.
Mike, would you mind checking something where mm/filemap.c does _not_ do
the "try_to_free_buffers()" when GFP_IO isn't set? Instead of
int wait = ((gfp_mask & __GFP_IO) && (nr_dirty-- < 0));
do something like
int wait;
if (!(gfp_mask & __GFP_IO))
goto unlock_continue;
wait = nr_dirty-- < 0;
or similar. Does that make loopback happier?
Linus
-
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 Jul 31 2000 - 21:00:35 EST