From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andrew Vagin <avagin@openvz.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
Pavel Emelyanov <xemul@parallels.com>,
Vasiliy Kulikov <segoon@openwall.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Michael Kerrisk-manpages <mtk.manpages@gmail.com>,
Julien Tinnes <jln@google.com>
Subject: Re: [rfc 1/4] mm: Introduce may_adjust_brk helper
Date: Thu, 24 Jul 2014 23:21:52 +0400 [thread overview]
Message-ID: <20140724192152.GC17876@moon> (raw)
In-Reply-To: <CAGXu5j+QHcrYjT8F9TZLA8YbJzZed28scp2y22QNO20sRF8Ndw@mail.gmail.com>
On Thu, Jul 24, 2014 at 12:18:56PM -0700, Kees Cook wrote:
> >
> > +static inline int may_adjust_brk(unsigned long rlim,
> > + unsigned long new_brk,
> > + unsigned long start_brk,
> > + unsigned long end_data,
> > + unsigned long start_data)
> > +{
> > + if (rlim < RLIMIT_DATA) {
>
> Won't rlim always be the value from a call to rlimit(RLIMIT_DATA)? Is
> there a good reason to not just put the rlimit() call in
> may_adjust_brk()? This would actually be an optimization in the
> prctl_set_mm case, since now it calls rlimit() unconditionally, but
> doesn't need to.
Nope, we use it for rlimit(RLIMIT_STACK) when checking for
@start_stack member.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andrew Vagin <avagin@openvz.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
Pavel Emelyanov <xemul@parallels.com>,
Vasiliy Kulikov <segoon@openwall.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Michael Kerrisk-manpages <mtk.manpages@gmail.com>,
Julien Tinnes <jln@google.com>
Subject: Re: [rfc 1/4] mm: Introduce may_adjust_brk helper
Date: Thu, 24 Jul 2014 23:21:52 +0400 [thread overview]
Message-ID: <20140724192152.GC17876@moon> (raw)
In-Reply-To: <CAGXu5j+QHcrYjT8F9TZLA8YbJzZed28scp2y22QNO20sRF8Ndw@mail.gmail.com>
On Thu, Jul 24, 2014 at 12:18:56PM -0700, Kees Cook wrote:
> >
> > +static inline int may_adjust_brk(unsigned long rlim,
> > + unsigned long new_brk,
> > + unsigned long start_brk,
> > + unsigned long end_data,
> > + unsigned long start_data)
> > +{
> > + if (rlim < RLIMIT_DATA) {
>
> Won't rlim always be the value from a call to rlimit(RLIMIT_DATA)? Is
> there a good reason to not just put the rlimit() call in
> may_adjust_brk()? This would actually be an optimization in the
> prctl_set_mm case, since now it calls rlimit() unconditionally, but
> doesn't need to.
Nope, we use it for rlimit(RLIMIT_STACK) when checking for
@start_stack member.
next prev parent reply other threads:[~2014-07-24 19:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-24 16:46 [rfc 0/4] prctl: set-mm -- Rework interface, v2 Cyrill Gorcunov
2014-07-24 16:46 ` Cyrill Gorcunov
2014-07-24 16:46 ` [rfc 1/4] mm: Introduce may_adjust_brk helper Cyrill Gorcunov
2014-07-24 16:46 ` Cyrill Gorcunov
2014-07-24 19:18 ` Kees Cook
2014-07-24 19:18 ` Kees Cook
2014-07-24 19:21 ` Cyrill Gorcunov [this message]
2014-07-24 19:21 ` Cyrill Gorcunov
2014-07-24 19:32 ` Serge Hallyn
2014-07-24 19:32 ` Serge Hallyn
2014-07-24 19:46 ` Cyrill Gorcunov
2014-07-24 19:46 ` Cyrill Gorcunov
2014-07-24 16:46 ` [rfc 2/4] mm: Use " Cyrill Gorcunov
2014-07-24 16:46 ` Cyrill Gorcunov
2014-07-24 16:47 ` [rfc 3/4] prctl: PR_SET_MM -- Factor out mmap_sem when update mm::exe_file Cyrill Gorcunov
2014-07-24 16:47 ` Cyrill Gorcunov
2014-07-24 16:47 ` [rfc 4/4] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation, v3 Cyrill Gorcunov
2014-07-24 16:47 ` Cyrill Gorcunov
2014-07-24 19:31 ` Kees Cook
2014-07-24 19:31 ` Kees Cook
2014-07-24 19:44 ` Cyrill Gorcunov
2014-07-24 19:44 ` 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=20140724192152.GC17876@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=linux-mm@kvack.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.