All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, keescook@chromium.org,
	tj@kernel.org, avagin@openvz.org, ebiederm@xmission.com,
	hpa@zytor.com, serge.hallyn@canonical.com, xemul@parallels.com,
	segoon@openwall.com, kamezawa.hiroyu@jp.fujitsu.com,
	mtk.manpages@gmail.com, jln@google.com
Subject: Re: [patch 4/4] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation, v3
Date: Sat, 23 Aug 2014 00:38:09 +0400	[thread overview]
Message-ID: <20140822203809.GC25918@moon> (raw)
In-Reply-To: <20140821234912.f007e2fb.akpm@linux-foundation.org>

On Thu, Aug 21, 2014 at 11:49:12PM -0700, Andrew Morton wrote:
> > > 
> > > But it's a bit hacky.  Can anyone think of anything smarter?
> > 
> > Looks good to me and not that hacky actually.
> 
> Hacky :( I guess it's pretty safe because this is a userspace-visible
> structure so we'll never be changing it.

Well, I saw something similar in netfilter code a long ago :)

> 
> Or will we?  What happens if we later decide that some additional field
> needs to be added?  Do we version the interface?  Add a new prctl()
> mode?  Let's cook up a plan for that and at least add to changelog?

I don't expect to change it anytime soon but we still have an option --
if we decide to extend or shrink it we always can use sizeof/offsetof
helpers to check which exactly version userspace asks us to use.
As far as I understand the mm_struct is not the structure which
changes that frequently, right?

> > Should I update on top for -mm tree?
> 
> Spose so.  Let's see what the code savings are when the other two sites
> are similarly changed?
> 
> To save a bit more space offsets[] could be an array of uchar, I guess.
> A BUILD_BUG_ON(sizeof(struct prctl_map) >= 256) would keep that sane.

Sure, thanks!

  reply	other threads:[~2014-08-22 20:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-04 17:22 [patch 0/4] prctl: set-mm -- Rework interface, v3 Cyrill Gorcunov
2014-08-04 17:22 ` [patch 1/4] mm: Introduce check_data_rlimit helper, v2 Cyrill Gorcunov
2014-08-04 20:25   ` Serge E. Hallyn
2014-08-04 17:22 ` [patch 2/4] mm: Use may_adjust_brk helper Cyrill Gorcunov
2014-08-04 20:25   ` Serge E. Hallyn
2014-08-04 17:22 ` [patch 3/4] prctl: PR_SET_MM -- Factor out mmap_sem when update mm::exe_file Cyrill Gorcunov
2014-08-04 20:22   ` Serge E. Hallyn
2014-08-04 17:22 ` [patch 4/4] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation, v3 Cyrill Gorcunov
2014-08-04 21:01   ` Serge E. Hallyn
2014-08-05  8:08   ` Andrew Vagin
2014-08-05  8:12     ` Cyrill Gorcunov
2014-08-21 22:51   ` Andrew Morton
2014-08-22  6:32     ` Cyrill Gorcunov
2014-08-22  6:49       ` Andrew Morton
2014-08-22 20:38         ` Cyrill Gorcunov [this message]
2014-08-22 20:46           ` Andrew Morton
2014-08-22 21:13             ` Cyrill Gorcunov
2014-08-15 19:11 ` [patch 0/4] prctl: set-mm -- Rework interface, v3 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=20140822203809.GC25918@moon \
    --to=gorcunov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jln@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=segoon@openwall.com \
    --cc=serge.hallyn@canonical.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.