All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] proc: clear_refs: do not clear reserved pages
Date: Sun, 15 Jan 2012 15:07:07 +0000	[thread overview]
Message-ID: <20120115150706.GA7474@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1201140901260.2381@eggly.anvils>

Hi Hugh,

Thanks for the explanation.

On Sat, Jan 14, 2012 at 05:36:37PM +0000, Hugh Dickins wrote:
> On Fri, 13 Jan 2012, Nicolas Pitre wrote:
> > Given Andrew's answer, this should be fine wrt Russell's concern.
> > 
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> 
> Yes, it should be okay as an urgent fix for -stable.
> But going forward, I doubt it's the right answer: comments below.

Ok great, getting this into -stable ASAP would be much appreciated. Can
somebody pick it up please?

> Please, going forward, can you delete your vectors page code, and
> use the gate_vma for it?  Extending it a little if it somehow does
> not satsify your need.  Or else can you please explain (ec706dab
> does not) why the gate_vma does not suit you.
> 
> I'm not saying the horrible hack gate_vma mechanism is any safer
> than yours (the latest bug in it was fixed all of 13 days ago).
> But I am saying that one horrible hack is safer than two.

Something like what I've got below seems to do the trick, and clear_refs
also seems to behave when it's presented with the gate_vma. If Russell is
happy with the approach, we can move to the gate_vma in the future.

Thanks,

