From: Kalesh Singh <kaleshsingh@google.com> To: unlisted-recipients:; (no To-header on input) Cc: ilkos@google.com, tjmercier@google.com, surenb@google.com, kernel-team@android.com, "Kalesh Singh" <kaleshsingh@google.com>, "Jonathan Corbet" <corbet@lwn.net>, "Sumit Semwal" <sumit.semwal@linaro.org>, "Christian König" <christian.koenig@amd.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Johannes Weiner" <hannes@cmpxchg.org>, "David Hildenbrand" <david@redhat.com>, "Christoph Anton Mitterer" <mail@christoph.anton.mitterer.name>, "Mike Rapoport" <rppt@kernel.org>, "Paul Gortmaker" <paul.gortmaker@windriver.com>, "Randy Dunlap" <rdunlap@infradead.org>, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org Subject: [PATCH 0/2] procfs: Add file path and size to /proc/<pid>/fdinfo Date: Tue, 31 May 2022 14:25:13 -0700 [thread overview] Message-ID: <20220531212521.1231133-1-kaleshsingh@google.com> (raw) Processes can pin shared memory by keeping a handle to it through a file descriptor; for instance dmabufs, memfd, and ashmem (in Android). In the case of a memory leak, to identify the process pinning the memory, userspace needs to: - Iterate the /proc/<pid>/fd/* for each process - Do a readlink on each entry to identify the type of memory from the file path. - stat() each entry to get the size of the memory. The file permissions on /proc/<pid>/fd/* only allows for the owner or root to perform the operations above; and so is not suitable for capturing the system-wide state in a production environment. This issue was addressed for dmabufs by making /proc/*/fdinfo/* accessible to a process with PTRACE_MODE_READ_FSCREDS credentials[1] To allow the same kind of tracking for other types of shared memory, add the following fields to /proc/<pid>/fdinfo/<fd>: path - This allows identifying the type of memory based on common prefixes: e.g. "/memfd...", "/dmabuf...", "/dev/ashmem..." This was not an issued when dmabuf tracking was introduced because the exp_name field of dmabuf fdinfo could be used to distinguish dmabuf fds from other types. size - To track the amount of memory that is being pinned. dmabufs expose size as an additional field in fdinfo. Remove this and make it a common field for all fds. Access to /proc/<pid>/fdinfo is governed by PTRACE_MODE_READ_FSCREDS -- the same as for /proc/<pid>/maps which also exposes the path and size for mapped memory regions. This allows for a system process with PTRACE_MODE_READ_FSCREDS to account the pinned per-process memory via fdinfo. ----- There was some concern about exposing the file path in the RFC[2], to that effect the change was split into separte patches. Also retrieving the file path from fdinfo is guarded by the same capability (PTRACE_MODE_READ) as /proc/<pid>/maps which also exposes file path, so this may not be an issue. [1] https://lore.kernel.org/r/20210308170651.919148-1-kaleshsingh@google.com/ [2] https://lore.kernel.org/r/20220519214021.3572840-1-kaleshsingh@google.com/ Kalesh Singh (2): procfs: Add 'size' to /proc/<pid>/fdinfo/ procfs: Add 'path' to /proc/<pid>/fdinfo/ Documentation/filesystems/proc.rst | 22 ++++++++++++++++++++-- drivers/dma-buf/dma-buf.c | 1 - fs/proc/fd.c | 13 +++++++++---- 3 files changed, 29 insertions(+), 7 deletions(-) base-commit: 8ab2afa23bd197df47819a87f0265c0ac95c5b6a -- 2.36.1.255.ge46751e96f-goog
WARNING: multiple messages have this Message-ID (diff)
From: Kalesh Singh <kaleshsingh@google.com> Cc: "Randy Dunlap" <rdunlap@infradead.org>, "Andrew Morton" <akpm@linux-foundation.org>, "Jonathan Corbet" <corbet@lwn.net>, "Christoph Anton Mitterer" <mail@christoph.anton.mitterer.name>, kernel-team@android.com, "Johannes Weiner" <hannes@cmpxchg.org>, ilkos@google.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, "Sumit Semwal" <sumit.semwal@linaro.org>, linaro-mm-sig@lists.linaro.org, "Paul Gortmaker" <paul.gortmaker@windriver.com>, dri-devel@lists.freedesktop.org, "Kalesh Singh" <kaleshsingh@google.com>, linux-fsdevel@vger.kernel.org, "Christian König" <christian.koenig@amd.com>, "David Hildenbrand" <david@redhat.com>, surenb@google.com, tjmercier@google.com, "Mike Rapoport" <rppt@kernel.org>, linux-media@vger.kernel.org Subject: [PATCH 0/2] procfs: Add file path and size to /proc/<pid>/fdinfo Date: Tue, 31 May 2022 14:25:13 -0700 [thread overview] Message-ID: <20220531212521.1231133-1-kaleshsingh@google.com> (raw) Processes can pin shared memory by keeping a handle to it through a file descriptor; for instance dmabufs, memfd, and ashmem (in Android). In the case of a memory leak, to identify the process pinning the memory, userspace needs to: - Iterate the /proc/<pid>/fd/* for each process - Do a readlink on each entry to identify the type of memory from the file path. - stat() each entry to get the size of the memory. The file permissions on /proc/<pid>/fd/* only allows for the owner or root to perform the operations above; and so is not suitable for capturing the system-wide state in a production environment. This issue was addressed for dmabufs by making /proc/*/fdinfo/* accessible to a process with PTRACE_MODE_READ_FSCREDS credentials[1] To allow the same kind of tracking for other types of shared memory, add the following fields to /proc/<pid>/fdinfo/<fd>: path - This allows identifying the type of memory based on common prefixes: e.g. "/memfd...", "/dmabuf...", "/dev/ashmem..." This was not an issued when dmabuf tracking was introduced because the exp_name field of dmabuf fdinfo could be used to distinguish dmabuf fds from other types. size - To track the amount of memory that is being pinned. dmabufs expose size as an additional field in fdinfo. Remove this and make it a common field for all fds. Access to /proc/<pid>/fdinfo is governed by PTRACE_MODE_READ_FSCREDS -- the same as for /proc/<pid>/maps which also exposes the path and size for mapped memory regions. This allows for a system process with PTRACE_MODE_READ_FSCREDS to account the pinned per-process memory via fdinfo. ----- There was some concern about exposing the file path in the RFC[2], to that effect the change was split into separte patches. Also retrieving the file path from fdinfo is guarded by the same capability (PTRACE_MODE_READ) as /proc/<pid>/maps which also exposes file path, so this may not be an issue. [1] https://lore.kernel.org/r/20210308170651.919148-1-kaleshsingh@google.com/ [2] https://lore.kernel.org/r/20220519214021.3572840-1-kaleshsingh@google.com/ Kalesh Singh (2): procfs: Add 'size' to /proc/<pid>/fdinfo/ procfs: Add 'path' to /proc/<pid>/fdinfo/ Documentation/filesystems/proc.rst | 22 ++++++++++++++++++++-- drivers/dma-buf/dma-buf.c | 1 - fs/proc/fd.c | 13 +++++++++---- 3 files changed, 29 insertions(+), 7 deletions(-) base-commit: 8ab2afa23bd197df47819a87f0265c0ac95c5b6a -- 2.36.1.255.ge46751e96f-goog
next reply other threads:[~2022-05-31 21:25 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-31 21:25 Kalesh Singh [this message] 2022-05-31 21:25 ` [PATCH 0/2] procfs: Add file path and size to /proc/<pid>/fdinfo Kalesh Singh 2022-05-31 21:25 ` [PATCH 1/2] procfs: Add 'size' to /proc/<pid>/fdinfo/ Kalesh Singh 2022-05-31 21:25 ` Kalesh Singh 2022-06-01 13:55 ` Christian König 2022-06-01 13:55 ` Christian König 2022-06-01 14:58 ` Kalesh Singh 2022-06-01 14:58 ` Kalesh Singh 2022-05-31 21:25 ` [PATCH 2/2] procfs: Add 'path' " Kalesh Singh 2022-05-31 21:25 ` Kalesh Singh 2022-05-31 22:07 ` Stephen Brennan 2022-05-31 22:07 ` Stephen Brennan 2022-05-31 22:30 ` Kalesh Singh 2022-05-31 22:30 ` Kalesh Singh 2022-05-31 22:48 ` Stephen Brennan 2022-05-31 22:48 ` Stephen Brennan 2022-06-01 15:02 ` [Linaro-mm-sig] " Christian König 2022-06-01 15:02 ` Christian König 2022-06-02 3:31 ` Kalesh Singh 2022-06-02 3:31 ` Kalesh Singh 2022-06-15 17:00 ` Kalesh Singh 2022-06-15 17:00 ` Kalesh Singh 2022-06-21 16:45 ` Kalesh Singh 2022-06-21 16:45 ` Kalesh Singh 2022-06-01 15:40 ` David Laight 2022-06-01 15:40 ` David Laight
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=20220531212521.1231133-1-kaleshsingh@google.com \ --to=kaleshsingh@google.com \ --cc=akpm@linux-foundation.org \ --cc=christian.koenig@amd.com \ --cc=corbet@lwn.net \ --cc=david@redhat.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=hannes@cmpxchg.org \ --cc=ilkos@google.com \ --cc=kernel-team@android.com \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=mail@christoph.anton.mitterer.name \ --cc=paul.gortmaker@windriver.com \ --cc=rdunlap@infradead.org \ --cc=rppt@kernel.org \ --cc=sumit.semwal@linaro.org \ --cc=surenb@google.com \ --cc=tjmercier@google.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: linkBe 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.