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 5AEA3C433E0 for ; Wed, 12 Aug 2020 17:16:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 300DD22B47 for ; Wed, 12 Aug 2020 17:16:53 +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 S1726577AbgHLRQv (ORCPT ); Wed, 12 Aug 2020 13:16:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726394AbgHLRQu (ORCPT ); Wed, 12 Aug 2020 13:16:50 -0400 Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13D1CC061384 for ; Wed, 12 Aug 2020 10:16:50 -0700 (PDT) Received: by mail-ed1-x542.google.com with SMTP id c10so2105105edk.6 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=S9DjSokYzqTbGeuWewZOd2q2GqzeDNVsBFL67Lgk6nQkAMSJsBuzEIfzf9wHrzf0ja jQ9BvHXPP+BLzsoyc7887i7P/zKntc66y9c42dP31hvxZIrNNhgW7c4PnxuS3ApFwI4u pd3UQObOo1j2Tvo55gUrx75sKaufevCWWurgNorh/H1d4jaMgmrXajxK9qDjBZrJgr/F Vo4ieOvai5aS7fE9nN09EKww7afHBhT4AhkZegCtBlAd5UZ6yUAgxp9DDvdxDo3Bh9ya 4TOYZGkiuiHPuy91WpGOSf1JjcXcoy1ya99LDBBcXciX8oIpCKZGXbE72eqd0b1b+lC3 uG7g== X-Gm-Message-State: AOAM530OOzyoYboVLjMV6AOljsYr8Wx/gBhyGPyvLJbNxzo+b4rBuwQi 8/QifGkFyyhfwtql2AoRH6IpHh/SzSpmLlOAGtLYwQ== 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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