From: Oleg Nesterov <oleg@redhat.com>
To: akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, adobriyan@gmail.com,
dhowells@redhat.com, ebiederm@xmission.com, hch@lst.de,
matthltc@us.ibm.com
Subject: Re: + mm-remove-struct-mm_struct-exe_file-et-al.patch added to -mm tree
Date: Tue, 31 Mar 2009 16:40:51 +0200 [thread overview]
Message-ID: <20090331144051.GA3951@redhat.com> (raw)
In-Reply-To: <200903302344.n2UNi3xd027136@imap1.linux-foundation.org>
s/mm-commits/lkml/
On 03/30, Andrew Morton wrote:
>
> From: Alexey Dobriyan <adobriyan@gmail.com>
>
> Commit 925d1c401fa6cfd0df5d2e37da8981494ccdec07 ("procfs task exe
> symlink"). introduced struct mm_struct::exe_file and struct
> mm_struct::num_exe_file_vmas.
>
> The rationale is weak: unifying MMU and no-MMU version of /proc/*/exe
> code. For this a) struct mm_struct becomes bigger, b) mmap/munmap/exit
> become slower, c) patch adds more code than removes in fact.
>
> ->exe_file maybe well defined, but doesn't make sense always. After
> original executable is unmapped, /proc/*/exe will still report it and,
> more importantly, pin corresponding struct file.
I never liked the change which introduced mm->exe_file, so I vote for
this patch.
But, as a advocatus diaboli... There was anotrher reason for ->exe_file,
iirc.
bprm->file->f_op->mmap() can change vma->vm_file, this means proc_exe_link()
can report the "wrong" path. The original file is not pinned in this case.
Matt?
Oleg.
next prev parent reply other threads:[~2009-03-31 14:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-30 23:44 + mm-remove-struct-mm_struct-exe_file-et-al.patch added to -mm tree akpm
2009-03-31 14:40 ` Oleg Nesterov [this message]
2009-04-01 0:32 ` Matt Helsley
2009-04-01 1:13 ` Alexey Dobriyan
2009-04-01 12:55 ` David Howells
2009-04-01 1:40 ` Oleg Nesterov
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=20090331144051.GA3951@redhat.com \
--to=oleg@redhat.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.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 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.