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 2EF66C433E2 for ; Sun, 30 Aug 2020 19:05:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AA85220578 for ; Sun, 30 Aug 2020 19:05: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="PuQMiK2l" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726282AbgH3TFy (ORCPT ); Sun, 30 Aug 2020 15:05:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726178AbgH3TFx (ORCPT ); Sun, 30 Aug 2020 15:05:53 -0400 Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00E46C061573 for ; Sun, 30 Aug 2020 12:05:52 -0700 (PDT) Received: by mail-vs1-xe42.google.com with SMTP id q67so131678vsd.5 for ; Sun, 30 Aug 2020 12:05:52 -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=x7R5Y1+hdW9X8/AT/D4QfTIG13sCo0lYiN0og0zlS0w=; b=PuQMiK2lRKOn7UPl2mHVYdMKUV+3RIjFWpWyx8svsWphZyjl5I64Y55WcmFN5cQmY+ hxfjY/EZeI4hvlsw6KWAqPEKQ703SCsSZShz9rgwROFYCWEzQhljgP/pWSuORu3VYW9W oOHakbryssutHKMbP/rly5DTGTjcPYFBzpY4k= 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=x7R5Y1+hdW9X8/AT/D4QfTIG13sCo0lYiN0og0zlS0w=; b=HyTw77R0IsaBCCKH9pXwD8iq0GnSocXLfkKzGk+uN0EP+D6MQ7jR3EvgawhRlIMe4e LMz26KdfDe822t0ab818MYTe22d1c2FcXLqhDLhsT5CjwHeNi/i83t5KQVkAZV7DSJuu qPomcVsKDIXGkmi8f9yxBUV8FuKDybDU2zrMihkCV7xAU+DlWBoi/6LiX9CdsZ00yxnQ l8KaZXXRHK4V04Oj8J03awfjyuaaQ9PugdX/geb/emc8iQMRgjlbJGVd57GYEP0siy3r 73GcpgMq1KYcVBAt6yRrAOgN2IDgumqBEI9mQ38FMl29S3czSXUbN3qZ87+6BDN/uuoc h24w== X-Gm-Message-State: AOAM5339ojcfIB6zTMQcV98orBT+tG35JJ6p9bv+VbGkXcIbkJFZ5ACL 0q5cdC/BTNzYHLcrJpinAN0YBnMfS+WG+a2P71+8ag== X-Google-Smtp-Source: ABdhPJzQLvLuMmN5wbmEN7npG3SoCLzjZupQv0CWs/e9AcS+5H0TWuuSU73fL9RZeNsWqqXyGzNsLzvJbDvjswhpYxw= X-Received: by 2002:a67:edd8:: with SMTP id e24mr3997806vsp.150.1598814351492; Sun, 30 Aug 2020 12:05:51 -0700 (PDT) MIME-Version: 1.0 References: <20200816225620.GA28218@dread.disaster.area> <20200816230908.GI17456@casper.infradead.org> <20200817002930.GB28218@dread.disaster.area> <20200827152207.GJ14765@casper.infradead.org> <20200827222457.GB12096@dread.disaster.area> <20200829160717.GS14765@casper.infradead.org> <20200829161358.GP1236603@ZenIV.linux.org.uk> <20200829180448.GQ1236603@ZenIV.linux.org.uk> <20200829192522.GS1236603@ZenIV.linux.org.uk> In-Reply-To: <20200829192522.GS1236603@ZenIV.linux.org.uk> From: Miklos Szeredi Date: Sun, 30 Aug 2020 21:05:40 +0200 Message-ID: Subject: Re: xattr names for unprivileged stacking? To: Al Viro Cc: Matthew Wilcox , Dave Chinner , Christian Schoenebeck , "Dr. David Alan Gilbert" , Greg Kurz , linux-fsdevel@vger.kernel.org, Stefan Hajnoczi , Miklos Szeredi , Vivek Goyal , Giuseppe Scrivano , Daniel J Walsh , Chirantan Ekbote 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 Sat, Aug 29, 2020 at 9:25 PM Al Viro wrote: > > On Sat, Aug 29, 2020 at 09:13:24PM +0200, Miklos Szeredi wrote: > > > > d_path() is the least of the problems, actually. Directory tree structure on > > > those, OTOH, is a serious problem. If you want to have getdents(2) on that > > > shite, you want an opened descriptor that looks like a directory. And _that_ > > > opens a large can of worms. Because now you have fchdir(2) to cope with, > > > lookups going through /proc/self/fd//..., etc., etc. > > > > Seriously, nobody wants fchdir(). And getdents() does not imply fchdir(). > > Yes, it does. If it's a directory, fchdir(2) gets to deal with it. > If it's not, no getdents(2). Unless you special-case the damn thing in > said fchdir(2). Huh? f_op->iterate() needed for getdents(2) and i_op->lookup() needed for fchdir(2). Yes, open(..., O_ALT) would be special. Let's call it open_alt(2) to avoid confusion with normal open on a normal filesystem. No special casing anywhere at all. It's a completely new interface that returns a file which either has ->read/write() or ->iterate() and which points to an inode with empty i_ops. Thanks, Miklos