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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 95DF4C433DB for ; Fri, 19 Feb 2021 08:41:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2CB6E64EC0 for ; Fri, 19 Feb 2021 08:41:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229712AbhBSIlQ (ORCPT ); Fri, 19 Feb 2021 03:41:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229546AbhBSIlO (ORCPT ); Fri, 19 Feb 2021 03:41:14 -0500 Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B488DC061574 for ; Fri, 19 Feb 2021 00:40:33 -0800 (PST) Received: by mail-ua1-x929.google.com with SMTP id t15so1608056ual.6 for ; Fri, 19 Feb 2021 00:40:33 -0800 (PST) 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=KAX4LYl0kG8JmUeTzz+wEYqEQj0XL2YyaDiep9J2YS8=; b=gd/7FyckxK787QDZNsZVd1QllF5rpLh64V2h2mv5C+8wsia4dfy1uM3w2MoG50n4cI 4N2ZTX8/CsqKCmT5oZnH2SKk8ICiBcJ4a0TyxUth24i6SmxTnVOSzXuUHOlVTkEW1oP2 T6+IHONQVolDO0REMDZI9A2ijbKT/e6jCzD4Q= 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=KAX4LYl0kG8JmUeTzz+wEYqEQj0XL2YyaDiep9J2YS8=; b=GCHirI8fupMPCnsq7uQ3+t+FXwjbjkT5WIfEkkbnOv2wsw9TdWtelzDiSRrwDS/dHr V3W/Dnp0dJEUbJ+UrKEL04Ut4iMk+huGt956lt+8v3rvs3HP4hd1UNookwy/LSVPG+0n aJrfczm9obeN0Qj5RkoC8YFGaTt+UqyfEb+cC3tSM3AAtMUtYCqvRD8Fnva+o8dH6Okj zH7+S4XqWwBp9GpM+DfxFtYNram/SvFsHRMTxM02Qf26qLrM5sKywoCRiqn572Tr4AJY FuUyBoVfOL2ftTXO6b1gCuytfNdjDAZKK5U7O++ZJPidBkHAFczDZHxMnBShP9n6eupt OyIw== X-Gm-Message-State: AOAM530xKU8LeTK8I6VGdMA/Hn/NZiAnGMCM06cqbLpckhdbqw5nXLAY aWk9R6w0IiXlAQxYGfaAzkmOLE1soA/qEswZvOGdvA== X-Google-Smtp-Source: ABdhPJzJH+5GI9QWwC1IyLsbDQuQfFymjQa1dh4IP0OeySwY17q+wAUhAUf8XUPUqrbpG/3gI3rWoc04RvisEarqvio= X-Received: by 2002:ab0:5963:: with SMTP id o32mr6378901uad.11.1613724032852; Fri, 19 Feb 2021 00:40:32 -0800 (PST) MIME-Version: 1.0 References: <20210125153057.3623715-1-balsini@android.com> <20210125153057.3623715-4-balsini@android.com> In-Reply-To: From: Miklos Szeredi Date: Fri, 19 Feb 2021 09:40:21 +0100 Message-ID: Subject: Re: [PATCH RESEND V12 3/8] fuse: Definitions and ioctl for passthrough To: Peng Tao Cc: Alessio Balsini , Akilesh Kailash , Amir Goldstein , 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" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 19, 2021 at 8:05 AM Peng Tao wrote: > > On Wed, Feb 17, 2021 at 9:41 PM Miklos Szeredi wrote: > > What I think would be useful is to have an explicit > > FUSE_DEV_IOC_PASSTHROUGH_CLOSE ioctl, that would need to be called > > once the fuse server no longer needs this ID. If this turns out to > > be a performance problem, we could still add the auto-close behavior > > with an explicit FOPEN_PASSTHROUGH_AUTOCLOSE flag later. > Hi Miklos, > > W/o auto closing, what happens if user space daemon forgets to call > FUSE_DEV_IOC_PASSTHROUGH_CLOSE? Do we keep the ID alive somewhere? Kernel would keep the ID open until explicit close or fuse connection is released. There should be some limit on the max open files referenced through ID's, though. E.g. inherit RLIMIT_NOFILE from mounting task. Thanks, Miklos