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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF29AC77B7F for ; Fri, 12 May 2023 19:38:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238810AbjELTiL (ORCPT ); Fri, 12 May 2023 15:38:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48976 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238968AbjELTiC (ORCPT ); Fri, 12 May 2023 15:38:02 -0400 Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F7946EBF for ; Fri, 12 May 2023 12:38:00 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id ada2fe7eead31-434834245c3so3054034137.0 for ; Fri, 12 May 2023 12:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683920279; x=1686512279; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=neEwfvVsPOUWYzBEFFOjFTtscUS7umnZ7KJE32d6STQ=; b=BmfcA40xLKinKwDjn4QGJ3u4urZBu1n+ljB2UvxoVDFkpqVUkFehoMz2bK555rUkGU V3Vky8ry6BgwznjUytxKKD2vIg7W2gtDPYwQSIy/59HY8O+HyJLsA5FJnLeUbE25XV5x w6/dx1N29EzKM7IFQtVMXskYUquZiYJ6lzhV6VrKJGzsEsBmVwYiSHauh7pOFo+Ry2VY KjCCX7NCa4rf00eXuu+wtFeELX9irn//75fGd8QlOpKA5Gi6J2AbZGfmqtlI3EGoD2X3 Ch1ADvklzzGtJnCaBIUPzwKqVJvu2gXkOYFvt1wFkPaTYZW94BQEkrgNaEAWPv7Ihez+ HRlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683920279; x=1686512279; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=neEwfvVsPOUWYzBEFFOjFTtscUS7umnZ7KJE32d6STQ=; b=EkBh471vfvB+qws82MjbgG1vl2fNUN6IjJclPJj8kI1VnHC6UftPoHMiPGgs4t/wxj sbBHNDeAfBofPzK05Yg2fggRCtb5QB6d1ftthLTbUCq6t3rl4/+MKpgciuieOgPTgCOn j7RfxEVJaWEbP2mDMreMq7e/cIKW75m+aB3n+Db+HYKXIAuWFjNkzw8Kjrud8xSaM1t6 GXKc18Jq3mxUqJj78ZzxyBqjk60R1vDfQIFV36siIxDKL6NCo1dOkaNONkzDVyrOLjj1 HDMDcwMA/ZUiHdLeYtkBCff50XASxbDKcgutNNEM1nOG/mvA/OQA0LMEK9ePQKxLP3BV dmrg== X-Gm-Message-State: AC+VfDwuELGkm70vLiRC34KYK90VQ0F6IFdBFKcLopzbSfLjzD/nStmx 3pNE0JUVK9OZxwvNh6oDDhqU6vamo6Cmxu4jeGQ= X-Google-Smtp-Source: ACHHUZ5mkDcmG+mrA+zE5A/42mHIOgSa0jSbGndY9mE1QhvJfhOF7VAe8EgoFpktk0V3uSYo/moFkVZbHGhRURlfOWg= X-Received: by 2002:a67:e205:0:b0:434:5831:f89e with SMTP id g5-20020a67e205000000b004345831f89emr11165802vsa.6.1683920279122; Fri, 12 May 2023 12:37:59 -0700 (PDT) MIME-Version: 1.0 References: <20210125153057.3623715-1-balsini@android.com> <20210125153057.3623715-4-balsini@android.com> In-Reply-To: From: Amir Goldstein Date: Fri, 12 May 2023 15:37:47 -0400 Message-ID: Subject: Re: [PATCH RESEND V12 3/8] fuse: Definitions and ioctl for passthrough To: Miklos Szeredi , Daniel Borkmann Cc: Alessio Balsini , Peng Tao , Akilesh Kailash , Antonio SJ Musumeci , David Anderson , Giuseppe Scrivano , Jann Horn , Jens Axboe , Martijn Coenen , Palmer Dabbelt , Paul Lawrence , Stefano Duo , Zimuzo Ezeozue , wuyan , fuse-devel , kernel-team , "linux-fsdevel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Sep 12, 2022 at 8:29=E2=80=AFAM Amir Goldstein = wrote: > > On Mon, Sep 12, 2022 at 12:29 PM Miklos Szeredi wrote= : > > > > On Sat, 10 Sept 2022 at 10:52, Amir Goldstein wrot= e: > > > > > I think we should accept the fact that just as any current FUSE > > > passthrough (in userspace) implementation is limited to max number of > > > open files as the server's process limitation, kernel passthrough imp= lementation > > > will be limited by inheriting the mounter's process limitation. > > > > > > There is no reason that the server should need to keep more > > > passthrough fd's open than client open fds. > > > > Maybe you're right. > > > > > If we only support FOPEN_PASSTHROUGH_AUTOCLOSE as v12 > > > patches implicitly do, then the memory overhead is not much different > > > than the extra overlayfs pseudo realfiles. > > > > How exactly would this work? > > > > ioctl(F_D_I_P_OPEN) - create passthrough fd with ref 1 > > open/FOPEN_PASSTHOUGH - inc refcount in passthrough fd > > release - put refcount in passthrough fd > > ioctl(F_D_I_P_CLOSE) - put ref in passthrough fd > > > > Due to being refcounted the F_D_I_P_CLOSE can come at any point past > > the finished open request. > > > > Or did you have something else in mind? > > > > What I had in mind is that FOPEN_PASSTHROUGH_AUTOCLOSE > "transfers" the server's refcount to the kernel and server does > not need to call explicit F_D_I_P_CLOSE. > > This is useful for servers that don't care about reusing mappings. > Hi Daniel, I was waiting for LSFMM to see if and how FUSE-BPF intends to address the highest value use case of read/write passthrough. >From what I've seen, you are still taking a very broad approach of all-or-nothing which still has a lot of core design issues to address, while these old patches already address the most important use case of read/write passthrough of fd without any of the core issues (credentials, hidden fds). As far as I can tell, this old implementation is mostly independent of your lookup based approach - they share the low level read/write passthrough functions but not much more than that, so merging them should not be a blocker to your efforts in the longer run. Please correct me if I am wrong. As things stand, I intend to re-post these old patches with mandatory FOPEN_PASSTHROUGH_AUTOCLOSE to eliminate the open questions about managing mappings. Miklos, please stop me if I missed something and if you do not think that these two approaches are independent. Thanks, Amir.