remap_pfn_range: store vm_pgoff for all linear_over_vma_region mappings
Subsystems (2)
RFC 1/1 remap_pfn_range: store vm_pgoff for all linear_over_vma_region mappings
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.
Quoted 1 line
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.
--- mm/memory.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
mm/memory.c +3 -4
@@ -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 ;
[Sorry for the duplicate. Correctly sending to Andrew this time.]
Quoted 42 lines · Venki Pallipadi
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_pgoffas an indicator for linear mapping over the vma region. Currently,remap_pfn_rangeonly setsvm_pgoffonly for COW mappings. Below patch changes the logic and sets thevm_pgoffirrespective 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 <[email protected]>Signed-off-by Suresh Siddha <[email protected]>--- mm/memory.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)Index:
linux-2.6/mm/memory.c
===================================================================mm/memory.c +3
-4@@ -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 ;
Quoted 11 lines · Venki Pallipadi
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_pgoffas an indicator for linear mapping over the vma region. Currently,remap_pfn_rangeonly setsvm_pgoffonly for COW mappings. Below patch changes the logic and sets thevm_pgoffirrespective of COW.
Quoted 7 lines
Quoted 1 line
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 <[email protected]>Signed-off-by Suresh Siddha <[email protected]>
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
Quoted 23 lines
--- mm/memory.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)Index:
linux-2.6/mm/memory.c
===================================================================mm/memory.c +3
-4@@ -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 ;
Quoted 29 lines
-----Original Message-----
From: Nick Piggin [mailto:[email protected]]
Sent: Thursday, October 23, 2008 6:08 PM
To: Pallipadi, Venkatesh
Cc: [email protected]; [email protected]; Ingo Molnar; linux-kernel
Subject: Re: [RFC]remap_pfn_range: storevm_pgofffor alllinear_over_vma_regionmappingsQuoted 3 lines · Venki Pallipadi
While working on x86 PAT, we are having some hurdles with tracking
remap_pfn_range()regions, as later we do not have anyinformation to say
Quoted 13 lines
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_pgoffas an indicator for linear mapping over the vma region. Currently,remap_pfn_rangeonly setsvm_pgoffonly for COW mappings. Below patch changes the logic and sets thevm_pgoffirrespective of COW.Quoted 1 line
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.
Quoted 7 lines
Quoted 2 lines
Signed-off-by Venkatesh Pallipadi <[email protected]>Signed-off-by Suresh Siddha <[email protected]>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... ?
Yes. We are thinking of it as a call similar to is_cow_mapping(). May be is_linear_vma_mapping() or something like that. We should have the rest of the patches by next week.
Thanks,
Venki