Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757253Ab2JJV5y (ORCPT ); Wed, 10 Oct 2012 17:57:54 -0400 Received: from mail-ie0-f174.google.com ([209.85.223.174]:56350 "EHLO mail-ie0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755199Ab2JJV5v (ORCPT ); Wed, 10 Oct 2012 17:57:51 -0400 Date: Wed, 10 Oct 2012 14:57:48 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Martin Schwidefsky cc: Jan Kara , linux-mm@kvack.org, LKML , xfs@oss.sgi.com, Mel Gorman , linux-s390@vger.kernel.org Subject: Re: [PATCH] mm: Fix XFS oops due to dirty pages without buffers on s390 In-Reply-To: Message-ID: References: <1349108796-32161-1-git-send-email-jack@suse.cz> <20121009101822.79bdcb65@mschwide> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2524 Lines: 50 On Tue, 9 Oct 2012, Hugh Dickins wrote: > On Tue, 9 Oct 2012, Martin Schwidefsky wrote: > > On Mon, 8 Oct 2012 21:24:40 -0700 (PDT) > > Hugh Dickins wrote: > > > > > A separate worry came to mind as I thought about your patch: where > > > in page migration is s390's dirty storage key migrated from old page > > > to new? And if there is a problem there, that too should be fixed > > > by what I propose in the previous paragraph. > > > > That is covered by the SetPageUptodate() in migrate_page_copy(). > > I don't think so: that makes sure that the newpage is not marked > dirty in storage key just because of the copy_highpage to it; but > I see nothing to mark the newpage dirty in storage key when the > old page was dirty there. I went to prepare a patch to fix this, and ended up finding no such problem to fix - which fits with how no such problem has been reported. Most of it is handled by page migration's unmap_and_move() having to unmap the old page first: so the old page will pass through the final page_remove_rmap(), which will transfer storage key to page_dirty in those cases which it deals with (with the old code, any file or swap page; with the new code, any unaccounted file or swap page, now that we realize the accounted files don't even need this); and page_dirty is already properly migrated to the new page. But that does leave one case behind: an anonymous page not yet in swapcache, migrated via a swap-like migration entry. But this case is not a problem because PageDirty doesn't actually affect anything for an anonymous page not in swapcache. There are various places where we set it, and its life-history is hard to make sense of, but in fact it's meaningless in 2.6, where page reclaim adds anon to swap (and sets PageDirty) whether the page was marked dirty before or not (which makes sense when we use the ZERO_PAGE for anon read faults). 2.4 did behave differently: it was liable to free anon pages not marked dirty, and I think most of our anon SetPageDirtys are just a relic of those days - I do have a patch from 18 months ago to remove them (adding PG_dirty to the flags which should not be set when a page is freed), but there are usually more urgent things to attend to than rebase and retest that. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/