Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp410815iob; Wed, 18 May 2022 05:04:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzHbq9OTpf+YkTI5FAs8p8YXOYmsbKHlCdfYX6aSnZfv0ucsn/WRB7SCPath6HZ1l6v69ty X-Received: by 2002:a05:6a00:ad0:b0:4f7:a357:6899 with SMTP id c16-20020a056a000ad000b004f7a3576899mr27789742pfl.80.1652875459233; Wed, 18 May 2022 05:04:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652875459; cv=none; d=google.com; s=arc-20160816; b=uKDAwPeyImihtWW2nwmz4CwbC0UXl35gnSwQum/GOK/RMQsCKW/00KMv/9KrVZrSYh CUt5SyII8TiyhbtCE3tUAZw7HRbGeiq4b3cbS4DvsP3K8oMc7Qu+dS1GMpXi1odLgYc6 yAYCGHNZt16xWPe7FA+Bcep3c1+lO3H/iQWs4RN4VwP4QEuzhLpBIXm61vT6+J5V10/9 tb6M8eYn9cLQ1QcP38vf7VGEzuKRZg6/RiRgVZtXLiEbUlX22bDlvvzN9wUuQBCjthdo o786vr6fIuNH+oLNZdBloZRqNqUibl3sDsUG6K8a+nHMqhroHVvohWKyIbkw7gTy4M6C E7Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=1AQVLqL8oPCsWqIf0y5cLrjgJaveJU57q/bnqY+Bcwc=; b=ckJntqSgfjt8BToeeF4Wuq1OKSrLBPpaUGnfQV8qYwe8a9obXVfA4iZ44/Rr8HFL6/ FIcE4QqVbuFWe6/E4LTG5yF9QwFlmg5uzkAhKc95L+hBRInIbO65Z7tAJ2G8Yu9Hf1Lt WoB5K7goscSX8cdcoTrNfu96iIugA78FBJo2D1nbYy/jwLVvfFzfd35l1hQhETYNuqdT d4MVQHtT+FLOpUj8Q0hYIEDXR6JIwtC+VuJdtu3jjqJN732vvrX6h74DW16LAGHAmPV4 Ed0PYOSxEdohbVRiviZ1epKJOHIhztdLhojglqxOOeFmgFmyaKUBtQ6mJS6CfPq8f9d7 Irxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=oy5BQ1sP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id z14-20020a63190e000000b003c1f456f0fcsi2102784pgl.879.2022.05.18.05.04.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 05:04:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=oy5BQ1sP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 86D2B377FD; Wed, 18 May 2022 04:58:26 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235878AbiERL6A (ORCPT + 99 others); Wed, 18 May 2022 07:58:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235885AbiERL56 (ORCPT ); Wed, 18 May 2022 07:57:58 -0400 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC3DA24093 for ; Wed, 18 May 2022 04:57:57 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id wh22so3190088ejb.7 for ; Wed, 18 May 2022 04:57:57 -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=1AQVLqL8oPCsWqIf0y5cLrjgJaveJU57q/bnqY+Bcwc=; b=oy5BQ1sPa+NNYI44WvlAhaedelel72TvA+F0iA95vikBTLLK/78vZ+B3nN3vxgrIHZ 1ub3KAZd6byRBhiUxivonltflM0hRYEm7ah6fM1zbSbnT13QLxV7WAzmrOsyn/gkY975 /VQOv6SrG1Dv2Vq0c58Z9F+EMLND4vnSrCvyc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1AQVLqL8oPCsWqIf0y5cLrjgJaveJU57q/bnqY+Bcwc=; b=WlS/vIARezwr+oIYNbGhvVycUw2qNTfYjG2kZGNvx2lg1zTtG6PbsKsYR7ONkVm6wF 7KMz8V2c1/m/Fw/eVs7yB6CF2mALop9qzS08OpTGlNuHl9zfkZPsmckK9uA9gcecYMbO AnRXynYEpsVNkyHealrFxzt880/GS6q21tXuOLCPtK3DfN7FgPlVIsifIOHcI3TQspkb esCGD8Njiujhc31+gbilvsG9RRCB3WTxOFzeBU9nn2aLNpxC2/60f7JbHmXzCJwiIuWk 8Mt6F8KJLIOiBh7vdbsQ/ms1I+RRjLpvOQA/1G/rVB8w/Ulb3+QCPqnmuF4/ySdddt9+ avlQ== X-Gm-Message-State: AOAM532I77qDYI0THf4l/TFIE31jchavUvEwL3Bm91hn4Jg8K1/jFGdX H3M4nIGLaNb3l6Iee6JPONQ3NBNzWCu0c+bcqLqmwA== X-Received: by 2002:a17:907:6e9e:b0:6fe:8d81:b4a3 with SMTP id sh30-20020a1709076e9e00b006fe8d81b4a3mr1443382ejc.748.1652875076330; Wed, 18 May 2022 04:57:56 -0700 (PDT) MIME-Version: 1.0 References: <20220511222910.635307-1-dlunev@chromium.org> <20220512082832.v2.2.I692165059274c30b59bed56940b54a573ccb46e4@changeid> In-Reply-To: From: Miklos Szeredi Date: Wed, 18 May 2022 13:57:45 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] FUSE: Retire superblock on force unmount To: Al Viro Cc: Daniil Lunev , linux-fsdevel@vger.kernel.org, Christoph Hellwig , fuse-devel , "Theodore Ts'o" , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 18 May 2022 at 00:32, Al Viro wrote: > > On Tue, May 17, 2022 at 10:20:06PM +0000, Al Viro wrote: > > On Thu, May 12, 2022 at 08:29:10AM +1000, Daniil Lunev wrote: > > > Force unmount of FUSE severes the connection with the user space, even > > > if there are still open files. Subsequent remount tries to re-use the > > > superblock held by the open files, which is meaningless in the FUSE case > > > after disconnect - reused super block doesn't have userspace counterpart > > > attached to it and is incapable of doing any IO. > > > > Why not simply have those simply rejected by fuse_test_super()? > > Looks like that would be much smaller and less invasive patch... > > Confused... > > ... because Miklos had suggested that, apparently ;-/ I disagree - > that approach has more side effects. "mount will skip that sucker" is, > AFAICS, the only effect of modiyfing test_super callback(s); yours, OTOH... Yep, messing with the bdi doesn't look good. Fuse always uses a private bdi, so it's not even necessary. Just removing from type->fs_supers should not have any side effects, at least I can't spot any. Fixing fuse_test_super() is not sufficient, as the fuseblk type goes though get_tree_bdev(). That could be tweaked as well, but it would end up with more complexity. Thanks, Miklos