linux-kernel - Re: [PATCH 2/7] KAMEZAWA Hiroyuki

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: <Pine.LNX.4.64.0705301304200.2671@schroedinger.engr.sgi.com>
Date:	Wed, 30 May 2007 13:07:33 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Hugh Dickins <hugh@...itas.com>
cc:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Mel Gorman <mel@....ul.ie>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/7] KAMEZAWA Hiroyuki - migration by kernel

On Wed, 30 May 2007, Hugh Dickins wrote:

> I've taken a look at last.  It looks like a good fix to a real problem,
> but may I suggest a simpler version?  The anon_vma isn't usually held
> by a refcount, but by having a vma on its linked list: why not just
> put a dummy vma into that linked list?  No need to add a refcount.
> 
> The NUMA shmem_alloc_page already uses a dummy vma on its stack,
> so you can reasonably declare a vm_area_struct on unmap_and_move's
> stack.  No need for a special anon_vma_release, anon_vma_unlink
> should do fine.  I've not reworked your whole patch, but show
> what I think the mm/rmap.c part would be at the bottom.

Hummm.. shmem_alloc_pages version only uses the vma as a placeholder 
for memory policies. So we would put the page on a vma that is on the 
stack? That would mean changing the mapping of the page? Is that safe?

And then later we would be changing the mapping back to the old vma?
What guarantees that the old vma is not gone by then?
-
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/