Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3345570pxv; Sun, 4 Jul 2021 16:09:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwhFzL1YxFGlp9AHb00ZEADNQuXOSA1EisKFxcZlZDQR7q1XSYOZwljbXpaApcHjl6xx9y6 X-Received: by 2002:a17:907:728e:: with SMTP id dt14mr10328675ejc.75.1625440164027; Sun, 04 Jul 2021 16:09:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625440164; cv=none; d=google.com; s=arc-20160816; b=CIMZdfkxbV6IV5qsult/xqeyl310Bx2Kw36JTBLPpU18ZR9dKduGz5NcfV+4xNwhL8 AO9dvtK5qpUJpPDV4vp1hPGCDQyaFoUSV3mZryrn5qlQijVBaY0M6qnT9aphtqmoZRH/ 342ibCQv1I18kgu9+YuJrGVmUYgrwS7oROrDcJyur9viJWaC500WWuuLU6NkMEGPMVxW Aa/5LVHUCpdpFZfFu1/blfzf6WWCtXx+b9s8uzzUW8s0F8iE1BvL3NS2gcS8dyJ0pNoA OizzsBYmdxU2iLDbpA5EQK4UflTuCqtKhOxjIRoHI6eUNx7tMHc+Yq6e7HjHW8rp2OZu EjRg== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=5R5IMtwKTmiO/JIACjbz0WySS4NdAnoY19JdLF4dngo=; b=wSDVoepYgy31D3/8s9owFrZXXTctcWd2JhkhfX9Z47hGhdFB+lR0hlz19dF49sFPtH okidnWcdY4xlatCGmsmWbPYGTvxA+9bh9iUdeMP11leXPOj+11IC0penWM9ZpFY8A0iu RkU/eu85yxfaRHka2U9MeQCL3gmMkURsB/OH/fi+7y8i8YHAt+tH0KhUQnfedFAjQxHt NpgLGrtmFR1UcKd+3EpubGdmCZaMVy5Gk02gB24uwDehD0yK0MykXyuHhwj17Qhu6D7a iBfK5k1cgKe4Oc0VSx44645DRWFxG4IP+E/dcWolT5PfS5GUn/tytqHUQrbb6+kDmUNn LkZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="T/HvCR7e"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id nc36si10569969ejc.48.2021.07.04.16.09.00; Sun, 04 Jul 2021 16:09:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="T/HvCR7e"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 S232405AbhGDXKR (ORCPT + 99 others); Sun, 4 Jul 2021 19:10:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:48032 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230103AbhGDXIk (ORCPT ); Sun, 4 Jul 2021 19:08:40 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id F1EC3613F1; Sun, 4 Jul 2021 23:06:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625439964; bh=S6WU4q0VaFrz8X2GaTSL4Y4hPxSAdB7d1yQ7EEGeF+Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=T/HvCR7elDomjJSa4sr5LW2NkUmabRs3yz4iQMhZpdaJwjWvMd6bK/kiVEOvVN8X0 3QdVpian5pFZ0+kzvW3hbkRDlGbmmklBamOmUVwp4U1Go6rxq4spxqi+QDOAWKnG5z cE2/0b+Hz3LYjTMTPIM0PIEas4cJ4GFhS1iamOo7jqoMSvhiFXjfm+vEQkh0RK+uUU 60VTg6XjuaEvxnjjqfHIOGisIDhjf7U9puy6EsrAeriIS0v7fKNgN5Hi0LWxXRK2tB YZub8fN34gZgPdvl78jbMhDGQDZ6TREqycmfGeElqLBRI6vp2Ntpw4VuKmJbczsUaQ sc3oD6I79RwUg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Qu Wenruo , Ritesh Harjani , Anand Jain , David Sterba , Sasha Levin , linux-btrfs@vger.kernel.org Subject: [PATCH AUTOSEL 5.13 77/85] btrfs: don't clear page extent mapped if we're not invalidating the full page Date: Sun, 4 Jul 2021 19:04:12 -0400 Message-Id: <20210704230420.1488358-77-sashal@kernel.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210704230420.1488358-1-sashal@kernel.org> References: <20210704230420.1488358-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Qu Wenruo [ Upstream commit bcd77455d590eaa0422a5e84ae852007cfce574a ] [BUG] With current btrfs subpage rw support, the following script can lead to fs hang: $ mkfs.btrfs -f -s 4k $dev $ mount $dev -o nospace_cache $mnt $ fsstress -w -n 100 -p 1 -s 1608140256 -v -d $mnt The fs will hang at btrfs_start_ordered_extent(). [CAUSE] In above test case, btrfs_invalidate() will be called with the following parameters: offset = 0 length = 53248 page dirty = 1 subpage dirty bitmap = 0x2000 Since @offset is 0, btrfs_invalidate() will try to invalidate the full page, and finally call clear_page_extent_mapped() which will detach subpage structure from the page. And since the page no longer has subpage structure, the subpage dirty bitmap will be cleared, preventing the dirty range from being written back, thus no way to wake up the ordered extent. [FIX] Just follow other filesystems, only to invalidate the page if the range covers the full page. There are cases like truncate_setsize() which can call btrfs_invalidatepage() with offset == 0 and length != 0 for the last page of an inode. Although the old code will still try to invalidate the full page, we are still safe to just wait for ordered extent to finish. So it shouldn't cause extra problems. Tested-by: Ritesh Harjani # [ppc64] Tested-by: Anand Jain # [aarch64] Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- fs/btrfs/inode.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index f9942560866b..5d147f204fca 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -8390,7 +8390,19 @@ static void btrfs_invalidatepage(struct page *page, unsigned int offset, */ wait_on_page_writeback(page); - if (offset) { + /* + * For subpage case, we have call sites like + * btrfs_punch_hole_lock_range() which passes range not aligned to + * sectorsize. + * If the range doesn't cover the full page, we don't need to and + * shouldn't clear page extent mapped, as page->private can still + * record subpage dirty bits for other part of the range. + * + * For cases that can invalidate the full even the range doesn't + * cover the full page, like invalidating the last page, we're + * still safe to wait for ordered extent to finish. + */ + if (!(offset == 0 && length == PAGE_SIZE)) { btrfs_releasepage(page, GFP_NOFS); return; } -- 2.30.2