linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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:08 UTC|newest]

Thread overview: 8+ 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:35 ` Russell King - ARM Linux
2012-01-13 22:43   ` Andrew Morton
2012-01-13 22:55 ` Nicolas Pitre
2012-01-14 17:36   ` Hugh Dickins
2012-01-15 15:07     ` Will Deacon [this message]
2012-01-16  4:19       ` Nicolas Pitre
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=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=moussaba@micron.com \
    --cc=nico@fluxnic.net \
    --cc=rientjes@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).