From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Cyrill Gorcunov <gorcunov@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:28:30 +0400 [thread overview]
Message-ID: <4F90918E.3050202@openvz.org> (raw)
In-Reply-To: <20120419220918.GA5474@redhat.com>
Oleg Nesterov wrote:
> On 04/20, Cyrill Gorcunov wrote:
>>
>> 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,
>
> Plus perhaps we can remove this for_each_vma check?
>
>> making overall code
>> simplier?
>
> Personally I'd certainly prefer this ;)
>
>
>
> But let me repeat to avoid the confusion. I am fine either way,
> I am not going to discuss this again unless I see something which
> looks technically wrong. And the current MMF_EXE_FILE_CHANGED
> doesn't look right even if the problem is minor.
Yeah, whole this protection does not protect anything and can be easily bypassed.
For example task can re-execute itself and change exe-file again and again.
>
> Oleg.
>
next prev parent reply other threads:[~2012-04-19 22:28 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
2012-04-19 22:09 ` Oleg Nesterov
2012-04-19 22:28 ` Konstantin Khlebnikov [this message]
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=4F90918E.3050202@openvz.org \
--to=khlebnikov@openvz.org \
--cc=akpm@linux-foundation.org \
--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=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.