Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp6070198ioo; Wed, 1 Jun 2022 20:33:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtoe5nh94L48AeNFDfSxUCQCmdV2Nu0C13oveWWQFitRYinhFNN2D+18aCcEGMwRkepeVw X-Received: by 2002:a17:902:7c13:b0:156:ca91:877f with SMTP id x19-20020a1709027c1300b00156ca91877fmr2668559pll.15.1654140796919; Wed, 01 Jun 2022 20:33:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654140796; cv=none; d=google.com; s=arc-20160816; b=B5NZVsx+gcwdbR8LUEOHtVqlrGBILnliAVKJOWsPAyek72m5Wv1nGLQI4fFd/imwvs xUhH2yx3jzxVhGpzgGjmQey36F2eSchQx2yyarLSFRLyNa3cTozi3jWBxvMTMo/YH0si Fc+lvKTdhNky7wdA3dkFF2j6b2TYELEXxC/BOtJ+SmQ9IqdWw0lHZFlX6P5TsjMlEht0 dnXxUHOt52Q/kISYqmMQhmGS2LVRiTRX0MqFFlTeAx8hzlP5RPM0W9qUQ1O10MhxLmGe 1IMwEb1gqUOzQ+iL+YOofqjwsQu1ROIW+FDfv3yOjAG3p25GuFL6TjtT4Mu8YCqYkeQb yQ2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=NtKZM7ZzL0kZiBk9fCkTs8IIiGvurk+lCaFLvy6F9KM=; b=ZmxE86oXf0JiLEmxe/55T9ojpsTsM2y48pcAsyyNggxE7AlQsZtz9/M1S2bjqePLWa 2ZIrcUvJco28izvnRND0SueyR8k8oVnUwtvuC61h1R97dL5CzJCys7f7MUGYpEsGpOUX BlBCCBhZdcgWtuybEXCoLukR6TNYtTokE++UTL/xzyUpygQPmKNc7C4T7x58OGDutXFG kcD5C21OAKl//lknqBXMp3IrAz1lEh0y0ZZ4s6x8Y5u/Lyf70s0fFxFy70UNfZB+4qc6 Kn0zWRXVz1Uaj6S+Q1M+sPahHDoZ1gfi45zkZBDles+MSTCkmiKm83t9m6w8p87zQ6j0 KC7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=raUrDavq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id q18-20020a056a00151200b00518827f712asi5404082pfu.353.2022.06.01.20.33.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 20:33:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=raUrDavq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 68E0F2B07FB; Wed, 1 Jun 2022 20:31:34 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233609AbiFBDbW (ORCPT + 99 others); Wed, 1 Jun 2022 23:31:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42452 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233578AbiFBDbU (ORCPT ); Wed, 1 Jun 2022 23:31:20 -0400 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5566F2789B6 for ; Wed, 1 Jun 2022 20:31:18 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id o9so1946285wmd.0 for ; Wed, 01 Jun 2022 20:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NtKZM7ZzL0kZiBk9fCkTs8IIiGvurk+lCaFLvy6F9KM=; b=raUrDavqbUtfHUyTsuvpI3JJKenCcbQI1C91oKXMoIo0hS6fi+YXCZvOeeg2MEQNX1 dJ6bd3Ce4GTPVs0QEn79KZs2VPt6QKmzQP0Nwiu/KPgJO8R4RFx7GRPptekvllGm36QP H1pTmzWRB1hHlS2eYOLCpjjFjyKzuVbWEWizG0E7Rh1GH62aQKt6rMy5q1V0iSdjlXRg oTlWVwC1Vm733kv5iBJpVdPKqQ7NyLd0YOcyeLw1ZfsP2dkqPLzYSAtFTezRtt9x1fyy WIXyado7VheTdhisXzaAk8sUkFbrRcuVKr0JJs9M+ijZAS3yhpw2MvnhzE+WK3dWox07 Y6Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NtKZM7ZzL0kZiBk9fCkTs8IIiGvurk+lCaFLvy6F9KM=; b=pJ6c1basqDCiGJ4MLZi4L2iL8v7Z6b1iZz1vO2OXTRb6SqibXxXcBLYcfXKWxw/Kxr 3JUf5XKElDr5ggEX5N1+5tOMW4MvBlP9/M4kkuW4WaeJ4wuP/oXFrtJ2//M5L+Er82/0 E7ITIyRe7S0gzpoTQI+hckfKXLVsTvKr29esRA+qu3hahtpQq4mXyVxxAn55vQQ1dxqD zRY/j6ljBEfWeqUhL6BiBPrgms6jUeF+KnkiUsosIQXaVG+9kwquc7aQJ2bDZsi03vfN vyHiVxi5Mb6gx7IdiZFHCupcSbSzk9/moNpXbni3yc9A10iYmxb+CFfMSFU2r+XAs+DE KhKA== X-Gm-Message-State: AOAM532eD+lkFEbQ/RNE+lAxu/I0In/eXDxnH4su8/eaJwI6JSO/vowS YUo6tzZHdMkM0nsnmAa9GI8zaalRx7+/KWY37VV0cA== X-Received: by 2002:a05:600c:3547:b0:39c:1606:17c5 with SMTP id i7-20020a05600c354700b0039c160617c5mr2125479wmq.61.1654140676586; Wed, 01 Jun 2022 20:31:16 -0700 (PDT) MIME-Version: 1.0 References: <20220531212521.1231133-1-kaleshsingh@google.com> <20220531212521.1231133-3-kaleshsingh@google.com> <14f85d24-a9de-9706-32f0-30be4999c71c@oracle.com> <875yll1fp1.fsf@stepbren-lnx.us.oracle.com> <4b79c2ea-dd1a-623d-e5b4-faa732c1a42d@gmail.com> In-Reply-To: <4b79c2ea-dd1a-623d-e5b4-faa732c1a42d@gmail.com> From: Kalesh Singh Date: Wed, 1 Jun 2022 20:31:05 -0700 Message-ID: Subject: Re: [Linaro-mm-sig] Re: [PATCH 2/2] procfs: Add 'path' to /proc//fdinfo/ To: =?UTF-8?Q?Christian_K=C3=B6nig?= , Alexander Viro Cc: Stephen Brennan , Ioannis Ilkos , "T.J. Mercier" , Suren Baghdasaryan , "Cc: Android Kernel" , Jonathan Corbet , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , Andrew Morton , David Hildenbrand , Christoph Anton Mitterer , Johannes Weiner , Colin Cross , Mike Rapoport , Paul Gortmaker , Randy Dunlap , LKML , linux-fsdevel , "open list:DOCUMENTATION" , Linux Media Mailing List , DRI mailing list , "moderated list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 1, 2022 at 8:02 AM Christian K=C3=B6nig wrote: > > Am 01.06.22 um 00:48 schrieb Stephen Brennan: > > Kalesh Singh writes: > >> On Tue, May 31, 2022 at 3:07 PM Stephen Brennan > >> wrote: > >>> On 5/31/22 14:25, Kalesh Singh wrote: > >>>> In order to identify the type of memory a process has pinned through > >>>> its open fds, add the file path to fdinfo output. This allows > >>>> identifying memory types based on common prefixes. e.g. "/memfd...", > >>>> "/dmabuf...", "/dev/ashmem...". > >>>> > >>>> Access to /proc//fdinfo is governed by PTRACE_MODE_READ_FSCREDS > >>>> the same as /proc//maps which also exposes the file path of > >>>> mappings; so the security permissions for accessing path is consiste= nt > >>>> with that of /proc//maps. > >>> Hi Kalesh, > >> Hi Stephen, > >> > >> Thanks for taking a look. > >> > >>> I think I see the value in the size field, but I'm curious about path= , > >>> which is available via readlink /proc//fd/, since those are > >>> symlinks to the file themselves. > >> This could work if we are root, but the file permissions wouldn't > >> allow us to do the readlink on other processes otherwise. We want to > >> be able to capture the system state in production environments from > >> some trusted process with ptrace read capability. > > Interesting, thanks for explaining. It seems weird to have a duplicate > > interface for the same information but such is life. > > Yeah, the size change is really straight forward but for this one I'm > not 100% sure either. The 2 concerns I think are: 1. Fun characters in the path names 2. If exposing the path is appropriate to begin with. One way I think we can address both is to only expose the path for anon inodes. Then we have well-known path formats and we don't expose much about which files a process is accessing since these aren't real paths. + if (is_anon_inode(inode)) { + seq_puts(m, "path:\t"); + seq_file_path(m, file, "\n"); + seq_putc(m, '\n'); + } Interested to hear thoughts on it. > > Probably best to ping some core fs developer before going further with it= . linux-fsdevel is cc'd here. Adding Al Vrio as well. Please let me know if there are other parties I should include. > > BTW: Any preferred branch to push this upstream? If not I can take it > through drm-misc-next. No other dependencies for this, so drm-misc-next is good. Thanks, Kalesh > > Regards, > Christian. > > > > >>> File paths can contain fun characters like newlines or colons, which > >>> could make parsing out filenames in this text file... fun. How would = your > >>> userspace parsing logic handle "/home/stephen/filename\nsize:\t4096"?= The > >>> readlink(2) API makes that easy already. > >> I think since we have escaped the "\n" (seq_file_path(m, file, "\n")), > > I really should have read through that function before commenting, > > thanks for teaching me something new :) > > > > Stephen > > > >> then user space might parse this line like: > >> > >> if (strncmp(line, "path:\t", 6) =3D=3D 0) > >> char* path =3D line + 6; > >> > >> > >> Thanks, > >> Kalesh > >> > >>> Is the goal avoiding races (e.g. file descriptor 3 is closed and reop= ened > >>> to a different path between reading fdinfo and stating the fd)? > >>> > >>> Stephen > >>> > >>>> Signed-off-by: Kalesh Singh > >>>> --- > >>>> > >>>> Changes from rfc: > >>>> - Split adding 'size' and 'path' into a separate patches, per Chr= istian > >>>> - Fix indentation (use tabs) in documentaion, per Randy > >>>> > >>>> Documentation/filesystems/proc.rst | 14 ++++++++++++-- > >>>> fs/proc/fd.c | 4 ++++ > >>>> 2 files changed, 16 insertions(+), 2 deletions(-) > >>>> > >>>> diff --git a/Documentation/filesystems/proc.rst b/Documentation/file= systems/proc.rst > >>>> index 779c05528e87..591f12d30d97 100644 > >>>> --- a/Documentation/filesystems/proc.rst > >>>> +++ b/Documentation/filesystems/proc.rst > >>>> @@ -1886,14 +1886,16 @@ if precise results are needed. > >>>> 3.8 /proc//fdinfo/ - Information about opened file > >>>> --------------------------------------------------------------- > >>>> This file provides information associated with an opened file. The= regular > >>>> -files have at least five fields -- 'pos', 'flags', 'mnt_id', 'ino',= and 'size'. > >>>> +files have at least six fields -- 'pos', 'flags', 'mnt_id', 'ino', = 'size', > >>>> +and 'path'. > >>>> > >>>> The 'pos' represents the current offset of the opened file in deci= mal > >>>> form [see lseek(2) for details], 'flags' denotes the octal O_xxx m= ask the > >>>> file has been created with [see open(2) for details] and 'mnt_id' = represents > >>>> mount ID of the file system containing the opened file [see 3.5 > >>>> /proc//mountinfo for details]. 'ino' represents the inode num= ber of > >>>> -the file, and 'size' represents the size of the file in bytes. > >>>> +the file, 'size' represents the size of the file in bytes, and 'pat= h' > >>>> +represents the file path. > >>>> > >>>> A typical output is:: > >>>> > >>>> @@ -1902,6 +1904,7 @@ A typical output is:: > >>>> mnt_id: 19 > >>>> ino: 63107 > >>>> size: 0 > >>>> + path: /dev/null > >>>> > >>>> All locks associated with a file descriptor are shown in its fdinf= o too:: > >>>> > >>>> @@ -1920,6 +1923,7 @@ Eventfd files > >>>> mnt_id: 9 > >>>> ino: 63107 > >>>> size: 0 > >>>> + path: anon_inode:[eventfd] > >>>> eventfd-count: 5a > >>>> > >>>> where 'eventfd-count' is hex value of a counter. > >>>> @@ -1934,6 +1938,7 @@ Signalfd files > >>>> mnt_id: 9 > >>>> ino: 63107 > >>>> size: 0 > >>>> + path: anon_inode:[signalfd] > >>>> sigmask: 0000000000000200 > >>>> > >>>> where 'sigmask' is hex value of the signal mask associated > >>>> @@ -1949,6 +1954,7 @@ Epoll files > >>>> mnt_id: 9 > >>>> ino: 63107 > >>>> size: 0 > >>>> + path: anon_inode:[eventpoll] > >>>> tfd: 5 events: 1d data: ffffffffffffffff pos:0 i= no:61af sdev:7 > >>>> > >>>> where 'tfd' is a target file descriptor number in decimal form, > >>>> @@ -1968,6 +1974,7 @@ For inotify files the format is the following:= : > >>>> mnt_id: 9 > >>>> ino: 63107 > >>>> size: 0 > >>>> + path: anon_inode:inotify > >>>> inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0= fhandle-bytes:8 fhandle-type:1 f_handle:7e9e0000640d1b6d > >>>> > >>>> where 'wd' is a watch descriptor in decimal form, i.e. a target fi= le > >>>> @@ -1992,6 +1999,7 @@ For fanotify files the format is:: > >>>> mnt_id: 9 > >>>> ino: 63107 > >>>> size: 0 > >>>> + path: anon_inode:[fanotify] > >>>> fanotify flags:10 event-flags:0 > >>>> fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003 > >>>> fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:= 40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4 > >>>> @@ -2018,6 +2026,7 @@ Timerfd files > >>>> mnt_id: 9 > >>>> ino: 63107 > >>>> size: 0 > >>>> + path: anon_inode:[timerfd] > >>>> clockid: 0 > >>>> ticks: 0 > >>>> settime flags: 01 > >>>> @@ -2042,6 +2051,7 @@ DMA Buffer files > >>>> mnt_id: 9 > >>>> ino: 63107 > >>>> size: 32768 > >>>> + path: /dmabuf: > >>>> count: 2 > >>>> exp_name: system-heap > >>>> > >>>> diff --git a/fs/proc/fd.c b/fs/proc/fd.c > >>>> index 464bc3f55759..8889a8ba09d4 100644 > >>>> --- a/fs/proc/fd.c > >>>> +++ b/fs/proc/fd.c > >>>> @@ -60,6 +60,10 @@ static int seq_show(struct seq_file *m, void *v) > >>>> seq_printf(m, "ino:\t%lu\n", file_inode(file)->i_ino); > >>>> seq_printf(m, "size:\t%lli\n", (long long)file_inode(file)->i= _size); > >>>> > >>>> + seq_puts(m, "path:\t"); > >>>> + seq_file_path(m, file, "\n"); > >>>> + seq_putc(m, '\n'); > >>>> + > >>>> /* show_fd_locks() never deferences files so a stale value is= safe */ > >>>> show_fd_locks(m, file, files); > >>>> if (seq_has_overflowed(m)) > >>> -- > >>> To unsubscribe from this group and stop receiving emails from it, sen= d an email to kernel-team+unsubscribe@android.com. > >>> > > _______________________________________________ > > Linaro-mm-sig mailing list -- linaro-mm-sig@lists.linaro.org > > To unsubscribe send an email to linaro-mm-sig-leave@lists.linaro.org >