From patchwork Tue May 31 21:25:13 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kalesh Singh X-Patchwork-Id: 577583 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 322A4C433F5 for ; Tue, 31 May 2022 21:25:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347993AbiEaVZg (ORCPT ); Tue, 31 May 2022 17:25:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347994AbiEaVZc (ORCPT ); Tue, 31 May 2022 17:25:32 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8999A9E9E6 for ; Tue, 31 May 2022 14:25:28 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id i17-20020a259d11000000b0064cd3084085so12992758ybp.9 for ; Tue, 31 May 2022 14:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:message-id:mime-version:subject:from:cc; bh=L5daPTOP8huWXGF9zZZ/YOQgC5+YhUKYKEYEGgJKuXI=; b=ni+vDj4JsvkDI6uQO/dBS970cz6dZc8DyFe2Zer4xTkNxkSHvK+9iWBnPWmPFlu+yM GldK8tXmwDcVnPqD5rTmrw1O/5Fx84SqlvyYy1O+NdSXpTGCmxmOP42PbCZEsmapK/pI LdPWt3eWdMCmmsdUAyhxzJwSk4K/f3XFD8JLMQDfFMKoV7yl3wD7c0YEyQZkVTKpKRls bQIXSiUx6bvVEbfIXw2C31CtGBGyRZKnhhZI0oqDXke/z5Cd5Z5SAktEbZN0415/W9kX oeGofIRzd3K6V4+k9c5ZaCl6y2CNVM4tUzcRZzthBuZX0q0DdV2YxdbJ4DLgGVowVllW //UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:mime-version:subject:from:cc; bh=L5daPTOP8huWXGF9zZZ/YOQgC5+YhUKYKEYEGgJKuXI=; b=Gxc4W4itAvKqv14pTkyxzrd8G4JiUYHlhG0c449ETdMl0IjmOiXC3bqEPELSFMPP3z 2bpGOHdTRqjv2rTqgqp38cdcbVaT6C6WOL92dzUxlpdc3C/wuDJMJ9GqUhL7bDoMZekm 3PFXZQGLD/ka57RLJiUKut+DFJox/Y6oPv15WOLh3XPtkx7gji/SyNMu0M93mAl0kyr8 i+eXAQa8uqDdn6PAA9n4o65RrL3RDb/09pKUE6ePXZ2FItxwXqVnX/OiwYAm4BbNOuO0 VVBv4d0Y56mdSwNB2jwXUbG5FNGuVcXLxwaHzBp+bx206aUTbQj7RCTm5q1Fc19NOnns MnBg== X-Gm-Message-State: AOAM531lO/cmWXSl0Z1FhLjbBcU0G6E8QN/BC+yA+D6umgf+NpPCKEZI zeTX44Q6uLUdS+R1S5bZ1DPh5o81REywkZlczA== X-Google-Smtp-Source: ABdhPJxWIiQFRYynwXQQYY0IBjtnA6j7FHVKcbmfGUIrmeVszzJonKHXPDCnsP8F5SOq9IOCJF3wUkeCrypYAVu4VA== X-Received: from kaleshsingh.mtv.corp.google.com ([2620:15c:211:200:a3c0:2a66:b25c:16df]) (user=kaleshsingh job=sendgmr) by 2002:a25:6588:0:b0:65d:57b9:c470 with SMTP id z130-20020a256588000000b0065d57b9c470mr4071204ybb.142.1654032327734; Tue, 31 May 2022 14:25:27 -0700 (PDT) Date: Tue, 31 May 2022 14:25:13 -0700 Message-Id: <20220531212521.1231133-1-kaleshsingh@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.36.1.255.ge46751e96f-goog Subject: [PATCH 0/2] procfs: Add file path and size to /proc//fdinfo From: Kalesh Singh Cc: ilkos@google.com, tjmercier@google.com, surenb@google.com, kernel-team@android.com, Kalesh Singh , Jonathan Corbet , Sumit Semwal , " =?utf-8?q?Christian_K=C3=B6nig?= " , Andrew Morton , Johannes Weiner , David Hildenbrand , Christoph Anton Mitterer , Mike Rapoport , Paul Gortmaker , Randy Dunlap , 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 To: unlisted-recipients:; (no To-header on input) Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org 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//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//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//fdinfo/: 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//fdinfo is governed by PTRACE_MODE_READ_FSCREDS -- the same as for /proc//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//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//fdinfo/ procfs: Add 'path' to /proc//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