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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
