From: Andrew Morton <akpm@linux-foundation.org>
To: Calvin Owens <calvinowens@fb.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Miklos Szeredi <miklos@szeredi.hu>, Zefan Li <lizefan@huawei.com>,
Oleg Nesterov <oleg@redhat.com>, Joe Perches <joe@perches.com>,
David Howells <dhowells@redhat.com>,
<linux-kernel@vger.kernel.org>, <kernel-team@fb.com>,
Andy Lutomirski <luto@amacapital.net>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Kees Cook <keescook@chromium.org>,
"Kirill A. Shutemov" <kirill@shutemov.name>
Subject: Re: [PATCH v6] procfs: Always expose /proc/<pid>/map_files/ and make it readable
Date: Wed, 10 Jun 2015 13:58:32 -0700 [thread overview]
Message-ID: <20150610135832.af4e8970c45f3a40b64274e0@linux-foundation.org> (raw)
In-Reply-To: <20150610013902.GA176908@mail.thefacebook.com>
On Tue, 9 Jun 2015 18:39:02 -0700 Calvin Owens <calvinowens@fb.com> wrote:
> On Tuesday 06/09 at 14:13 -0700, Andrew Morton wrote:
> > On Mon, 8 Jun 2015 20:39:33 -0700 Calvin Owens <calvinowens@fb.com> wrote:
> >
> > > Currently, /proc/<pid>/map_files/ is restricted to CAP_SYS_ADMIN, and
> > > is only exposed if CONFIG_CHECKPOINT_RESTORE is set.
> > >
> > > This interface very useful because it allows userspace to stat()
> > > deleted files that are still mapped by some process, which enables a
> > > much quicker and more accurate answer to the question "How much disk
> > > space is being consumed by files that are deleted but still mapped?"
> > > than is currently possible.
> >
> > Why is that information useful?
> >
> > I could perhaps think of some use for "How much disk space is being
> > consumed by files that are deleted but still open", but to count the
> > mmapped-then-unlinked files while excluding the opened-then-unlinked
> > files seems damned peculiar.
>
> Let's phrase the question a bit more generically:
>
> "How much disk space is being consumed by files that have been
> unlinked, but are still referenced by some process?"
>
> There are two pieces to this problem:
> 1) Unlinked files that are still open (whether mapped or not)
> 2) Unlinked files that are not open, but are still mapped
>
> You can track down everything in (1) using /proc/<pid>/fd/*, and you
> can use stat() to figure out how much space they're using.
This doesn't work if the mapped file has been unlinked? What does the
/proc/pid/map_files listing look like for these?
> Does that all seem sensible?
Spose so. Please capture all this info in the changelog.
It all seems a bit awkward though. If we want to know "how much disk
space is this process using" (or similar) then I wonder what a syscall
(or prctl mode?) which does this would look like.
next prev parent reply other threads:[~2015-06-10 20:58 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-14 0:20 [RFC][PATCH] procfs: Add /proc/<pid>/mapped_files Calvin Owens
2015-01-14 0:23 ` Calvin Owens
2015-01-14 14:13 ` Rasmus Villemoes
2015-01-14 14:37 ` Siddhesh Poyarekar
2015-01-14 14:53 ` Rasmus Villemoes
2015-01-14 21:03 ` Calvin Owens
2015-01-14 22:45 ` Andrew Morton
2015-01-14 23:51 ` Rasmus Villemoes
2015-01-16 1:15 ` Andrew Morton
2015-01-16 11:00 ` Kirill A. Shutemov
2015-01-14 15:25 ` Kirill A. Shutemov
2015-01-14 15:33 ` Cyrill Gorcunov
2015-01-14 20:46 ` Calvin Owens
2015-01-14 21:16 ` Cyrill Gorcunov
2015-01-22 2:45 ` [RFC][PATCH] procfs: Always expose /proc/<pid>/map_files/ and make it readable Calvin Owens
2015-01-22 7:16 ` Cyrill Gorcunov
2015-01-22 11:02 ` Kirill A. Shutemov
2015-01-22 21:00 ` Calvin Owens
2015-01-22 21:27 ` Kirill A. Shutemov
2015-01-23 5:52 ` Calvin Owens
2015-01-24 3:15 ` [RFC][PATCH v2] " Calvin Owens
2015-01-26 12:47 ` Kirill A. Shutemov
2015-01-26 21:00 ` Cyrill Gorcunov
2015-01-26 23:43 ` Andrew Morton
2015-01-27 0:15 ` Kees Cook
2015-01-27 7:37 ` Cyrill Gorcunov
2015-01-27 19:53 ` Kees Cook
2015-01-27 21:35 ` Cyrill Gorcunov
2015-01-27 21:46 ` Pavel Emelyanov
2015-01-27 0:19 ` Kirill A. Shutemov
2015-01-27 6:46 ` Cyrill Gorcunov
2015-01-27 6:50 ` Andrew Morton
2015-01-27 7:23 ` Cyrill Gorcunov
2015-01-28 4:38 ` Calvin Owens
2015-01-30 1:30 ` Kees Cook
2015-01-31 1:58 ` Calvin Owens
2015-02-02 14:01 ` Austin S Hemmelgarn
2015-02-04 3:53 ` Calvin Owens
2015-02-02 20:16 ` Andy Lutomirski
2015-02-04 3:28 ` Calvin Owens
2015-02-12 2:29 ` [RFC][PATCH v3] " Calvin Owens
2015-02-12 7:45 ` Cyrill Gorcunov
2015-02-14 20:40 ` [RFC][PATCH v4] " Calvin Owens
2015-03-10 22:17 ` Cyrill Gorcunov
2015-04-28 22:23 ` Calvin Owens
2015-04-29 7:32 ` Cyrill Gorcunov
2015-05-19 3:10 ` [PATCH v5] " Calvin Owens
2015-05-19 3:29 ` Joe Perches
2015-05-19 18:04 ` Andy Lutomirski
2015-05-21 1:52 ` Calvin Owens
2015-05-21 2:10 ` Andy Lutomirski
2015-06-09 3:39 ` [PATCH v6] " Calvin Owens
2015-06-09 17:27 ` Kees Cook
2015-06-09 17:47 ` Andy Lutomirski
2015-06-09 18:15 ` Cyrill Gorcunov
2015-06-09 21:13 ` Andrew Morton
2015-06-10 1:39 ` Calvin Owens
2015-06-10 20:58 ` Andrew Morton [this message]
2015-06-11 11:10 ` Alexey Dobriyan
2015-06-11 18:49 ` Andrew Morton
2015-06-12 9:55 ` Alexey Dobriyan
2015-06-19 2:32 ` [PATCH v7] " Calvin Owens
2015-07-15 22:21 ` Andrew Morton
2015-07-15 23:39 ` Calvin Owens
2015-02-14 20:44 ` [PATCH] procfs: Return -ESRCH on /proc/N/fd/* when PID N doesn't exist Calvin Owens
2015-01-14 22:40 ` [RFC][PATCH] procfs: Add /proc/<pid>/mapped_files Kirill A. Shutemov
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=20150610135832.af4e8970c45f3a40b64274e0@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=adobriyan@gmail.com \
--cc=calvinowens@fb.com \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=gorcunov@openvz.org \
--cc=joe@perches.com \
--cc=keescook@chromium.org \
--cc=kernel-team@fb.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=luto@amacapital.net \
--cc=miklos@szeredi.hu \
--cc=oleg@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).