[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081024010803.GB5004@wotan.suse.de>
Date: Fri, 24 Oct 2008 03:08:03 +0200
From: Nick Piggin <npiggin@...e.de>
To: Venki Pallipadi <venkatesh.pallipadi@...el.com>
Cc: hugh@...itas.com, apkm@...ux-os.sc.intel.com,
Ingo Molnar <mingo@...e.hu>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] remap_pfn_range: store vm_pgoff for all linear_over_vma_region mappings
On Thu, Oct 23, 2008 at 03:09:14PM -0700, Venki Pallipadi wrote:
>
> While working on x86 PAT, we are having some hurdles with tracking
> remap_pfn_range() regions, as later we do not have any information to say
> whether that PFNMAP mapping is linear for the entire vma range or
> it is smaller granularity regions within the vma.
>
> A simple solution to this is to use vm_pgoff as an indicator for
> linear mapping over the vma region. Currently, remap_pfn_range
> only sets vm_pgoff only for COW mappings. Below patch changes the
> logic and sets the vm_pgoff irrespective of COW.
>
> >From our understanding of the code, this should not break anyone.
> Just sending it as an RFC to get feedback on whether it is OK to do
> something like this or are there any corner cases that we may
> break or watch out for.
>
> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@...el.com>
Hmm, I can'tthink of why it would break, but I would like to see an
entire patch. Obviously you won't try to decode this vma stuff
directly from the PAT code, but just call mm helpers... ?
Thanks,
Nick
> ---
> mm/memory.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> Index: linux-2.6/mm/memory.c
> ===================================================================
> --- linux-2.6.orig/mm/memory.c 2008-10-21 09:58:47.000000000 -0700
> +++ linux-2.6/mm/memory.c 2008-10-23 13:38:26.000000000 -0700
> @@ -1575,11 +1575,10 @@ int remap_pfn_range(struct vm_area_struc
> * behaviour that some programs depend on. We mark the "original"
> * un-COW'ed pages by matching them up with "vma->vm_pgoff".
> */
> - if (is_cow_mapping(vma->vm_flags)) {
> - if (addr != vma->vm_start || end != vma->vm_end)
> - return -EINVAL;
> + if (addr == vma->vm_start && end == vma->vm_end)
> vma->vm_pgoff = pfn;
> - }
> + else if (is_cow_mapping(vma->vm_flags))
> + return -EINVAL;
>
> vma->vm_flags |= VM_IO | VM_RESERVED | VM_PFNMAP;
>
--
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/
Powered by blists - more mailing lists