That's the same here, when I implemented my version
of the patch. But apperantly there are some places
in the kernel which could lock when there are no
buffers (Linus?). At least, that's the answer I got
when Linus rejected my patch.
And since I've got a feeling that he might be right,
it would be best to just allocate one page at a time,
wake up kflushd and schedule when we hit this situation.
> I'm not sure, why this patch can cause a deadlock, because a "return 0;"
> is the "normal" case, if "__get_free_page" in "grow_buffers()" fails.
It could cause a deadlock when we need a buffer in order
to do something semi-critical inside of the kernel. At
least, according to Linus. Maybe Stephen Tweedie has more
info, or knows something to disprove Linus' point of view.
It would be nice if we could be sure that your code worked
correctly...
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu