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=-4.0 required=3.0 tests=BAYES_00, 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 F2626C433DF for ; Wed, 12 Aug 2020 16:34:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CE27C2076B for ; Wed, 12 Aug 2020 16:34:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726735AbgHLQeE (ORCPT ); Wed, 12 Aug 2020 12:34:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726600AbgHLQeD (ORCPT ); Wed, 12 Aug 2020 12:34:03 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 258B7C061383; Wed, 12 Aug 2020 09:34:03 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k5thD-00EB4R-36; Wed, 12 Aug 2020 16:33:47 +0000 Date: Wed, 12 Aug 2020 17:33:47 +0100 From: Al Viro To: Miklos Szeredi 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 Subject: Re: file metadata via fs API (was: [GIT PULL] Filesystem Information) Message-ID: <20200812163347.GS1236603@ZenIV.linux.org.uk> References: <20200812143957.GQ1236603@ZenIV.linux.org.uk> <20200812150807.GR1236603@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 05:13:14PM +0200, Miklos Szeredi wrote: > > Lovely. And what of fchdir() to those? > > Not allowed. Not allowed _how_? Existing check is "is it a directory"; what do you propose? IIRC, you've mentioned using readdir() in that context, so it's not that you only allow to open the leaves there. > > > > Is that a flat space, or can they be directories?" > > > > > > Yes it has a directory tree. But you can't mkdir, rename, link, > > > symlink, etc on anything in there. > > > > That kills the "shared inode" part - you'll get deadlocks from > > hell that way. > > No. The shared inode is not for lookup, just for the open file. Bloody hell... So what inodes are you using for lookups? And that thing you would be passing to readdir() - what inode will _that_ have? > > Next: what will that tree be attached to? As in, "what's the parent > > of its root"? And while we are at it, what will be the struct mount > > used with those - same as the original file, something different > > attached to it, something created on the fly for each pathwalk and > > lazy-umounted? And see above re fchdir() - if they can be directories, > > it's very much in the game. > > 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"? Sure, that avoids all questions about dcache interactions - by growing a replacement layer and making just about everything in fs/namei.c, fs/open.c, etc. special-case the handling of that crap. But yes, the syscall-level interface will be simple. Wonderful. I really hope that's not what you have in mind, though.