From: Christopher Covington <cov@codeaurora.org>
To: linux-mm@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>, Vlastimil Babka <vbabka@suse.cz>,
Hugh Dickins <hughd@google.com>,
Konstantin Khlebnikov <koct9i@gmail.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Robert Foss <robert.foss@collabora.com>,
John Stultz <john.stultz@linaro.org>,
Robert Ho <robert.hu@intel.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
Jerome Marchand <jmarchan@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Kees Cook <keescook@chromium.org>,
Christopher Covington <cov@codeaurora.org>,
Alexey Dobriyan <adobriyan@gmail.com>, Jann Horn <jann@thejh.net>,
Joe Perches <joe@perches.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
"Richard W.M. Jones" <rjones@redhat.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Christopher Covington <cov@codeauora.org>
Subject: [PATCH] procfs: Add mem_end to /proc/<pid>/stat
Date: Fri, 4 Nov 2016 09:14:06 -0400 [thread overview]
Message-ID: <20161104131408.16886-1-cov@codeaurora.org> (raw)
Applications such as Just-In-Time (JIT) compilers, Checkpoint/Restore In
Userspace (CRIU), and User Mode Linux (UML) need to know the highest
virtual address, TASK_SIZE, to implement pointer tagging or make a first
educated guess at where to find a large, unused region of memory.
Unfortunately the currently available mechanisms for determining TASK_SIZE
are either convoluted and potentially error-prone, such as making repeated
munmap() calls and checking the return code, or make use of hard-coded
assumptions that limit an application's portability across kernels with
different Kconfig options and multiple architectures.
Therefore, expose TASK_SIZE to userspace. While PAGE_SIZE is exposed to
userspace via an auxiliary vector, that approach is not used for TASK_SIZE
in case run-time alterations to the usable virtual address range are one
day implemented, such as through an extension to prctl(PR_SET_MM) or a flag
to clone. There is no prctl(PR_GET_MM). Instead such information is
expected to come from /proc/<pid>/stat[m]. For the same extendability
reason, use a per-pid proc entry rather than a system-wide entry like
/proc/sys/vm/mmap_min_addr.
Signed-off-by: Christopher Covington <cov@codeauora.org>
---
Documentation/filesystems/proc.txt | 1 +
fs/proc/array.c | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 74329fd..b9c19cf 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -343,6 +343,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
env_start address above which program environment is placed
env_end address below which program environment is placed
exit_code the thread's exit_code in the form reported by the waitpid system call
+ end_mem address below which all regular program parts are placed (TASK_SIZE)
..............................................................................
The /proc/PID/maps file containing the currently mapped memory regions and
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 9a3ca9e..32b5002 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -561,6 +561,11 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
else
seq_puts(m, " 0");
+ if (mm && permitted)
+ seq_put_decimal_ull(m, " ", mm->task_size);
+ else
+ seq_puts(m, " 0");
+
seq_putc(m, '\n');
if (mm)
mmput(mm);
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
next reply other threads:[~2016-11-04 13:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 13:14 Christopher Covington [this message]
2016-11-04 14:21 ` [PATCH] procfs: Add mem_end to /proc/<pid>/stat Andy Lutomirski
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=20161104131408.16886-1-cov@codeaurora.org \
--to=cov@codeaurora.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=corbet@lwn.net \
--cc=cov@codeauora.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jann@thejh.net \
--cc=jmarchan@redhat.com \
--cc=joe@perches.com \
--cc=john.stultz@linaro.org \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=koct9i@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mhocko@suse.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=rjones@redhat.com \
--cc=robert.foss@collabora.com \
--cc=robert.hu@intel.com \
--cc=ross.zwisler@linux.intel.com \
--cc=vbabka@suse.cz \
/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.