Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4408289ioa; Wed, 27 Apr 2022 03:15:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1WZAmNIUQSIeMcVOnRseXKFjnJJPI6mgDhsH4yEjRJrSyB1fpa2hBO9h19EcAMpm3rxnI X-Received: by 2002:a17:902:9692:b0:15d:1968:8d47 with SMTP id n18-20020a170902969200b0015d19688d47mr14219972plp.58.1651054506964; Wed, 27 Apr 2022 03:15:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651054506; cv=none; d=google.com; s=arc-20160816; b=OH+o3FuhJsjFqLnz1lB9ipFH0AIoQChSRGEvYINWiljih4YyFiRhy6ujGYhuS1agan QkJm4hRPK563cEtswYSyiB94C1YP4H7xBUnMGbAtZ9P7VG5zBtGwp1x02eKKtC96NgIV xAHFKWcQdrqWUU5ckqb0hGujU2LHLQ1MuT6u2lPqznVz0Q3FfC1hdk/LeTnEneRyv7uS 2sq58N/4fC6YgzF6wbpwK4p6l9NdgfR4/3GqQtaW//QWRJVv2Bk9OGmZrVTMyjMCRtIA rQV9bd0XROjCIPyfUQ4HjV6RJUpup1t+ZhLCECSyfGDcA2F4F8MB4zklx1c+jQKtJSpC ODJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=afheC5KZBBRfXsbBXeNCI66O1qmc02KTyCmAOgMc74o=; b=os/wZn692RUTZGRkxD2WJf/8+qEvOKSF8eRLH1syrH4K/1F4HUm5Da4/B0zVC6hubW 2zYxzhEw9CN91m6C9eSqeK/u+jt5tfiCIPOIqF4K+vEVp9qHWENf5apCZcOyKSrY/yCv B4RKIIm2RddsWB1wXvYKVbck9XaIRTOX5pqzddZGyn/eCR4a3Md2Hb7ZGubvlvBlANyp 5KdO+v5vEhU+mSvl+hz6NWEaRwylN+vKyrs2wjHd6hfcu3BALNw82gtPx1/Rd2ALYkGK LOURUIxlV4nXk8+w5QkH23gBLhDiCckQZsVVqgZ+cQj26fdtnm2HNMGUi0xcjhqfAIhY CUHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=il94r3FZ; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id b8-20020a056a00114800b0050d67ef8296si1016117pfm.370.2022.04.27.03.15.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 03:15:06 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=il94r3FZ; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 788A132D2DD; Wed, 27 Apr 2022 02:36:12 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346476AbiDZJAl (ORCPT + 99 others); Tue, 26 Apr 2022 05:00:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346886AbiDZIp2 (ORCPT ); Tue, 26 Apr 2022 04:45:28 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4928C3CA6C; Tue, 26 Apr 2022 01:36:11 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id F1C02B81D09; Tue, 26 Apr 2022 08:36:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A861C385A0; Tue, 26 Apr 2022 08:36:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1650962168; bh=rxNYrynthAVSNFVZDDnxe1rUHGlVchAhwqVCmHm98Vs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=il94r3FZ40fImGZOiGAgJVGdeNxU0wtLVKAi5eBOGL1EDc13qsRHodplpS+SV9DWV N8q927g6YGlcL6i/TONBSQOoxQl76JIE2yOJ4o+Weo8MtAjIYc3Qhtz/Jq0MTcslmc VH463oK/15DV1eP036XvYhkr2RR9cklzEOBE8lhY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christoph Hellwig , Chaitanya Kulkarni , Jens Axboe , Sasha Levin Subject: [PATCH 5.15 001/124] fs: remove __sync_filesystem Date: Tue, 26 Apr 2022 10:20:02 +0200 Message-Id: <20220426081747.332004348@linuxfoundation.org> X-Mailer: git-send-email 2.36.0 In-Reply-To: <20220426081747.286685339@linuxfoundation.org> References: <20220426081747.286685339@linuxfoundation.org> User-Agent: quilt/0.66 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE autolearn=unavailable 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 From: Christoph Hellwig [ Upstream commit 9a208ba5c9afa62c7b1e9c6f5e783066e84e2d3c ] There is no clear benefit in having this helper vs just open coding it. Signed-off-by: Christoph Hellwig Reviewed-by: Chaitanya Kulkarni Link: https://lore.kernel.org/r/20211019062530.2174626-2-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- fs/sync.c | 38 +++++++++++++++++--------------------- 1 file changed, 17 insertions(+), 21 deletions(-) diff --git a/fs/sync.c b/fs/sync.c index 1373a610dc78..0d6cdc507cb9 100644 --- a/fs/sync.c +++ b/fs/sync.c @@ -21,25 +21,6 @@ #define VALID_FLAGS (SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE| \ SYNC_FILE_RANGE_WAIT_AFTER) -/* - * Do the filesystem syncing work. For simple filesystems - * writeback_inodes_sb(sb) just dirties buffers with inodes so we have to - * submit IO for these buffers via __sync_blockdev(). This also speeds up the - * wait == 1 case since in that case write_inode() functions do - * sync_dirty_buffer() and thus effectively write one block at a time. - */ -static int __sync_filesystem(struct super_block *sb, int wait) -{ - if (wait) - sync_inodes_sb(sb); - else - writeback_inodes_sb(sb, WB_REASON_SYNC); - - if (sb->s_op->sync_fs) - sb->s_op->sync_fs(sb, wait); - return __sync_blockdev(sb->s_bdev, wait); -} - /* * Write out and wait upon all dirty data associated with this * superblock. Filesystem data as well as the underlying block @@ -61,10 +42,25 @@ int sync_filesystem(struct super_block *sb) if (sb_rdonly(sb)) return 0; - ret = __sync_filesystem(sb, 0); + /* + * Do the filesystem syncing work. For simple filesystems + * writeback_inodes_sb(sb) just dirties buffers with inodes so we have + * to submit I/O for these buffers via __sync_blockdev(). This also + * speeds up the wait == 1 case since in that case write_inode() + * methods call sync_dirty_buffer() and thus effectively write one block + * at a time. + */ + writeback_inodes_sb(sb, WB_REASON_SYNC); + if (sb->s_op->sync_fs) + sb->s_op->sync_fs(sb, 0); + ret = __sync_blockdev(sb->s_bdev, 0); if (ret < 0) return ret; - return __sync_filesystem(sb, 1); + + sync_inodes_sb(sb); + if (sb->s_op->sync_fs) + sb->s_op->sync_fs(sb, 1); + return __sync_blockdev(sb->s_bdev, 1); } EXPORT_SYMBOL(sync_filesystem); -- 2.35.1