Will


    ARM: vectors: use gate_vma for vectors user mapping
    
    The current user mapping for the vectors page is inserted as a `horrible
    hack vma' into each task via arch_setup_additional_pages. This causes
    problems with the MM subsystem and vm_normal_page, as described here:
    
    https://lkml.org/lkml/2012/1/14/55
    
    Following the suggestion from Hugh in the above thread, this patch uses
    the gate_vma for the vectors user mapping, therefore consolidating
    the horrible hack VMAs into one.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>

diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h
index 0e9ce8d..38050b1 100644
--- a/arch/arm/include/asm/elf.h
+++ b/arch/arm/include/asm/elf.h
@@ -130,8 +130,4 @@ struct mm_struct;
 extern unsigned long arch_randomize_brk(struct mm_struct *mm);
 #define arch_randomize_brk arch_randomize_brk
 
-extern int vectors_user_mapping(void);
-#define arch_setup_additional_pages(bprm, uses_interp) vectors_user_mapping()
-#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
-
 #endif
diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index ca94653..e851aa3 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -151,6 +151,8 @@ extern void __cpu_copy_user_highpage(struct page *to, struct page *from,
 #define clear_page(page)	memset((void *)(page), 0, PAGE_SIZE)
 extern void copy_page(void *to, const void *from);
 
+#define __HAVE_ARCH_GATE_AREA 1
+
 #include <asm/pgtable-2level-types.h>
 
 #endif /* CONFIG_MMU */
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 3d0c6fb..c13b8f6 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -493,22 +493,40 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
 #ifdef CONFIG_MMU
 /*
  * The vectors page is always readable from user space for the
- * atomic helpers and the signal restart code.  Let's declare a mapping
- * for it so it is visible through ptrace and /proc/<pid>/mem.
+ * atomic helpers and the signal restart code. Insert it into the
+ * gate_vma so that it is visible through ptrace and /proc/<pid>/mem.
  */
+static struct vm_area_struct gate_vma;
 
-int vectors_user_mapping(void)
+static int __init gate_vma_init(void)
 {
-	struct mm_struct *mm = current->mm;
-	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
-				       VM_READ | VM_EXEC |
-				       VM_MAYREAD | VM_MAYEXEC |
-				       VM_ALWAYSDUMP | VM_RESERVED,
-				       NULL);
+	gate_vma.vm_start	= 0xffff0000;
+	gate_vma.vm_end		= 0xffff0000 + PAGE_SIZE;
+	gate_vma.vm_page_prot	= PAGE_READONLY_EXEC;
+	gate_vma.vm_flags	= VM_READ | VM_EXEC |
+				  VM_MAYREAD | VM_MAYEXEC |
+				  VM_ALWAYSDUMP;
+	return 0;
+}
+arch_initcall(gate_vma_init);
+
+struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
+{
+	return &gate_vma;
+}
+
+int in_gate_area(struct mm_struct *mm, unsigned long addr)
+{
+	return (addr >= gate_vma.vm_start) && (addr < gate_vma.vm_end);
+}
+
+int in_gate_area_no_mm(unsigned long addr)
+{
+	return in_gate_area(NULL, addr);
 }
 
 const char *arch_vma_name(struct vm_area_struct *vma)
 {
-	return (vma->vm_start == 0xffff0000) ? "[vectors]" : NULL;
+	return (vma == &gate_vma) ? "[vectors]" : NULL;
 }
 #endif

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Hugh Dickins <hughd@google.com>
Cc: Nicolas Pitre <nico@fluxnic.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"moussaba@micron.com" <moussaba@micron.com>,
	David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: Re: [RFC PATCH] proc: clear_refs: do not clear reserved pages
Date: Sun, 15 Jan 2012 15:07:07 +0000	[thread overview]
Message-ID: <20120115150706.GA7474@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1201140901260.2381@eggly.anvils>

Hi Hugh,

Thanks for the explanation.

On Sat, Jan 14, 2012 at 05:36:37PM +0000, Hugh Dickins wrote:
> On Fri, 13 Jan 2012, Nicolas Pitre wrote:
> > Given Andrew's answer, this should be fine wrt Russell's concern.
> > 
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> 
> Yes, it should be okay as an urgent fix for -stable.
> But going forward, I doubt it's the right answer: comments below.

Ok great, getting this into -stable ASAP would be much appreciated. Can
somebody pick it up please?

> Please, going forward, can you delete your vectors page code, and
> use the gate_vma for it?  Extending it a little if it somehow does
> not satsify your need.  Or else can you please explain (ec706dab
> does not) why the gate_vma does not suit you.
> 
> I'm not saying the horrible hack gate_vma mechanism is any safer
> than yours (the latest bug in it was fixed all of 13 days ago).
> But I am saying that one horrible hack is safer than two.

Something like what I've got below seems to do the trick, and clear_refs
also seems to behave when it's presented with the gate_vma. If Russell is
happy with the approach, we can move to the gate_vma in the future.

Thanks,

Will


    ARM: vectors: use gate_vma for vectors user mapping
    
    The current user mapping for the vectors page is inserted as a `horrible
    hack vma' into each task via arch_setup_additional_pages. This causes
    problems with the MM subsystem and vm_normal_page, as described here:
    
    https://lkml.org/lkml/2012/1/14/55
    
    Following the suggestion from Hugh in the above thread, this patch uses
    the gate_vma for the vectors user mapping, therefore consolidating
    the horrible hack VMAs into one.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>

diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h
index 0e9ce8d..38050b1 100644
--- a/arch/arm/include/asm/elf.h
+++ b/arch/arm/include/asm/elf.h
@@ -130,8 +130,4 @@ struct mm_struct;
 extern unsigned long arch_randomize_brk(struct mm_struct *mm);
 #define arch_randomize_brk arch_randomize_brk
 
-extern int vectors_user_mapping(void);
-#define arch_setup_additional_pages(bprm, uses_interp) vectors_user_mapping()
-#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
-
 #endif
diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index ca94653..e851aa3 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -151,6 +151,8 @@ extern void __cpu_copy_user_highpage(struct page *to, struct page *from,
 #define clear_page(page)	memset((void *)(page), 0, PAGE_SIZE)
 extern void copy_page(void *to, const void *from);
 
+#define __HAVE_ARCH_GATE_AREA 1
+
 #include <asm/pgtable-2level-types.h>
 
 #endif /* CONFIG_MMU */
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 3d0c6fb..c13b8f6 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -493,22 +493,40 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
 #ifdef CONFIG_MMU
 /*
  * The vectors page is always readable from user space for the
- * atomic helpers and the signal restart code.  Let's declare a mapping
- * for it so it is visible through ptrace and /proc/<pid>/mem.
+ * atomic helpers and the signal restart code. Insert it into the
+ * gate_vma so that it is visible through ptrace and /proc/<pid>/mem.
  */
+static struct vm_area_struct gate_vma;
 
-int vectors_user_mapping(void)
+static int __init gate_vma_init(void)
 {
-	struct mm_struct *mm = current->mm;
-	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
-				       VM_READ | VM_EXEC |
-				       VM_MAYREAD | VM_MAYEXEC |
-				       VM_ALWAYSDUMP | VM_RESERVED,
-				       NULL);
+	gate_vma.vm_start	= 0xffff0000;
+	gate_vma.vm_end		= 0xffff0000 + PAGE_SIZE;
+	gate_vma.vm_page_prot	= PAGE_READONLY_EXEC;
+	gate_vma.vm_flags	= VM_READ | VM_EXEC |
+				  VM_MAYREAD | VM_MAYEXEC |
+				  VM_ALWAYSDUMP;
+	return 0;
+}
+arch_initcall(gate_vma_init);
+
+struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
+{
+	return &gate_vma;
+}
+
+int in_gate_area(struct mm_struct *mm, unsigned long addr)
+{
+	return (addr >= gate_vma.vm_start) && (addr < gate_vma.vm_end);
+}
+
+int in_gate_area_no_mm(unsigned long addr)
+{
+	return in_gate_area(NULL, addr);
 }
 
 const char *arch_vma_name(struct vm_area_struct *vma)
 {
-	return (vma->vm_start == 0xffff0000) ? "[vectors]" : NULL;
+	return (vma == &gate_vma) ? "[vectors]" : NULL;
 }
 #endif

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Hugh Dickins <hughd@google.com>
Cc: Nicolas Pitre <nico@fluxnic.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"moussaba@micron.com" <moussaba@micron.com>,
	David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: Re: [RFC PATCH] proc: clear_refs: do not clear reserved pages
Date: Sun, 15 Jan 2012 15:07:07 +0000	[thread overview]
Message-ID: <20120115150706.GA7474@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1201140901260.2381@eggly.anvils>

Hi Hugh,

Thanks for the explanation.

On Sat, Jan 14, 2012 at 05:36:37PM +0000, Hugh Dickins wrote:
> On Fri, 13 Jan 2012, Nicolas Pitre wrote:
> > Given Andrew's answer, this should be fine wrt Russell's concern.
> > 
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> 
> Yes, it should be okay as an urgent fix for -stable.
> But going forward, I doubt it's the right answer: comments below.

Ok great, getting this into -stable ASAP would be much appreciated. Can
somebody pick it up please?

> Please, going forward, can you delete your vectors page code, and
> use the gate_vma for it?  Extending it a little if it somehow does
> not satsify your need.  Or else can you please explain (ec706dab
> does not) why the gate_vma does not suit you.
> 
> I'm not saying the horrible hack gate_vma mechanism is any safer
> than yours (the latest bug in it was fixed all of 13 days ago).
> But I am saying that one horrible hack is safer than two.

Something like what I've got below seems to do the trick, and clear_refs
also seems to behave when it's presented with the gate_vma. If Russell is
happy with the approach, we can move to the gate_vma in the future.

Thanks,

