On Wed, 11 Jul 2012, Andrew Morton wrote:
> On Wed, 11 Jul 2012 18:57:43 -0700 (PDT) Hugh Dickins <hu...@google.com>
> wrote:
>
> > --- 3.5-rc6-mm1/mm/vmscan.c 2012-07-11 14:42:13.668335884 -0700
> > +++ linux/mm/vmscan.c 2012-07-11 16:01:20.712814127 -0700
> > @@ -726,7 +726,8 @@ static unsigned long shrink_page_list(st
> > * writeback from reclaim and there is nothing else to
> > * reclaim.
> > */
> > - if (!global_reclaim(sc) && PageReclaim(page))
> > + if (!global_reclaim(sc) && PageReclaim(page) &&
> > + may_enter_fs)
> > wait_on_page_writeback(page);
> > else {
> > nr_writeback++;
>
> um, that may_enter_fs test got removed because nobody knew why it was
> there. Nobody knew why it was there because it was undocumented. Do
> you see where I'm going with this?
I was hoping you might do that bit ;) Here's my display of ignorance:
--- 3.5-rc6-mm1/mm/vmscan.c 2012-07-11 14:42:13.668335884 -0700
+++ linux/mm/vmscan.c 2012-07-11 20:09:33.182829986 -0700
@@ -725,8 +725,15 @@ static unsigned long shrink_page_list(st
* could easily OOM just because too many pages are in
* writeback from reclaim and there is nothing else to
* reclaim.
+ *
+ * Check may_enter_fs, certainly because a loop driver
+ * thread might enter reclaim, and deadlock if it waits
+ * on a page for which it is needed to do the write
+ * (loop masks off __GFP_IO|__GFP_FS for this reason);
+ * but more thought would probably show more reasons.
*/
- if (!global_reclaim(sc) && PageReclaim(page))
+ if (!global_reclaim(sc) && PageReclaim(page) &&
+ may_enter_fs)
wait_on_page_writeback(page);
else {
nr_writeback++;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
