All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@openvz.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"kosaki.motohiro@jp.fujitsu.com" <kosaki.motohiro@jp.fujitsu.com>,
	"matthltc@us.ibm.com" <matthltc@us.ibm.com>,
	"tj@kernel.org" <tj@kernel.org>,
	Pavel Emelianov <xemul@parallels.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: + c-r-prctl-add-ability-to-set-new-mm_struct-exe_file-update-after-mm- num_exe_file_vmas-removal.patch added to -mm tree
Date: Fri, 20 Apr 2012 02:02:01 +0400	[thread overview]
Message-ID: <20120419220201.GR1893@moon> (raw)
In-Reply-To: <20120419215109.GA4896@redhat.com>

On Thu, Apr 19, 2012 at 11:51:09PM +0200, Oleg Nesterov wrote:
> On 04/20, Konstantin Khlebnikov wrote:
> >
> > Oleg Nesterov wrote:
> >>
> >> You misunderstood. I am not arguing with "one-shot", I do not really
> >> care.
> >>
> >> My question is: unless I missed something "it can't be changed again"
> >> is not actually true. A task does PR_SET_MM_EXE_FILE, then it forks
> >> the new child. The child can do PR_SET_MM_EXE_FILE again. Is this
> >> by design?
> >>
> >> Oleg.
> >>
> >
> > I found more weird case: child thread (with CLONE_THREAD and without CLONE_VM)
> > changes its exe_file...
> 
> No. copy_process() does:
> 
> 	if ((clone_flags & CLONE_THREAD) && !(clone_flags & CLONE_SIGHAND))
> 		return ERR_PTR(-EINVAL);
> 
> 	if ((clone_flags & CLONE_SIGHAND) && !(clone_flags & CLONE_VM))
> 		return ERR_PTR(-EINVAL);
> 
> IOW, CLONE_THREAD => CLONE_SIGHAND => CLONE_VM

Guys, while I more-less agree with Matt about single-shot behaviour

[ let me copy my and his email

  >> With mm->exe_file this prctl option become a one-shot
  >> only, and while at moment our user-space tool can perfectly
  >> live with that I thought that there is no strict need to
  >> limit the option this way from the very beginning.
  >>
  > As far as backward compatibility, isn't it better to lift that restriction
  > later rather than add it? I think the latter would very likely "break"
  > things whereas the former would not.
  >
  > I also prefer that restriction because it establishes a bound on how
  > frequently the symlink can change. Keeping it a one-shot deal makes the
  > values that show up in tools like top more reliable for admins.
]

I guess maybe it's time to drop one-shot requirement and as result
we can drop MMF_EXE_FILE_CHANGED bit completely, making overall code
simplier?

Our tool can live with any behaviour (and one shot and multishot,
doesn't matter).

	Cyrill

  reply	other threads:[~2012-04-19 22:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19 18:52 + c-r-prctl-add-ability-to-set-new-mm_struct-exe_file-update-after-mm-num_exe_file_vmas-removal.patch added to -mm tree akpm
2012-04-19 19:20 ` + c-r-prctl-add-ability-to-set-new-mm_struct-exe_file-update-after-mm- num_exe_file_vmas-removal.patch " Oleg Nesterov
2012-04-19 21:00   ` Cyrill Gorcunov
2012-04-19 21:12     ` Oleg Nesterov
2012-04-19 21:32       ` Cyrill Gorcunov
2012-04-19 22:08         ` Konstantin Khlebnikov
2012-04-19 22:16           ` Cyrill Gorcunov
2012-04-19 22:29           ` Oleg Nesterov
2012-04-19 21:46       ` Konstantin Khlebnikov
2012-04-19 21:51         ` Oleg Nesterov
2012-04-19 22:02           ` Cyrill Gorcunov [this message]
2012-04-19 22:09             ` Oleg Nesterov
2012-04-19 22:28               ` Konstantin Khlebnikov
2012-04-19 22:32               ` Cyrill Gorcunov

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=20120419220201.GR1893@moon \
    --to=gorcunov@openvz.org \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=khlebnikov@openvz.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthltc@us.ibm.com \
    --cc=oleg@redhat.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.