From patchwork Thu Apr 25 14:04:10 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bruce Fields X-Patchwork-Id: 10917211 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A32471575 for ; Thu, 25 Apr 2019 14:04:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9629928793 for ; Thu, 25 Apr 2019 14:04:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8A16528B6D; Thu, 25 Apr 2019 14:04:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2426B28793 for ; Thu, 25 Apr 2019 14:04:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729257AbfDYOEd (ORCPT ); Thu, 25 Apr 2019 10:04:33 -0400 Received: from fieldses.org ([173.255.197.46]:50854 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726710AbfDYOEY (ORCPT ); Thu, 25 Apr 2019 10:04:24 -0400 Received: by fieldses.org (Postfix, from userid 2815) id A73321C83; Thu, 25 Apr 2019 10:04:22 -0400 (EDT) From: "J. Bruce Fields" To: linux-nfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, abe@purdue.edu, lsof-l@lists.purdue.edu, util-linux@vger.kernel.org, jlayton@redhat.com, "J. Bruce Fields" Subject: [PATCH 00/10] exposing knfsd opens to userspace Date: Thu, 25 Apr 2019 10:04:10 -0400 Message-Id: <1556201060-7947-1-git-send-email-bfields@redhat.com> X-Mailer: git-send-email 1.8.3.1 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: "J. Bruce Fields" The following patches expose information about NFSv4 opens held by knfsd on behalf of NFSv4 clients. Those are currently invisible to userspace, unlike locks (/proc/locks) and local proccesses' opens (/proc//). The approach is to add a new directory /proc/fs/nfsd/clients/ with subdirectories for each active NFSv4 client. Each subdirectory has an "info" file with some basic information to help identify the client and an "opens" directory that lists the opens held by that client. I got it working by cobbling together some poorly-understood code I found in libfs, rpc_pipefs and elsewhere. If anyone wants to wade in and tell me what I've got wrong, they're more than welcome, but at this stage I'm more curious for feedback on the interface. I'm also cc'ing people responsible for lsof and util-linux in case they have any opinions. Currently these pseudofiles look like: # find /proc/fs/nfsd/clients -type f|xargs tail ==> /proc/fs/nfsd/clients/3741/opens <== 5cc0cd36/6debfb50/00000001/00000001 rw -- fd:10:13649 'open id:\x00\x00\x00&\x00\x00\x00\x00\x00\x00\x0b\xb7\x89%\xfc\xef' 5cc0cd36/6debfb50/00000003/00000001 r- -- fd:10:13650 'open id:\x00\x00\x00&\x00\x00\x00\x00\x00\x00\x0b\xb7\x89%\xfc\xef' ==> /proc/fs/nfsd/clients/3741/info <== clientid: 6debfb505cc0cd36 address: 192.168.122.36:0 name: Linux NFSv4.2 test2.fieldses.org minor version: 2 Each line of the "opens" file is tab-delimited and describes one open, and the fields are stateid, open access bits, deny bits, major:minor:ino, and open owner. So, some random questions: - I just copied the major:minor:ino thing from /proc/locks, I suspect we would have picked something different to identify inodes if /proc/locks were done now. (Mount id and inode? Something else?) - The open owner is just an opaque blob of binary data, but clients may choose to include some useful asci-encoded information, so I'm formatting them as strings with non-ascii stuff escaped. For example, pynfs usually uses the name of the test as the open owner. But as you see above, the ascii content of the Linux client's open owners is less useful. Also, there's no way I know of to map them back to a file description or process or anything else useful on the client, so perhaps they're of limited interest. - I'm not sure about the stateid either. I did think it might be useful just as a unique identifier for each line. (Actually for that it'd be enough to take just the third of those four numbers making up the stateid--maybe that would be better.) In the "info" file, the "name" line is the client identifier/client owner provided by the client, which (like the stateowner) is just opaque binary data, though as you can see here the Linux client is providing a readable ascii string. There's probably a lot more we could add to that info file eventually. Other stuff to add next: - nfsd/clients/#/kill that you can write to to revoke all a client's state if it's wedged somehow. - lists of locks and delegations; lower priority since most of that information is already in /proc/locks. --b. J. Bruce Fields (10): nfsd: persist nfsd filesystem across mounts nfsd: rename cl_refcount nfsd4: use reference count to free client nfsd: add nfsd/clients directory nfsd: make client/ directory names small ints rpc: replace rpc_filelist by tree_descr nfsd4: add a client info file nfsd4: add file to display list of client's opens nfsd: expose some more information about NFSv4 opens nfsd: add more information to client info file fs/nfsd/netns.h | 6 + fs/nfsd/nfs4state.c | 228 ++++++++++++++++++++++++++++++--- fs/nfsd/nfsctl.c | 225 +++++++++++++++++++++++++++++++- fs/nfsd/nfsd.h | 11 ++ fs/nfsd/state.h | 9 +- fs/seq_file.c | 17 +++ include/linux/seq_file.h | 2 + include/linux/string_helpers.h | 1 + lib/string_helpers.c | 5 +- net/sunrpc/rpc_pipe.c | 37 ++---- 10 files changed, 491 insertions(+), 50 deletions(-) Reviewed-by: Jeff Layton