linux-kernel - Re: [PATCH 3/3] mm,migration: Remove straggling migration PTEs when page tables are being moved after the VMA has already moved

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: <20100428111248.2797801c.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Wed, 28 Apr 2010 11:12:48 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	Mel Gorman <mel@....ul.ie>, Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Minchan Kim <minchan.kim@...il.com>,
	Christoph Lameter <cl@...ux.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 3/3] mm,migration: Remove straggling migration PTEs when
 page tables are being moved after the VMA has already moved

On Wed, 28 Apr 2010 03:44:34 +0200
Andrea Arcangeli <aarcange@...hat.com> wrote:

> On Wed, Apr 28, 2010 at 10:29:28AM +0900, KAMEZAWA Hiroyuki wrote:
> > Hmm..Mel's patch 2/3 takes vma->anon_vma->lock in vma_adjust(),
> > so this patch clears vma->anon_vma...
> 
> yep, it should be safe with patch 2 applied too. And I'm unsure why Mel's
> patch locks the anon_vma also when vm_start != start. See the other
> email I sent about patch 2.
> 
> > I think we can unlock this just after move_page_tables().
> 
> Checking this, I can't see where exactly is vma->vm_pgoff adjusted
> during the atomic section I protected with the anon_vma->lock?
> For a moment it looks like these pages become unmovable.
> 
The page can be replaced with migration_pte before the 1st vma_adjust.

The key is 
	(vma, page) <-> address <-> pte <-> page
relationship.

	vma_adjust() 
	(*)
	move_pagetables();
	(**)
	vma_adjust();

At (*), vma_address(vma, page) retruns a _new_ address. But pte is not
updated. This is ciritcal for rmap_walk. We're safe at (**).


> I guess this is why I thought initially that it was move_page_tables
> to adjust the page->index. If it doesn't then the vma->vm_pgoff has to
> be moved down of shift >>PAGE_SHIFT and it doesn't seem to be
> happening which is an unrelated bug.
> 

Anyway, I have no strong opinion about the placement of unlock(anon_vma->lock).

I wonder why we don't see this at testing memory-hotplug is because memory-hotplug
disables a new page allocation in the migration range. So, this exec() is hard to get
a page which can be migration target.

Thanks,
-Kame

--
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/