Will


    ARM: vectors: use gate_vma for vectors user mapping
    
    The current user mapping for the vectors page is inserted as a `horrible
    hack vma' into each task via arch_setup_additional_pages. This causes
    problems with the MM subsystem and vm_normal_page, as described here:
    
    https://lkml.org/lkml/2012/1/14/55
    
    Following the suggestion from Hugh in the above thread, this patch uses
    the gate_vma for the vectors user mapping, therefore consolidating
    the horrible hack VMAs into one.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>

diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h
index 0e9ce8d..38050b1 100644
--- a/arch/arm/include/asm/elf.h
+++ b/arch/arm/include/asm/elf.h
@@ -130,8 +130,4 @@ struct mm_struct;
 extern unsigned long arch_randomize_brk(struct mm_struct *mm);
 #define arch_randomize_brk arch_randomize_brk
 
-extern int vectors_user_mapping(void);
-#define arch_setup_additional_pages(bprm, uses_interp) vectors_user_mapping()
-#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
-
 #endif
diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index ca94653..e851aa3 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -151,6 +151,8 @@ extern void __cpu_copy_user_highpage(struct page *to, struct page *from,
 #define clear_page(page)	memset((void *)(page), 0, PAGE_SIZE)
 extern void copy_page(void *to, const void *from);
 
+#define __HAVE_ARCH_GATE_AREA 1
+
 #include <asm/pgtable-2level-types.h>
 
 #endif /* CONFIG_MMU */
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 3d0c6fb..c13b8f6 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -493,22 +493,40 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
 #ifdef CONFIG_MMU
 /*
  * The vectors page is always readable from user space for the
- * atomic helpers and the signal restart code.  Let's declare a mapping
- * for it so it is visible through ptrace and /proc/<pid>/mem.
+ * atomic helpers and the signal restart code. Insert it into the
+ * gate_vma so that it is visible through ptrace and /proc/<pid>/mem.
  */
+static struct vm_area_struct gate_vma;
 
-int vectors_user_mapping(void)
+static int __init gate_vma_init(void)
 {
-	struct mm_struct *mm = current->mm;
-	return install_special_mapping(mm, 0xffff0000, PAGE_SIZE,
-				       VM_READ | VM_EXEC |
-				       VM_MAYREAD | VM_MAYEXEC |
-				       VM_ALWAYSDUMP | VM_RESERVED,
-				       NULL);
+	gate_vma.vm_start	= 0xffff0000;
+	gate_vma.vm_end		= 0xffff0000 + PAGE_SIZE;
+	gate_vma.vm_page_prot	= PAGE_READONLY_EXEC;
+	gate_vma.vm_flags	= VM_READ | VM_EXEC |
+				  VM_MAYREAD | VM_MAYEXEC |
+				  VM_ALWAYSDUMP;
+	return 0;
+}
+arch_initcall(gate_vma_init);
+
+struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
+{
+	return &gate_vma;
+}
+
+int in_gate_area(struct mm_struct *mm, unsigned long addr)
+{
+	return (addr >= gate_vma.vm_start) && (addr < gate_vma.vm_end);
+}
+
+int in_gate_area_no_mm(unsigned long addr)
+{
+	return in_gate_area(NULL, addr);
 }
 
 const char *arch_vma_name(struct vm_area_struct *vma)
 {
-	return (vma->vm_start == 0xffff0000) ? "[vectors]" : NULL;
+	return (vma == &gate_vma) ? "[vectors]" : NULL;
 }
 #endif


  reply	other threads:[~2012-01-15 15:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-13 15:13 [RFC PATCH] proc: clear_refs: do not clear reserved pages Will Deacon
2012-01-13 15:13 ` Will Deacon
2012-01-13 15:13 ` Will Deacon
2012-01-13 15:35 ` Russell King - ARM Linux
2012-01-13 15:35   ` Russell King - ARM Linux
2012-01-13 15:35   ` Russell King - ARM Linux
2012-01-13 22:43   ` Andrew Morton
2012-01-13 22:43     ` Andrew Morton
2012-01-13 22:43     ` Andrew Morton
2012-01-13 22:55 ` Nicolas Pitre
2012-01-13 22:55   ` Nicolas Pitre
2012-01-13 22:55   ` Nicolas Pitre
2012-01-14 17:36   ` Hugh Dickins
2012-01-14 17:36     ` Hugh Dickins
2012-01-14 17:36     ` Hugh Dickins
2012-01-15 15:07     ` Will Deacon [this message]
2012-01-15 15:07       ` Will Deacon
2012-01-15 15:07       ` Will Deacon
2012-01-16  4:19       ` Nicolas Pitre
2012-01-16  4:19         ` Nicolas Pitre
2012-01-16  4:19         ` Nicolas Pitre
2012-01-16 10:06         ` Will Deacon
2012-01-16 10:06           ` Will Deacon
2012-01-16 10:06           ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120115150706.GA7474@mudshark.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.