From: Oleg Nesterov <oleg@redhat.com>
To: Matt Helsley <matthltc@us.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Pavel Emelyanov <xemul@parallels.com>, Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/1] turn mm->exe_file into mm->exe_path
Date: Tue, 6 Mar 2012 17:28:14 +0100 [thread overview]
Message-ID: <20120306162814.GA12836@redhat.com> (raw)
In-Reply-To: <20120305211436.GM7666@count0.beaverton.ibm.com>
On 03/05, Matt Helsley wrote:
>
> On Mon, Mar 05, 2012 at 04:28:26PM +0100, Oleg Nesterov wrote:
> >
> > Unless there was another subtle reason, "struct path *exe_path"
> > can equally work but it looks more clear.
>
> PATCH 1/1 looks fine. I think Alexey Dobriyan was working on a similar
> patch years ago.
Good, can I take the above as your Acked-by/Reviewed-by ?
> > And can't we also remove added_exe_file_vma/removed_exe_file_vma?
> > Why do we need mm->num_exe_file_vmas? Afaics it is only needed to
> > "free" mm->exe_file if the application unmaps all these vmas. Say,
> > to allow to unmount fs.
>
> Yup. I know it's not pretty to have to track the exe file refs this way
> but I couldn't see any other way to keep a reference to the file (or
> path) and avoid pinning the mounted filesystem the exectuable is on.
>
> > Can't we simply add PR_CLEAR_MM_EXE_PATH instead? Of course it is
> > not enough if ->vm_file still has a reference. But c/r people want
>
> Relying solely on this prctl would break existing programs.
so we can't :/ I expected this answer.
> I believe Al
> Viro's example was a program that copies its text to a new executable
> area, unmaps the original, performs a pivot_root(), and finally umounts
> the old root. Removing the counter would cause the mount to be pinned
> for these programs and the umount would fail.
Yes, sure, the application should do PR_SET_MM_EXE_PATH(NULL) after unmap.
I am wondering if there is any apllication which actually does this.
But OK, it is hardly possible to argue with "break existing program".
Thanks,
Oleg.
next prev parent reply other threads:[~2012-03-06 16:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-05 15:28 [PATCH 0/1] turn mm->exe_file into mm->exe_path Oleg Nesterov
2012-03-05 15:28 ` [PATCH 1/1] " Oleg Nesterov
2012-03-05 17:05 ` [PATCH 0/1] " Cyrill Gorcunov
2012-03-05 17:33 ` Oleg Nesterov
2012-03-05 18:25 ` Cyrill Gorcunov
2012-03-05 21:14 ` Matt Helsley
2012-03-06 16:28 ` Oleg Nesterov [this message]
2012-03-06 16:41 ` Cyrill Gorcunov
2012-03-06 18:16 ` 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=20120306162814.GA12836@redhat.com \
--to=oleg@redhat.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=gorcunov@openvz.org \
--cc=keescook@chromium.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=tj@kernel.org \
--cc=xemul@parallels.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.