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=-3.8 required=3.0 tests=BAYES_00,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 3DAE9C433E3 for ; Wed, 12 Aug 2020 17:16:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1390920675 for ; Wed, 12 Aug 2020 17:16:55 +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="nAulnfLe" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726503AbgHLRQv (ORCPT ); Wed, 12 Aug 2020 13:16:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726276AbgHLRQu (ORCPT ); Wed, 12 Aug 2020 13:16:50 -0400 Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6792C061383 for ; Wed, 12 Aug 2020 10:16:49 -0700 (PDT) Received: by mail-ed1-x543.google.com with SMTP id ba10so2118294edb.3 for ; Wed, 12 Aug 2020 10:16:49 -0700 (PDT) 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=l2X1UTNYtxtD9AqiCPxyGHdXjAbLFgoKechHodwc0Uo=; b=nAulnfLe5uw3GGbI4m3Tum5zj3laHAl5lzMTlbg9w0RQxUXyfMRVW0PUksH7Rp6ZFN Yq1nSYnweoNegqNGWk3syhijVezp9QgoP5+S2Di2gSfqAOOXVBABYvP7X+VVxFs5wL3L ah3L2fnd4E2PFbne2qLQvAQDr2nPtHrCw32E8= 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=l2X1UTNYtxtD9AqiCPxyGHdXjAbLFgoKechHodwc0Uo=; b=t6m9ZcCRlOMdJxveUfqqa2RYSf1eTTm0GGCWfVpeZd8sZ8dkVvHu7CaHQCpbgc/UP8 eGtW0Wof3WOmKdz2VSy/iilo6hMaPg86LezDi+Z03BptIHP2PRguwTQpXp8Nd59INueP vSwjQ24uFVi0vqHhhcm2iRfoZJX5EOBlRvY8or2Ytq67hmhBPcToe3XFtdtyPvzE40PF 1waMC+1Xz0hq5vn32rO9UmLwziuXt5B0JyZURD0a6thIfAo262pktmOa3meE1Vow6SU4 kmdYNaXn98h4hkXefoIT5+vhnoCqUSdNUM/aQJUDObgycwbqAONITR3GMk7XlLGMTTfs F0PQ== X-Gm-Message-State: AOAM532jJj7OdTnJ/yE4mlLYlHUiWYjUnZ/bup0DzTw+IQMdq3cVbhw6 fhQ8ZGAVT4GMqHwqWga4yje4uExH+Lp6b65rw0JLkw== X-Google-Smtp-Source: ABdhPJxug2NLkyVDrt4SDzElrjaxLcJAHADPULDoz4hIsy0nzQPyH+wfb4erX3M7q+SBR4y2ScqFzLhktBpqx/PV0jA= X-Received: by 2002:a05:6402:12c4:: with SMTP id k4mr905858edx.358.1597252608671; Wed, 12 Aug 2020 10:16:48 -0700 (PDT) MIME-Version: 1.0 References: <20200812143957.GQ1236603@ZenIV.linux.org.uk> <20200812150807.GR1236603@ZenIV.linux.org.uk> <20200812163347.GS1236603@ZenIV.linux.org.uk> In-Reply-To: <20200812163347.GS1236603@ZenIV.linux.org.uk> From: Miklos Szeredi Date: Wed, 12 Aug 2020 19:16:37 +0200 Message-ID: Subject: Re: file metadata via fs API (was: [GIT PULL] Filesystem Information) To: Al Viro Cc: Linus Torvalds , Jann Horn , Casey Schaufler , Andy Lutomirski , linux-fsdevel , David Howells , Karel Zak , Jeff Layton , Miklos Szeredi , Nicolas Dichtel , Christian Brauner , Lennart Poettering , Linux API , Ian Kent , LSM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Aug 12, 2020 at 6:33 PM Al Viro wrote: > > On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Szeredi wrote: > > Why does it have to have a struct mount? It does not have to use > > dentry/mount based path lookup. > > What the fuck? So we suddenly get an additional class of objects > serving as kinda-sorta analogues of dentries *AND* now struct file > might refer to that instead of a dentry/mount pair - all on the VFS > level? And so do all the syscalls you want to allow for such "pathnames"? The only syscall I'd want to allow is open, everything else would be on the open files themselves. file->f_path can refer to an anon mount/inode, the real object is referred to by file->private_data. The change to namei.c would be on the order of ~10 lines. No other parts of the VFS would be affected. Maybe I'm optimistic; we'll see... Now off to something completely different. Back on Tuesday. Thanks, Miklos