From: Oleg Nesterov <oleg@redhat.com>
To: Matt Helsley <matthltc@us.ibm.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
adobriyan@gmail.com, dhowells@redhat.com, ebiederm@xmission.com,
hch@lst.de
Subject: Re: + mm-remove-struct-mm_struct-exe_file-et-al.patch added to -mm tree
Date: Wed, 1 Apr 2009 03:40:37 +0200 [thread overview]
Message-ID: <20090401014037.GA32051@redhat.com> (raw)
In-Reply-To: <20090401003223.GH29821@us.ibm.com>
On 03/31, Matt Helsley wrote:
>
> On Tue, Mar 31, 2009 at 04:40:51PM +0200, Oleg Nesterov wrote:
> >
> > 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.
>
> That's _my_ reason for it. However no mainline code does that and hence it was
> not the reason Andrew accepted it.
Good.
> I still prefer ->exe_file because I think it's a win not to walk the
> VMAs with mmap sem when doing a readlink on /proc/*/exe. It's also less
> sensitive to the order in which VMAs appear should that ever change.
I agree with Alexey, I don't think the VMAs walking can be a problem.
But even if it is problem, we could make a much more simple patch
to avoid it? Just add "struct path exe_path" to ->mm, no?
Oleg.
prev parent reply other threads:[~2009-04-01 1:44 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
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 [this message]
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=20090401014037.GA32051@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.