Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp144432iob; Tue, 17 May 2022 21:45:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJycjdiuHIGwiifRAiFBqSO8+DYm0cprD+YFy3IJFU5iuakaEhSN1tu2ebpFJQU0he3vib41 X-Received: by 2002:a17:90b:1b03:b0:1dc:a80b:8004 with SMTP id nu3-20020a17090b1b0300b001dca80b8004mr39386272pjb.182.1652849115381; Tue, 17 May 2022 21:45:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652849115; cv=none; d=google.com; s=arc-20160816; b=0uPp+Ek3IffJic4+VnqGI4nhUW4p5QPUBiIAMODKN57W2+6DbTHaXCuu31f2OBXJt5 QmZiFazJpReBKbDIoAyvjwgLAqkVepnWcUrKoVafaRtIka10t0qb7zhCiUNDbzbFr7lh 6/2/vq0Jy1Do9OnDwFL7VA8dbhMGrady4yp8H4xG56SIva3RRzn2IKAUQ+GbdX+bOmjs k77EDa6sRQ3xRXXoiP/1+EV1csTLgFZLOLju5UqluaN4RvMYV3XP49YZOuP+V8giwZRF Ok02dzI7yTbelblh4I24g51L6riqXrlsEjoTFHWQd854ptygteQ6j+/UPmiC+xqYPABd 1T3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=NkGrqohDhl0Ru/z/4CdG6vGOYGQQqFbS8Adgul9ZO6U=; b=lumpKUY7SdcpcnVeQV4Ue4GGjb1xZ2Cc8rxBFtbYMuN2cY2aDr3l8pgczQBGEeSju9 Tojmyg/HER9cUhomrXiBsd6fvM7VXxnFfUBnvAMvBE8t9wXN7DqAkecvytOG3KM+5eJJ VSJruUO6lJLVWWugWIIy80DZNOoQq/cfwIz7mnrvZ+x7bUNXLyfCNjrRvNBMIPGzjVrK G++eE5U9fxOdPDtjs8POcMQBE43mJZ4bBe7bCtPEhjtRAdrO7djgMX72/NAPj6bd7bLX tNUiXZSPPG56mpfJoNpL315Ara+sGsxSGhF297v+ufKsDlApxjgOAkKqYCcHXIrsKxys 1ATw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.org.uk header.s=zeniv-20220401 header.b=Wiru92zK; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zeniv.linux.org.uk Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id r5-20020a17090a4dc500b001df6826cd3asi4948078pjl.52.2022.05.17.21.45.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 May 2022 21:45:15 -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=pass header.i=@linux.org.uk header.s=zeniv-20220401 header.b=Wiru92zK; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zeniv.linux.org.uk Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D830FE7309; Tue, 17 May 2022 20:57:36 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231234AbiEQWct (ORCPT + 99 others); Tue, 17 May 2022 18:32:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230494AbiEQWck (ORCPT ); Tue, 17 May 2022 18:32:40 -0400 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED6B43E5C0; Tue, 17 May 2022 15:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=NkGrqohDhl0Ru/z/4CdG6vGOYGQQqFbS8Adgul9ZO6U=; b=Wiru92zKmLZwC3ibtyjcesi8uW r/gJ+Fyxp3+obMLld0GCOAi2ZW9Y747BjG8+A/Ak32uwni/t/u2JP+qMxfXondYIU5lPWUH9gapzC 92BPGGXQfBre+Lz7UgKlLUQ0AU/UWZEi6wrTkzMhbfrc4SN79Z7ajKaYGFJR+3CC4+2NoDrJ6KEFK BstTjmYOWCmb9BOyX5AKUQvkUs3UPHOEWpL4xkpn5x9ME5S+nxEtcRbaal778TVGIAUUFlbxhpBpo IBUCULp06qp0Ak1+s3BkFtZHH4/gPiTvargskB89ZS0hbe14BOCbeBkczT1haQ9TaIweU6WpaqoTB euS/N5XQ==; Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nr5k6-00Fr1x-GF; Tue, 17 May 2022 22:32:38 +0000 Date: Tue, 17 May 2022 22:32:38 +0000 From: Al Viro To: Daniil Lunev Cc: linux-fsdevel@vger.kernel.org, hch@infradead.org, fuse-devel@lists.sourceforge.net, tytso@mit.edu, miklos@szeredi.hu, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] FUSE: Retire superblock on force unmount Message-ID: References: <20220511222910.635307-1-dlunev@chromium.org> <20220512082832.v2.2.I692165059274c30b59bed56940b54a573ccb46e4@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 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... Note that generic_shutdown_super() is *not* called while superblock is mounted anywhere. And it doesn't get to eviction from the list while it still has live dentries. Or inodes, for that matter. So this if (sb->s_bdi != &noop_backing_dev_info) { if (sb->s_iflags & SB_I_PERSB_BDI) bdi_unregister(sb->s_bdi); bdi_put(sb->s_bdi); sb->s_bdi = &noop_backing_dev_info; } is almost certainly not safe to be done on a live superblock.