From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1529C3F2D1 for ; Mon, 2 Mar 2020 09:10:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B2358246A1 for ; Mon, 2 Mar 2020 09:10:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=szeredi.hu header.i=@szeredi.hu header.b="cgJULK2b" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726991AbgCBJKD (ORCPT ); Mon, 2 Mar 2020 04:10:03 -0500 Received: from mail-io1-f65.google.com ([209.85.166.65]:44119 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726694AbgCBJKD (ORCPT ); Mon, 2 Mar 2020 04:10:03 -0500 Received: by mail-io1-f65.google.com with SMTP id u17so5707624iog.11 for ; Mon, 02 Mar 2020 01:10:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3FNj0hxzVQQvLDDs/BJ20eFHA24zEIH58cnboIabkr4=; b=cgJULK2b4rwm17h2uu8AA5J4tW6jQKiYhohSPZsFXeZHuiXAEbsaVTRIJHl20Wqgc6 LVswQ/97B4c0lP2Ov1burH1xuh6+bPHa9Zk4VJx/URCFZHihena+raNN4mZB/Yp3sKL0 TgcmsstrZuGDPSwjIdkCnpwG9IZcjry9TNCG4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3FNj0hxzVQQvLDDs/BJ20eFHA24zEIH58cnboIabkr4=; b=FDwKjrFFEifdOKTeXSwtS773r0nGBzBNZ30suuNvQp5hnGJVSFKqQXYvllW9ZpVi1T qZVYXMajUbgFx7uBgHkJjjvJ73fc/ENIquh9cH3KbMmETINwf/j6txFxY0J+BVRsgBCB 3X1DQCnwNljInBYBgZr6JstEiHTzdZvZlSEXeAt9Q+NKQg/kE0mc04Qf9vG7B0m6vdij k1Alt0M7pEi7nQI+kiDIEaSWvcJcbF/xghS/N18hzHc+eDQKDmvSHkWxRo4WBYMWF4v1 OPQuZt2BbE6DuEtgugX2WRINdIntSjjz/lmPUbjX0dq0ViXhVecApEG5kRejucOT3rU2 Ldgg== X-Gm-Message-State: APjAAAX9LI31JvIp81nxlilkEpo02OCuVHJKNSDb4E1jv5KUGAMmyunk SksGPLXHMdtR2CiOHOUGNPj1Uz6Y2K6gTqO27CuoBQ== X-Google-Smtp-Source: APXvYqw24F9lWuP9ZU02aXyoDAyjVcSIObFEA54Qjf0OiC/jHdCOMjILcUuNsjutQKAGboqeMBKUh+6+TbW+K8vw6cY= X-Received: by 2002:a05:6602:382:: with SMTP id f2mr12340952iov.174.1583140202384; Mon, 02 Mar 2020 01:10:02 -0800 (PST) MIME-Version: 1.0 References: <158230810644.2185128.16726948836367716086.stgit@warthog.procyon.org.uk> <1582316494.3376.45.camel@HansenPartnership.com> <1582556135.3384.4.camel@HansenPartnership.com> <1582644535.3361.8.camel@HansenPartnership.com> <20200228155244.k4h4hz3dqhl7q7ks@wittgenstein> <107666.1582907766@warthog.procyon.org.uk> In-Reply-To: <107666.1582907766@warthog.procyon.org.uk> From: Miklos Szeredi Date: Mon, 2 Mar 2020 10:09:51 +0100 Message-ID: Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] To: David Howells Cc: Christian Brauner , James Bottomley , Steven Whitehouse , Miklos Szeredi , viro , Ian Kent , Christian Brauner , Jann Horn , "Darrick J. Wong" , Linux API , linux-fsdevel , lkml , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 28, 2020 at 5:36 PM David Howells wrote: > > sysfs also has some other disadvantages for this: > > (1) There's a potential chicken-and-egg problem in that you have to create a > bunch of files and dirs in sysfs for every created mount and superblock > (possibly excluding special ones like the socket mount) - but this > includes sysfs itself. This might work - provided you create sysfs > first. Sysfs architecture looks something like this (I hope Greg will correct me if I'm wrong): device driver -> kobj tree <- sysfs tree The kobj tree is created by the device driver, and the dentry tree is created on demand from the kobj tree. Lifetime of kobjs is bound to both the sysfs objects and the device but not the other way round. I.e. device can go away while the sysfs object is still being referenced, and sysfs can be freely mounted and unmounted independently of device initialization. So there's no ordering requirement between sysfs mounts and other mounts. I might be wrong on the details, since mounts are created very early in the boot process... > > (2) sysfs is memory intensive. The directory structure has to be backed by > dentries and inodes that linger as long as the referenced object does > (procfs is more efficient in this regard for files that aren't being > accessed) See above: I don't think dentries and inodes are pinned, only kobjs and their associated cruft. Which may be too heavy, depending on the details of the kobj tree. > (3) It gives people extra, indirect ways to pin mount objects and > superblocks. See above. > For the moment, fsinfo() gives you three ways of referring to a filesystem > object: > > (a) Directly by path. A path is always representable by an O_PATH descriptor. > > (b) By path associated with an fd. See my proposal about linking from /proc/$PID/fdmount/$FD -> /sys/devices/virtual/mounts/$MOUNT_ID. > > (c) By mount ID (perm checked by working back up the tree). Check that perm on lookup of /sys/devices/virtual/mounts/$MOUNT_ID. The proc symlink would bypass the lookup check by directly jumping to the mountinfo dir. > but will need to add: > > (d) By fscontext fd (which is hard to find in sysfs). Indeed, the superblock > may not even exist yet. Proc symlink would work for that too. If sysfs is too heavy, this could be proc or a completely new filesystem. The implementation is much less relevant at this stage of the discussion than the interface. Thanks, Miklos