linux-kernel - Re: [PATCH 76/94] mm/khugepaged: Use maple tree iterators instead of vma

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>] [day] [month] [year] [list]

Message-ID: <20210504140454.22isjwj66vydyzmy@revolver>
Date:   Tue, 4 May 2021 14:05:26 +0000
From:   Liam Howlett <liam.howlett@...cle.com>
To:     Hillf Danton <hdanton@...a.com>
CC:     MAPLE <maple-tree@...ts.infradead.org>, MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>,
        Michel Lespinasse <walken.cr@...il.com>
Subject: Re: [PATCH 76/94] mm/khugepaged: Use maple tree iterators instead of
 vma

* Hillf Danton <hdanton@...a.com> [210504 00:29]:
> On Wed, 28 Apr 2021 15:36:24  Liam R. Howlett wrote:
> > ---
> >  mm/khugepaged.c | 11 +++++++++--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> Good work. And a nit below.
> > 
> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > index 33cf91529f0b..4983a25c5a90 100644
> > --- a/mm/khugepaged.c
> > +++ b/mm/khugepaged.c
> > @@ -2063,6 +2063,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned =
> > int pages,
> >  	struct mm_struct *mm;
> >  	struct vm_area_struct *vma;
> >  	int progress = 0;
> > +	MA_STATE(mas, NULL, 0, 0);
> > 
> >  	VM_BUG_ON(!pages);
> >  	lockdep_assert_held(&khugepaged_mm_lock);
> > @@ -2079,18 +2080,22 @@ static unsigned int khugepaged_scan_mm_slot(unsigne=
> > d int pages,
> >  	khugepaged_collapse_pte_mapped_thps(mm_slot);
> > 
> >  	mm = mm_slot->mm;
> > +	mas.tree = &mm->mm_mt;
> >  	/*
> >  	 * Don't wait for semaphore (to avoid long wait times).  Just move to
> >  	 * the next mm on the list.
> >  	 */
> >  	vma = NULL;
> > +	mas_set(&mas, khugepaged_scan.address);
> >  	if (unlikely(!mmap_read_trylock(mm)))
> >  		goto breakouterloop_mmap_lock;
> > +
> > +	rcu_read_lock();
> >  	if (likely(!khugepaged_test_exit(mm)))
> > -		vma = find_vma(mm, khugepaged_scan.address);
> > +		vma = mas_find(&mas, ULONG_MAX);
> > 
> >  	progress++;
> > -	for (; vma; vma = vma->vm_next) {
> > +	mas_for_each(&mas, vma, ULONG_MAX) {
> >  		unsigned long hstart, hend;
> > 
> >  		cond_resched();
> 
> Given the added rcu_read_lock(), take another look at this scheduling
> entry?
> 

Yes, thank you for pointing this out.  It is certainly an issue.

> > @@ -2129,6 +2134,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned =
> > int pages,
> >  				pgoff_t pgoff = linear_page_index(vma,
> >  						khugepaged_scan.address);
> > 
> > +				rcu_read_unlock();
> >  				mmap_read_unlock(mm);
> >  				ret = 1;
> >  				khugepaged_scan_file(mm, file, pgoff, hpage);
> > @@ -2149,6 +2155,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned =
> > int pages,
> >  		}
> >  	}
> >  breakouterloop:
> > +	rcu_read_unlock();
> >  	mmap_read_unlock(mm); /* exit_mmap will destroy ptes after this */
> >  breakouterloop_mmap_lock:
> > 
> > --
> > 2.30.2