2008-11-12 23:22:38

by Pallipadi, Venkatesh

[permalink] [raw]
Subject: [patch 4/8] x86 PAT: hooks in generic vm code to help archs to track pfnmap regions

Introduce generic hooks in remap_pfn_range and vm_insert_pfn and
corresponding copy and free routines with reserve and free tracking.

Signed-off-by: Venkatesh Pallipadi <[email protected]>
Signed-off-by: Suresh Siddha <[email protected]>

---
include/linux/mm.h | 6 +++++
mm/memory.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 59 insertions(+), 1 deletion(-)

Index: tip/mm/memory.c
===================================================================
--- tip.orig/mm/memory.c 2008-11-11 10:10:11.000000000 -0800
+++ tip/mm/memory.c 2008-11-11 12:10:18.000000000 -0800
@@ -99,6 +99,28 @@ int randomize_va_space __read_mostly =
2;
#endif

+#ifndef track_pfn_vma_new
+int track_pfn_vma_new(struct vm_area_struct *vma, pgprot_t prot,
+ unsigned long pfn, unsigned long size)
+{
+ return 0;
+}
+#endif
+
+#ifndef track_pfn_vma_copy
+int track_pfn_vma_copy(struct vm_area_struct *vma)
+{
+ return 0;
+}
+#endif
+
+#ifndef untrack_pfn_vma
+void untrack_pfn_vma(struct vm_area_struct *vma, unsigned long pfn,
+ unsigned long size)
+{
+}
+#endif
+
static int __init disable_randmaps(char *s)
{
randomize_va_space = 0;
@@ -669,6 +691,16 @@ int copy_page_range(struct mm_struct *ds
if (is_vm_hugetlb_page(vma))
return copy_hugetlb_page_range(dst_mm, src_mm, vma);

+ if (is_pfn_mapping(vma)) {
+ /*
+ * We do not free on error cases below as remove_vma
+ * gets called on error from higher level routine
+ */
+ ret = track_pfn_vma_copy(vma);
+ if (ret)
+ return ret;
+ }
+
/*
* We need to invalidate the secondary MMU mappings only when
* there could be a permission downgrade on the ptes of the
@@ -915,6 +947,9 @@ unsigned long unmap_vmas(struct mmu_gath
if (vma->vm_flags & VM_ACCOUNT)
*nr_accounted += (end - start) >> PAGE_SHIFT;

+ if (is_pfn_mapping(vma))
+ untrack_pfn_vma(vma, 0, 0);
+
while (start != end) {
if (!tlb_start_valid) {
tlb_start = start;
@@ -1473,6 +1508,7 @@ out:
int vm_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn)
{
+ int ret;
/*
* Technically, architectures with pte_special can avoid all these
* restrictions (same for remap_pfn_range). However we would like
@@ -1489,7 +1525,15 @@ int vm_insert_pfn(struct vm_area_struct
return -EFAULT;

vma->vm_flags |= VM_PFNMAP;
- return insert_pfn(vma, addr, pfn, vma->vm_page_prot);
+ if (track_pfn_vma_new(vma, vma->vm_page_prot, pfn, PAGE_SIZE))
+ return -EINVAL;
+
+ ret = insert_pfn(vma, addr, pfn, vma->vm_page_prot);
+
+ if (ret)
+ untrack_pfn_vma(vma, pfn, PAGE_SIZE);
+
+ return ret;
}
EXPORT_SYMBOL(vm_insert_pfn);

@@ -1627,6 +1671,10 @@ int remap_pfn_range(struct vm_area_struc

vma->vm_flags |= VM_IO | VM_RESERVED | VM_PFNMAP;

+ err = track_pfn_vma_new(vma, prot, pfn, PAGE_ALIGN(size));
+ if (err)
+ return -EINVAL;
+
BUG_ON(addr >= end);
pfn -= addr >> PAGE_SHIFT;
pgd = pgd_offset(mm, addr);
@@ -1638,6 +1686,10 @@ int remap_pfn_range(struct vm_area_struc
if (err)
break;
} while (pgd++, addr = next, addr != end);
+
+ if (err)
+ untrack_pfn_vma(vma, pfn, PAGE_ALIGN(size));
+
return err;
}
EXPORT_SYMBOL(remap_pfn_range);
Index: tip/include/linux/mm.h
===================================================================
--- tip.orig/include/linux/mm.h 2008-11-11 10:10:11.000000000 -0800
+++ tip/include/linux/mm.h 2008-11-11 10:10:12.000000000 -0800
@@ -155,6 +155,12 @@ static inline int is_pfn_mapping(struct
return (vma->vm_flags & VM_PFNMAP);
}

+extern int track_pfn_vma_new(struct vm_area_struct *vma, pgprot_t prot,
+ unsigned long pfn, unsigned long size);
+extern int track_pfn_vma_copy(struct vm_area_struct *vma);
+extern void untrack_pfn_vma(struct vm_area_struct *vma, unsigned long pfn,
+ unsigned long size);
+
/*
* vm_fault is filled by the the pagefault handler and passed to the vma's
* ->fault function. The vma's ->fault is responsible for returning a bitmask

--


2008-12-16 19:58:20

by Andrew Morton

[permalink] [raw]
Subject: Re: [patch 4/8] x86 PAT: hooks in generic vm code to help archs to track pfnmap regions

On Wed, 12 Nov 2008 13:26:51 -0800
Venkatesh Pallipadi <[email protected]> wrote:

> --- tip.orig/mm/memory.c 2008-11-11 10:10:11.000000000 -0800
> +++ tip/mm/memory.c 2008-11-11 12:10:18.000000000 -0800
> @@ -99,6 +99,28 @@ int randomize_va_space __read_mostly =
> 2;
> #endif
>
> +#ifndef track_pfn_vma_new
> +int track_pfn_vma_new(struct vm_area_struct *vma, pgprot_t prot,
> + unsigned long pfn, unsigned long size)
> +{
> + return 0;
> +}
> +#endif
> +
> +#ifndef track_pfn_vma_copy
> +int track_pfn_vma_copy(struct vm_area_struct *vma)
> +{
> + return 0;
> +}
> +#endif
> +
> +#ifndef untrack_pfn_vma
> +void untrack_pfn_vma(struct vm_area_struct *vma, unsigned long pfn,
> + unsigned long size)
> +{
> +}
> +#endif

Using __weak would provide a somewhat neater result here.

2008-12-16 20:07:31

by Pallipadi, Venkatesh

[permalink] [raw]
Subject: RE: [patch 4/8] x86 PAT: hooks in generic vm code to help archs to track pfnmap regions



>-----Original Message-----
>From: Andrew Morton [mailto:[email protected]]
>Sent: Tuesday, December 16, 2008 11:57 AM
>To: Pallipadi, Venkatesh
>Cc: [email protected]; [email protected]; [email protected];
>[email protected]; [email protected]; [email protected];
>[email protected]; [email protected];
>[email protected]; [email protected]; Pallipadi,
>Venkatesh; Siddha, Suresh B
>Subject: Re: [patch 4/8] x86 PAT: hooks in generic vm code to
>help archs to track pfnmap regions
>
>On Wed, 12 Nov 2008 13:26:51 -0800
>Venkatesh Pallipadi <[email protected]> wrote:
>
>> --- tip.orig/mm/memory.c 2008-11-11 10:10:11.000000000 -0800
>> +++ tip/mm/memory.c 2008-11-11 12:10:18.000000000 -0800
>> @@ -99,6 +99,28 @@ int randomize_va_space __read_mostly =
>> 2;
>> #endif
>>
>> +#ifndef track_pfn_vma_new
>> +int track_pfn_vma_new(struct vm_area_struct *vma, pgprot_t prot,
>> + unsigned long pfn, unsigned long size)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> +#ifndef track_pfn_vma_copy
>> +int track_pfn_vma_copy(struct vm_area_struct *vma)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> +#ifndef untrack_pfn_vma
>> +void untrack_pfn_vma(struct vm_area_struct *vma, unsigned long pfn,
>> + unsigned long size)
>> +{
>> +}
>> +#endif
>
>Using __weak would provide a somewhat neater result here.
>

Thought about that. But, then remembered the issues with gcc versions and __weak, as in here
http://lkml.org/lkml/2008/5/1/368

and decided to take the safer approach.

Thanks,
Venki-

2008-12-16 20:14:10

by Andrew Morton

[permalink] [raw]
Subject: Re: [patch 4/8] x86 PAT: hooks in generic vm code to help archs to track pfnmap regions

On Tue, 16 Dec 2008 12:07:56 -0800
"Pallipadi, Venkatesh" <[email protected]> wrote:

>
>
> >-----Original Message-----
> >From: Andrew Morton [mailto:[email protected]]
> >Sent: Tuesday, December 16, 2008 11:57 AM
> >To: Pallipadi, Venkatesh
> >Cc: [email protected]; [email protected]; [email protected];
> >[email protected]; [email protected]; [email protected];
> >[email protected]; [email protected];
> >[email protected]; [email protected]; Pallipadi,
> >Venkatesh; Siddha, Suresh B
> >Subject: Re: [patch 4/8] x86 PAT: hooks in generic vm code to
> >help archs to track pfnmap regions

Your emails are getting mucked up.

> >On Wed, 12 Nov 2008 13:26:51 -0800
> >Venkatesh Pallipadi <[email protected]> wrote:
> >
> >> --- tip.orig/mm/memory.c 2008-11-11 10:10:11.000000000 -0800
> >> +++ tip/mm/memory.c 2008-11-11 12:10:18.000000000 -0800
> >> @@ -99,6 +99,28 @@ int randomize_va_space __read_mostly =
> >> 2;
> >> #endif
> >>
> >> +#ifndef track_pfn_vma_new
> >> +int track_pfn_vma_new(struct vm_area_struct *vma, pgprot_t prot,
> >> + unsigned long pfn, unsigned long size)
> >> +{
> >> + return 0;
> >> +}
> >> +#endif
> >> +
> >> +#ifndef track_pfn_vma_copy
> >> +int track_pfn_vma_copy(struct vm_area_struct *vma)
> >> +{
> >> + return 0;
> >> +}
> >> +#endif
> >> +
> >> +#ifndef untrack_pfn_vma
> >> +void untrack_pfn_vma(struct vm_area_struct *vma, unsigned long pfn,
> >> + unsigned long size)
> >> +{
> >> +}
> >> +#endif
> >
> >Using __weak would provide a somewhat neater result here.
> >
>
> Thought about that. But, then remembered the issues with gcc versions and __weak, as in here
> http://lkml.org/lkml/2008/5/1/368
>
> and decided to take the safer approach.
>

Yes, it is a concern.