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 EA84FECAAA1 for ; Mon, 12 Sep 2022 09:30:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229633AbiILJaC (ORCPT ); Mon, 12 Sep 2022 05:30:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbiILJaB (ORCPT ); Mon, 12 Sep 2022 05:30:01 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 800C4E0B9 for ; Mon, 12 Sep 2022 02:29:54 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id u9so18760927ejy.5 for ; Mon, 12 Sep 2022 02:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=46+jGyJPnqV30BHK03N0JMAGDfZXj5oRazAZMY1f87I=; b=bpJgBIuHFrzAEbfrmwF4W0uJscuQIM2ByEYMpDwrF6UUK2zPUBrMZFcxP59WlgU6vT m6e6wwgKHzbAvSlL7kFcpudvZZH1w4ju1zKrz/gaLPB+O2ep/aAaPa73AcPiVQi0sR9E QhPticcZO5tOAMNtHFbeOvNth6r0sb3sA+794= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=46+jGyJPnqV30BHK03N0JMAGDfZXj5oRazAZMY1f87I=; b=u/m5ndJvM4grJpqLDdH1PuOt58OS3btVQnErCF6bl5gyngyhXex8j4eKI4+moxeZ3n oRNtYqdxBkqYqbdFCGJREwyyg59XbOyr1Vy3785sYHNRDzrJfm7JjxfJ9B7G8OcEZ4zE gv2Q0gZMe4iqHEBKBBltpi+Duj9sy7A3GjAlwTaERg2a1gp6zKCeCJ3ApvcYs5PANmqv lCIaLhgB9yvqWpzPJ0cpk1HdJC3PrSPLrnTXzsbeUMMz67LQ8PJGWrkG6l16To7iQtJm jsz0tQ0hiLQV5yBptGTDVVUi1sXk7S1GR5nh69c2n1NfvVJCs9PCbB5aBrGonX3mD9sU VdEA== X-Gm-Message-State: ACgBeo3M05DpZ8C+7ADEx33SB6f477pwNwSbdY/YstLXIdqNtyV9o6fB NSdHH8gh0YDrHnRoQiujMheqqt/8hRAkf5guS70rQA== X-Google-Smtp-Source: AA6agR4csRvJsoipDTpL92jm117+j7gacvMXLZ1PwI3rgdZPZ4weDaNAYWJDMZe3FKniLKVOfIPBXHNvwHNnX0t3VU0= X-Received: by 2002:a17:907:7f0b:b0:731:b81a:1912 with SMTP id qf11-20020a1709077f0b00b00731b81a1912mr18271357ejc.8.1662974992623; Mon, 12 Sep 2022 02:29:52 -0700 (PDT) MIME-Version: 1.0 References: <20210125153057.3623715-1-balsini@android.com> <20210125153057.3623715-4-balsini@android.com> In-Reply-To: From: Miklos Szeredi Date: Mon, 12 Sep 2022 11:29:41 +0200 Message-ID: Subject: Re: [PATCH RESEND V12 3/8] fuse: Definitions and ioctl for passthrough To: Amir Goldstein 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" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Sat, 10 Sept 2022 at 10:52, Amir Goldstein wrote: > 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 implementation > 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? > > One other question that's nagging me is how to "unhide" these pseudo-fds. > > > > Could we create a kernel thread for each fuse sb which has normal > > file-table for these? This would would allow inspecting state through > > /proc/$KTHREDID/fd, etc.. > > > > Yeah that sounds like a good idea. > As I mentioned elsewhere in the thread, io_uring also has a mechanism > to register open files with the kernel to perform IO on them later. > I assume those files are also visible via some /proc/$KTHREDID/fd, > but I'll need to check. > > BTW, I see that the Android team is presenting eBPF-FUSE on LPC > coming Tuesday [1]. At first glance it looks like a filtered kernel-only passthrough + fuse fallback, where filtering is provided by eBPF scripts and only falls back to userspace access on more complex cases. Maybe it's a good direction, we'll see. Apparently the passthrough case is important enough for various use cases. Miklos