linux-kernel - Re: [PATCH] mm: fix direct reclaim writeback regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 26 Jul 2014 16:15:25 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Vlastimil Babka <vbabka@...e.cz>
cc:	Hugh Dickins <hughd@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Rientjes <rientjes@...gle.com>,
	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Dave Jones <davej@...hat.com>,
	Dave Chinner <david@...morbit.com>, xfs@....sgi.com,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm: fix direct reclaim writeback regression

On Sun, 27 Jul 2014, Vlastimil Babka wrote:
> On 07/26/2014 09:58 PM, Hugh Dickins wrote:
> > Yes, 3.16-rc1's 68711a746345 ("mm, migration: add destination page
> > freeing callback") has provided such a way to compaction: if migrating
> > a SwapBacked page fails, its newpage may be put back on the list for
> > later use with PageSwapBacked still set, and nothing will clear it.
> 
> Ugh good catch. So is this the only flag that can become "stray" like
> this? It seems so from quick check...

Yes, it seemed so to me too; but I would prefer a regime in which
we only mess with newpage once it's sure to be successful.

> > --- 3.16-rc6/mm/migrate.c	2014-06-29 15:22:10.584003935 -0700
> > +++ linux/mm/migrate.c	2014-07-26 11:28:34.488126591 -0700
> > @@ -988,9 +988,10 @@ out:
> >  	 * it.  Otherwise, putback_lru_page() will drop the reference grabbed
> >  	 * during isolation.
> >  	 */
> > -	if (rc != MIGRATEPAGE_SUCCESS && put_new_page)
> > +	if (rc != MIGRATEPAGE_SUCCESS && put_new_page) {
> > +		ClearPageSwapBacked(newpage);
> >  		put_new_page(newpage, private);
> > -	else
> > +	} else
> >  		putback_lru_page(newpage);
> >  
> >  	if (result) {
> 
> What about unmap_and_move_huge_page()? Seems to me it can also get the
> same stray flag. Although compaction, who is the only user so far of
> custom put_new_page, wouldn't of course migrate huge pages. But might
> bite us in the future, if a new user appears before a cleanup...

I think you're right, thanks for pointing it out.  We don't have an
actual bug there at present, so no need to rush back and fix up the
patch now in Linus's tree; but unmap_and_move_huge_page() gives
another reason why my choice was "probably the worst place to fix it".

More reason for a cleanup, but not while the memcg interface is in flux.
In mmotm I'm a little anxious about the PageAnon case when newpage's
mapping is left set, I wonder if that might also be problematic: I
mailed Hannes privately to think about that - perhaps that will give
more impulse for a cleanup, though I've not noticed any bug from it.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/