linux-kernel - Re: [PATCH 4/5] mm: fix check_move_unevictable

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]

Message-ID: <alpine.LSU.2.11.2008312040530.1019@eggly.anvils>
Date:   Mon, 31 Aug 2020 20:59:24 -0700 (PDT)
From:   Hugh Dickins <hughd@...gle.com>
To:     Alex Shi <alex.shi@...ux.alibaba.com>
cc:     Hugh Dickins <hughd@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...e.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        Matthew Wilcox <willy@...radead.org>, Qian Cai <cai@....pw>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        Kuo-Hsin Yang <vovoy@...omium.org>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 4/5] mm: fix check_move_unevictable_pages() on THP

On Tue, 1 Sep 2020, Alex Shi wrote:
> 在 2020/8/31 上午5:08, Hugh Dickins 写道:
> > --- 5.9-rc2/mm/vmscan.c	2020-08-16 17:32:50.721507348 -0700
> > +++ linux/mm/vmscan.c	2020-08-28 17:47:10.595580876 -0700
> > @@ -4260,8 +4260,14 @@ void check_move_unevictable_pages(struct
> >  	for (i = 0; i < pvec->nr; i++) {
> >  		struct page *page = pvec->pages[i];
> >  		struct pglist_data *pagepgdat = page_pgdat(page);
> > +		int nr_pages;
> > +
> > +		if (PageTransTail(page))
> > +			continue;
> > +
> > +		nr_pages = thp_nr_pages(page);
> > +		pgscanned += nr_pages;
> >  
> > -		pgscanned++;
> >  		if (pagepgdat != pgdat) {
> >  			if (pgdat)
> >  				spin_unlock_irq(&pgdat->lru_lock);
> > @@ -4280,7 +4286,7 @@ void check_move_unevictable_pages(struct
> >  			ClearPageUnevictable(page);
> >  			del_page_from_lru_list(page, lruvec, LRU_UNEVICTABLE);
> >  			add_page_to_lru_list(page, lruvec, lru);
> 
> So, we might randomly del or add a thp tail page into lru?
> It's interesting to know here. :)

No, it wasn't that interesting, I'd have been more concerned if it was
like that.  Amusing idea though: because the act of adding a thp tail
to lru would clear the very bit that says it's a tail.

		if (!PageLRU(page) || !PageUnevictable(page))
			continue;

Let's see: PageLRU and PageUnevictable are both of the PF_HEAD type,
so permitted on tails, but always redirecting to head: so typically
PageLRU(page) would be true, because head on lru; but PageUnevictable(page)
would be false on tail, because head has already been moved to an evictable
lru by this same function.  So it safely went the "continue" way, but
without incrementing pgrescued.

Hugh

> 
> Thanks
> Alex
> 
> > -			pgrescued++;
> > +			pgrescued += nr_pages;
> >  		}
> >  	}
> >