linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matt Helsley <matthltc@us.ibm.com>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Oleg Nesterov <oleg@tv-sign.ru>,
	David Howells <dhowells@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Christoph Hellwig <chellwig@de.ibm.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Hugh Dickins <hugh@veritas.com>, Bryan Wu <Bryan.Wu@analog.com>
Subject: Re: [PATCH] procfs task exe symlink
Date: Tue, 19 Feb 2008 13:54:25 -0800	[thread overview]
Message-ID: <1203458065.7408.27.camel@localhost.localdomain> (raw)
In-Reply-To: <8bd0f97a0802160412ve49103cya446b89d8560458b@mail.gmail.com>

On Sat, 2008-02-16 at 07:12 -0500, Mike Frysinger wrote:
> On Feb 6, 2008 8:44 PM, Matt Helsley <matthltc@us.ibm.com> wrote:
> > The kernel implements readlink of /proc/pid/exe by getting the file from the
> > first executable VMA. Then the path to the file is reconstructed and reported as
> > the result.
> >
> > Because of the VMA walk the code is slightly different on nommu systems. This
> > patch avoids separate /proc/pid/exe code on nommu systems. Instead of walking
> > the VMAs to find the first executable file-backed VMA we store a reference to
> > the exec'd file in the mm_struct.
> >
> > That reference would prevent the filesystem holding the executable file from
> > being unmounted even after unmapping the VMAs. So we track the number of
> > VM_EXECUTABLE VMAs and drop the new reference when the last one is unmapped.
> > This avoids pinning the mounted filesystem.
> >
> > Andrew, these are the updates I promised. Please consider this patch for
> > inclusion in -mm.
> 
> mm/nommu.c wasnt compiled tested, it's trivially broken:

Thanks for the report. I've looked into this and the "obvious" fix,
using vma->vm_mm, isn't correct since it's never set. This means the
portions of the procfs task exe symlink patch using vma->vm_mm in
mm/nommu.c are incorrect.

The patch below attempts to fix this by using current->mm during mmap
and passing the current mm to put_vma() as well.

Mike, does this patch fix the compile problem(s)?

Signed-off-by: Matt Helsley <matthltc@us.ibm.com>

---
Mike, I don't have a nommu compile or test environment. I have yet
to to generate a good CONFIG_MMU=n config on i386 (got one?). Since I
don't have any nommu hardware I'm also looking into using qemu. It looks
like I may need to build my own image from scratch. Do you have any
recommendations on testing nommu configs without hardware?

 mm/nommu.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

Index: linux-2.6.24/mm/nommu.c
===================================================================
--- linux-2.6.24.orig/mm/nommu.c
+++ linux-2.6.24/mm/nommu.c
@@ -962,12 +962,14 @@ unsigned long do_mmap_pgoff(struct file 
 
 	INIT_LIST_HEAD(&vma->anon_vma_node);
 	atomic_set(&vma->vm_usage, 1);
 	if (file) {
 		get_file(file);
-		if (vm_flags & VM_EXECUTABLE)
-			added_exe_file_vma(mm);
+		if (vm_flags & VM_EXECUTABLE) {
+			added_exe_file_vma(current->mm);
+			vma->vm_mm = current->mm;
+		}
 	}
 	vma->vm_file	= file;
 	vma->vm_flags	= vm_flags;
 	vma->vm_start	= addr;
 	vma->vm_end	= addr + len;
@@ -1053,11 +1055,11 @@ unsigned long do_mmap_pgoff(struct file 
 EXPORT_SYMBOL(do_mmap_pgoff);
 
 /*
  * handle mapping disposal for uClinux
  */
-static void put_vma(struct vm_area_struct *vma)
+static void put_vma(struct mm_struct *mm, struct vm_area_struct *vma)
 {
 	if (vma) {
 		down_write(&nommu_vma_sem);
 
 		if (atomic_dec_and_test(&vma->vm_usage)) {
@@ -1078,11 +1080,11 @@ static void put_vma(struct vm_area_struc
 			askedalloc -= sizeof(*vma);
 
 			if (vma->vm_file) {
 				fput(vma->vm_file);
 				if (vma->vm_flags & VM_EXECUTABLE)
-					removed_exe_file_vma(vma->vm_mm);
+					removed_exe_file_vma(mm);
 			}
 			kfree(vma);
 		}
 
 		up_write(&nommu_vma_sem);
@@ -1116,11 +1118,11 @@ int do_munmap(struct mm_struct *mm, unsi
 	return -EINVAL;
 
  found:
 	vml = *parent;
 
-	put_vma(vml->vma);
+	put_vma(mm, vml->vma);
 
 	*parent = vml->next;
 	realalloc -= kobjsize(vml);
 	askedalloc -= sizeof(*vml);
 	kfree(vml);
@@ -1161,11 +1163,11 @@ void exit_mmap(struct mm_struct * mm)
 
 		mm->total_vm = 0;
 
 		while ((tmp = mm->context.vmlist)) {
 			mm->context.vmlist = tmp->next;
-			put_vma(tmp->vma);
+			put_vma(mm, tmp->vma);
 
 			realalloc -= kobjsize(tmp);
 			askedalloc -= sizeof(*tmp);
 			kfree(tmp);
 		}


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-02-19 21:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-07  1:44 [PATCH] procfs task exe symlink Matt Helsley
2008-02-16 12:12 ` Mike Frysinger
2008-02-19 21:54   ` Matt Helsley [this message]
2008-02-20  4:02     ` Mike Frysinger
2008-04-26 16:19 ` Andrew Morton
2008-04-26 16:24   ` Al Viro
2008-04-30 11:02     ` Matt Helsley

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=1203458065.7408.27.camel@localhost.localdomain \
    --to=matthltc@us.ibm.com \
    --cc=Bryan.Wu@analog.com \
    --cc=akpm@linux-foundation.org \
    --cc=chellwig@de.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oleg@tv-sign.ru \
    --cc=vapier.adi@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /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).