Received: by 2002:a05:6359:6284:b0:131:369:b2a3 with SMTP id se4csp5811031rwb; Wed, 9 Aug 2023 09:22:41 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHpql3+awZ6r1LM5HMaVE50KtXVE84rx1Xy/6wKKQaprtDr1O4XBAdyOdH8fx2AcKnanvqO X-Received: by 2002:a54:4894:0:b0:3a3:76c6:a46f with SMTP id r20-20020a544894000000b003a376c6a46fmr3032815oic.38.1691598161148; Wed, 09 Aug 2023 09:22:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691598161; cv=none; d=google.com; s=arc-20160816; b=GJMWjLLMB0wQ3HbzXH9zuSoErfah57EOpAciftbKj1g0dc41IEB938Z7cQws+ajHBZ 4e+ODzjpB3wggFgMfxMoqrQzsD8U3IWFz3KynGzMl726FY3s+29UGfjcSRgj7hcrk+eV kzKvBFef80QREd4efwvKiCd1vgA1quiB5FrIxqYzb6aHYFEt3DvPsKLhlmmPsy31obWR w/VBb9WG+g1BapLsWAKGY1shuzTYuZtKCxU1pRnFIFpnfE6BtF6uwLvEeAs7LpOHudA/ gTPz1ECYRXeGQ4Qv6RqLLQkA70QoB73413SF3544qBaTkTMDGYtSaOdqQ2A6P5aOvRjM ucew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=wdOF3pyO4ik/1un4+3Vp0Nof1tnqsabCXWw0vPjRAGw=; fh=YRj7mLRQ+l5fOG2/fJiTsq/KXlD++8jllVl+Utl36yg=; b=TOGbFdNalMN1TOqaA8T91OchcOZ0NqdEwl+ndUOOb0pbAnVh7Zw/W8U44b5HkdoUSb HlsKBqmWxqSL/o7l/K7tBza19aJo6GmI5gC1G0TKma5yzesDl2w6UqYYQWcFde8vAoR3 yywHQ8Z3DqXexjkjP5m7BYSW1YfZYvqcdB95UAJbfqePPGYh1P2CeKQSWnX/+kdUi+6z AUg1nouhB2Y6/z065anXWS4xt0LS0poxR3EcSVQGUnbhBQ9ZxAZ6ej61aFvG8oZvOT45 xC9am8dzOZ4C4vTnmW6qj/oDJ5RATEggcTdb+YCSg2MoxueIEdoocOo3sAG7FjnrG/g/ A3Zw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=XrynVFtA; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c66-20020a633545000000b00563eda6a8f1si8193407pga.226.2023.08.09.09.22.13; Wed, 09 Aug 2023 09:22:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=XrynVFtA; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233684AbjHIPpf (ORCPT + 99 others); Wed, 9 Aug 2023 11:45:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233975AbjHIPpf (ORCPT ); Wed, 9 Aug 2023 11:45:35 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4573F2139; Wed, 9 Aug 2023 08:45:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D2AEE614DC; Wed, 9 Aug 2023 15:45:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2B11BC433C8; Wed, 9 Aug 2023 15:45:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691595933; bh=xC/U1SwIhXg/9IzHIU+jYILOUKvTiOGIUTdlEC2+11Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XrynVFtAjJdRyGWkjPIGxrEK167oTiS3kpmr3Cm87CEZMlUwz8NZ9QUPHRWlaobMV CjNPw7H+W3X+xUMuS8/5EHVAYrN2yfMUVSiLhO80FD8/okEYh0Vj70HX70d3EW2fqB zyonxdtU0XaKQSoev3dIzv/Iimz1BUOOlqG9Ce6vsrab3Qfby+nYlg2FubP7Pjb/Q9 klksR3ppHNDtU4Kr5C5+fmxsJ0GVW1ajqdjFcVGDsHWqo/QLhBUjvvwbz7hNbgFvsg CstD01lXDIkkmrMgGTabpyVf76AzmfEzAmnZa/Be0cg+g0n1y+0al8ZUKwN1nlDrgM HNKbfE+zQHTIQ== Date: Wed, 9 Aug 2023 08:45:32 -0700 From: "Darrick J. Wong" To: Christoph Hellwig Cc: Al Viro , Christian Brauner , Namjae Jeon , Sungjong Seo , Theodore Ts'o , Andreas Dilger , Konstantin Komarov , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, ntfs3@lists.linux.dev, linux-xfs@vger.kernel.org Subject: Re: [PATCH 06/13] xfs: close the RT and log block devices in xfs_free_buftarg Message-ID: <20230809154532.GT11352@frogsfrogsfrogs> References: <20230808161600.1099516-1-hch@lst.de> <20230808161600.1099516-7-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230808161600.1099516-7-hch@lst.de> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham 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-ext4@vger.kernel.org On Tue, Aug 08, 2023 at 09:15:53AM -0700, Christoph Hellwig wrote: > Closing the block devices logically belongs into xfs_free_buftarg, So instead > of open coding it in the caller move it there and add a check for the s_bdev > so that the main device isn't close as that's done by the VFS helper. > > Signed-off-by: Christoph Hellwig > --- > fs/xfs/xfs_buf.c | 5 +++++ > fs/xfs/xfs_super.c | 12 ++---------- > 2 files changed, 7 insertions(+), 10 deletions(-) > > diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c > index 83b8702030f71d..c57e6e03dfa80c 100644 > --- a/fs/xfs/xfs_buf.c > +++ b/fs/xfs/xfs_buf.c > @@ -1938,6 +1938,8 @@ void > xfs_free_buftarg( > struct xfs_buftarg *btp) > { > + struct block_device *bdev = btp->bt_bdev; > + > unregister_shrinker(&btp->bt_shrinker); > ASSERT(percpu_counter_sum(&btp->bt_io_count) == 0); > percpu_counter_destroy(&btp->bt_io_count); > @@ -1945,6 +1947,9 @@ xfs_free_buftarg( > > blkdev_issue_flush(btp->bt_bdev); > fs_put_dax(btp->bt_daxdev, btp->bt_mount); > + /* the main block device is closed by kill_block_super */ > + if (bdev != btp->bt_mount->m_super->s_bdev) > + blkdev_put(bdev, btp->bt_mount->m_super); Hmm... I feel like this would be cleaner if the data dev buftarg could get its own refcount separate from super_block.s_bdev, but I looked through the code and couldn't identify a simple way to do that. Soo... Reviewed-by: Darrick J. Wong --D > > kmem_free(btp); > } > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index f00d1162815d19..37b1b763a0bef0 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -399,18 +399,10 @@ STATIC void > xfs_close_devices( > struct xfs_mount *mp) > { > - if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) { > - struct block_device *logdev = mp->m_logdev_targp->bt_bdev; > - > + if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) > xfs_free_buftarg(mp->m_logdev_targp); > - blkdev_put(logdev, mp->m_super); > - } > - if (mp->m_rtdev_targp) { > - struct block_device *rtdev = mp->m_rtdev_targp->bt_bdev; > - > + if (mp->m_rtdev_targp) > xfs_free_buftarg(mp->m_rtdev_targp); > - blkdev_put(rtdev, mp->m_super); > - } > xfs_free_buftarg(mp->m_ddev_targp); > } > > -- > 2.39.2 >