All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@openvz.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Matt Helsley <matthltc@us.ibm.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Pavel Emelyanov <xemul@parallels.com>,
	Kees Cook <keescook@chromium.org>, Tejun Heo <tj@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] c/r: prctl: Add ability to set new mm_struct::exe_file v3
Date: Fri, 9 Mar 2012 18:42:39 +0400	[thread overview]
Message-ID: <20120309144239.GD13346@moon> (raw)
In-Reply-To: <20120309142620.GA5334@redhat.com>

On Fri, Mar 09, 2012 at 03:26:20PM +0100, Oleg Nesterov wrote:
> >
> > To be sure it's not increased somewhere else before
> > down_write taken.
> 
> Who can do this? Only another CLONE_VM thread. And _only_ if we
> already have the bug in mm_exe accounting logic. And only if that
> thread does something to trigger the bug in the small window
> between.

ok, agreed.

> > > into removed_exe_file_vma().
> >
> > This one looks like a good idea for me -- it's cheap and
> > not a hot path.
> 
> But not in this patch, please.
> 

Sure.

> > > But imho your WARN looks like "OK, I checked it lockless but I
> > > am not sure this is correct".
> >
> > Oleg, I bet if someone will be changing num_exe_file_vmas overall
> > idea -- this prctl code will be fixed at last moment (if ever) only
> > because it's very specific, so I wanted to not miss such moment
> > and add some check that the rest of the kernel is in a good state.
> > This test is cheap but may prevent potential problem if one day
> > mm::exe_file concept will be reworked.
> 
> The test is cheap indeed. If you mean performance-wise.
> 
> But it looks confusing, imho. I do not care about a couple of CPU
> cycles. The code should be optimized for the reading in the first
> place, not for executing ;) Imho, of course.
> 
> And once again. Following your logic you need another WARN_ON()
> right after we drop mmap_sem. Why? To be sure it's not increased
> somewhere else _after_ down_write taken. And another one after
> fput.
> 
> Sure, bugs are possible. And yes, in theory this WARN_ON() can
> catch some problem. But there is tradeoff. Given that you need
> another thread to trigger the (potential) bug and the window is
> tiny, how high do you estimate the probability it can help?
> 
> > Sure I can simply drop this WARN_ON ;)
> 
> Oh, keep it if you like it ;)
> 
> Yes I hate it, but you are the author and this is almost cosmetic.

OK, Oleg, can't argue, you've convinced me ;) I'll drop this WARN_ON.
Would it be enough for your Reviewed-by tag? /me hides

	Cyrill

  reply	other threads:[~2012-03-09 14:42 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-08 16:51 [RFC] c/r: prctl: Add ability to set new mm_struct::exe_file v3 Cyrill Gorcunov
2012-03-08 18:26 ` Oleg Nesterov
2012-03-08 19:03   ` Cyrill Gorcunov
2012-03-08 19:05     ` Oleg Nesterov
2012-03-08 19:25       ` Cyrill Gorcunov
2012-03-08 19:25         ` Oleg Nesterov
2012-03-08 19:36           ` Cyrill Gorcunov
2012-03-08 21:48           ` Cyrill Gorcunov
2012-03-09 12:48             ` Oleg Nesterov
2012-03-09 12:57               ` Cyrill Gorcunov
2012-03-09 13:35                 ` Cyrill Gorcunov
2012-03-09 13:47                   ` Oleg Nesterov
2012-03-09 14:13                     ` Cyrill Gorcunov
2012-03-09 14:26                       ` Oleg Nesterov
2012-03-09 14:42                         ` Cyrill Gorcunov [this message]
2012-03-09 15:21                           ` Oleg Nesterov
2012-03-09 15:42                             ` Cyrill Gorcunov
2012-03-09 22:02                               ` Matt Helsley
2012-03-09 22:39                                 ` Cyrill Gorcunov
2012-03-09 23:59                                   ` Matt Helsley
2012-03-10  7:48                                     ` Cyrill Gorcunov
2012-03-13  2:45                                       ` Matt Helsley
2012-03-13  6:26                                         ` Cyrill Gorcunov
2012-03-13  7:18                                           ` Cyrill Gorcunov
2012-03-13 15:43                                             ` Oleg Nesterov
2012-03-13 16:00                                               ` Cyrill Gorcunov
2012-03-13 16:04                                                 ` Cyrill Gorcunov
2012-03-13 16:44                                                   ` Oleg Nesterov
2012-03-14  1:41                                                   ` Matt Helsley
2012-03-14  5:47                                                     ` Cyrill Gorcunov
2012-03-14 22:21                                                       ` Matt Helsley
2012-03-14 22:48                                                         ` Cyrill Gorcunov
2012-03-14  0:36                                               ` Matt Helsley
2012-03-09 21:46     ` Matt Helsley
2012-03-09 21:52       ` Cyrill Gorcunov
2012-03-08 19:31 ` Kees Cook
2012-03-08 19:40   ` Cyrill Gorcunov
2012-03-08 20:02     ` Andy Lutomirski
2012-03-08 20:06       ` Kees Cook
2012-03-08 20:07       ` Cyrill Gorcunov
2012-03-08 20:15         ` Andy Lutomirski
2012-03-08 20:21           ` Cyrill Gorcunov
2012-03-08 20:24             ` Andy Lutomirski
2012-03-08 20:28               ` Cyrill Gorcunov
2012-03-08 21:57               ` Cyrill Gorcunov
2012-03-08 22:03                 ` Kees Cook
2012-03-08 22:12                   ` Cyrill Gorcunov
2012-03-08 22:14                     ` Kees Cook

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=20120309144239.GD13346@moon \
    --to=gorcunov@openvz.org \
    --cc=akpm@linux-foundation.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.