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.6 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 BE4A1C433DF for ; Tue, 18 Aug 2020 09:41:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9300820639 for ; Tue, 18 Aug 2020 09:41:47 +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="TKBIZQ9c" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726631AbgHRJlq (ORCPT ); Tue, 18 Aug 2020 05:41:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726370AbgHRJlo (ORCPT ); Tue, 18 Aug 2020 05:41:44 -0400 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF1D7C061342 for ; Tue, 18 Aug 2020 02:41:42 -0700 (PDT) Received: by mail-ej1-x641.google.com with SMTP id qc22so21299484ejb.4 for ; Tue, 18 Aug 2020 02:41:42 -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=Dv1Xhl1bS+5jEQYbFML/aNrkT6FMSIT4YIWLINTkYuA=; b=TKBIZQ9cEM0s7XlAhqk+9WuMaJ5WAzHt28fYx7z2YcY+Ky15uWjPK9XQAlE4GEUNqa mV0SnmJ2Gpom5vx/h8sEIfNfZa5zbCrKs2dnoVh0T89qV+LR7R+5+3MROncxObXPQArg /jnklxkh2Vw4IJ9BkaOQd5d8BqCmxE3VXbUS4= 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=Dv1Xhl1bS+5jEQYbFML/aNrkT6FMSIT4YIWLINTkYuA=; b=fJ5G3rqs6imjtTI2Qe2dubCZlzR9h6Ex26wUqMWLR9ED/GeRrt8DKHAj63pC603UZB 5ynBFG/SJITkkQOx9WUTDLgFNXoBwSUZQMiT86kKr6wTYb/T6BLufRFhvWf9Z/WtJKZZ Y2LYyypuZx4SegGKDnKNz+aEG3guaX4SCduOVeU+Q2t+tBPmd7NA9lx+DzbMT95RslrT TQ8kb5cEH2sqe7OjZiaOTZx9vuNQ6UlPRrdXd1oONTkZ79/bYD2jbH5IB8lRJYNOz7E6 +CQDOLuEE/Qi2+9XNdK3HowiSUR1sDg8Sl7eOwYTjsOoOAzibjDrd/FeZZD05k2qvAMU /58w== X-Gm-Message-State: AOAM531p1ThMKIDgmC01Jn3JCMEULCSdG0Dbkty30C30OHRMJwj3J195 Haju2YQ906n2ABT0mFa68kXUAlUyvklF//6EJA4L6Q== X-Google-Smtp-Source: ABdhPJzt1EdcvKZCvCY2Z46UPxjvinPUBrda1Z9vw7Mvqcsu6bquKdK/yTIXHnA8ZslRVtZfcgEoy+b/s/oUX8tNtng= X-Received: by 2002:a17:907:94ca:: with SMTP id dn10mr19044858ejc.110.1597743701266; Tue, 18 Aug 2020 02:41:41 -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> <20200812173911.GT1236603@ZenIV.linux.org.uk> <20200812183326.GU1236603@ZenIV.linux.org.uk> <20200812213041.GV1236603@ZenIV.linux.org.uk> In-Reply-To: <20200812213041.GV1236603@ZenIV.linux.org.uk> From: Miklos Szeredi Date: Tue, 18 Aug 2020 11:41:29 +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 11:30 PM Al Viro wrote: > > On Wed, Aug 12, 2020 at 07:33:26PM +0100, Al Viro wrote: > > > BTW, what would such opened files look like from /proc/*/fd/* POV? And > > what would happen if you walk _through_ that symlink, with e.g. ".." > > following it? Or with names of those attributes, for that matter... > > What about a normal open() of such a sucker? It won't know where to > > look for your ->private_data... > > > > FWIW, you keep refering to regularity of this stuff from the syscall > > POV, but it looks like you have no real idea of what subset of the > > things available for normal descriptors will be available for those. > > Another question: what should happen with that sucker on umount of > the filesystem holding the underlying object? Should it be counted > as pinning that fs? Obviously yes. > Who controls what's in that tree? It could be several entities: - global (like mount info) - per inode (like xattr) - per fs (fs specific inode attributes) - etc.. > If we plan to have xattrs there, > will they be in a flat tree, or should it mirror the hierarchy of > xattrs? When is it populated? open() time? What happens if we > add/remove an xattr after that point? >From the interface perspective it would be dynamic (i.e. would get updated on open or read). From an implementation POV it could have caching, but that's not how I'd start out. > If we open the same file several times, what should we get? A full > copy of the tree every time, with all coherency being up to whatever's > putting attributes there? > > What are the permissions needed to do lookups in that thing? That would depend on what would need to be looked up. Top level would be world readable, otherwise it would be up to the attribute/group. > > All of that is about semantics and the answers are needed before we > start looking into implementations. "Whatever my implementation > does" is _not_ a good way to go, especially since that'll be cast > in stone as soon as API becomes exposed to userland... Fine. Thanks, Miklos