From patchwork Sun Aug 28 12:46:08 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12957234 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C61FECAAD2 for ; Sun, 28 Aug 2022 12:46:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229638AbiH1Mqd (ORCPT ); Sun, 28 Aug 2022 08:46:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbiH1Mqb (ORCPT ); Sun, 28 Aug 2022 08:46:31 -0400 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B2D639BAD; Sun, 28 Aug 2022 05:46:30 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id h204-20020a1c21d5000000b003a5b467c3abso6793175wmh.5; Sun, 28 Aug 2022 05:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=vR58R442Y/t8Jo0OV+K5yrdrf+CZJYm2VdqXmsIKaQ8=; b=qfnKAdBfDoqLi8EzrQPQGQ6n4wR6PI78+xG9xpu0dvcSK/4tixAqXsyPAle/r3Ha9K KwOVLj9KvLOIUPdhJQsmxuvmMdbWLNTuLQB2U8ihdgpwO1BBcJsC1tx4T+TSqJT2iU69 rNEuV7B2aSIEcUqmSxbtiKuVYmydwPJaz1zMku/RE3d5OYoJENmVxPx3tHJdyoxejaYR QLyXoSXOAz+U6Jtar2II4P6uUnCT+1k32d4pwH2hPqGeiccietHPoBbxtIu7jgSHA0KF MAcNSXS9+6sB6ExQ8gg2y9/f+5wqfvyxPjKvzs6BL2JwmqafWauJeze3E2tA4rmVToBY 1AVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=vR58R442Y/t8Jo0OV+K5yrdrf+CZJYm2VdqXmsIKaQ8=; b=fKCLpb071zS3N4jFqjvhsMwoYyfJr4zDdrB2vzPwW0VwUXqKRhuLP/HoJ5Lwy25prc oxvaWcFnzDaZJeElHPn6RBkKD/3eliFsqXz2aQ7PIk5nkb0KU5AEszW8Fw9ZQU5SN05+ j8BZRlbER1VjpUPmbhk5HWdftg0cp6xzIqp2dRzrC2Ig/41yDmp7ciDy9r0ha1dhUzHR FzHNMfAKPwgfOu3+1WOApmu+zVB93++HzdZ8jszXOLxDkiNKtWGj6kWLBX0QXwA7anc/ U5LTvx2LBBgZIpS/T1AK7zSEqUo1go9Ff7//nYnssQLg7QqQz/78CENm+qYt9blH19bu BtTw== X-Gm-Message-State: ACgBeo0zpC4sEQjFjPoQ7oomNIuGIq5XwhUWwuhUdZ4lNjAwFVZkXXup tlJyHegGBYkJo1HIQLwOvSzQDjkj+N8= X-Google-Smtp-Source: AA6agR6105NVNaYu3MnG3zGKETTG3oXzbPYf7EK8KPOxO85rCb7kIoToxnVWQE2SS6QHeh9R80wprw== X-Received: by 2002:a05:600c:474c:b0:3a7:3954:8818 with SMTP id w12-20020a05600c474c00b003a739548818mr4413631wmo.124.1661690788827; Sun, 28 Aug 2022 05:46:28 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([2a0d:6fc2:4b00:1500:ecf5:e90e:2ba2:1534]) by smtp.gmail.com with ESMTPSA id k25-20020adfd239000000b0021e43b4edf0sm4443414wrh.20.2022.08.28.05.46.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Aug 2022 05:46:28 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Chandan Babu R , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Brian Foster , Dave Chinner Subject: [PATCH 5.10 CANDIDATE 1/7] xfs: remove infinite loop when reserving free block pool Date: Sun, 28 Aug 2022 15:46:08 +0300 Message-Id: <20220828124614.2190592-2-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220828124614.2190592-1-amir73il@gmail.com> References: <20220828124614.2190592-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org commit 15f04fdc75aaaa1cccb0b8b3af1be290e118a7bc upstream. [Added wrapper xfs_fdblocks_unavailable() for 5.10.y backport] Infinite loops in kernel code are scary. Calls to xfs_reserve_blocks should be rare (people should just use the defaults!) so we really don't need to try so hard. Simplify the logic here by removing the infinite loop. Cc: Brian Foster Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Amir Goldstein --- fs/xfs/xfs_fsops.c | 52 +++++++++++++++++++--------------------------- fs/xfs/xfs_mount.h | 8 +++++++ 2 files changed, 29 insertions(+), 31 deletions(-) diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c index ef1d5bb88b93..6d4f4271e7be 100644 --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -376,46 +376,36 @@ xfs_reserve_blocks( * If the request is larger than the current reservation, reserve the * blocks before we update the reserve counters. Sample m_fdblocks and * perform a partial reservation if the request exceeds free space. + * + * The code below estimates how many blocks it can request from + * fdblocks to stash in the reserve pool. This is a classic TOCTOU + * race since fdblocks updates are not always coordinated via + * m_sb_lock. */ - error = -ENOSPC; - do { - free = percpu_counter_sum(&mp->m_fdblocks) - - mp->m_alloc_set_aside; - if (free <= 0) - break; - - delta = request - mp->m_resblks; - lcounter = free - delta; - if (lcounter < 0) - /* We can't satisfy the request, just get what we can */ - fdblks_delta = free; - else - fdblks_delta = delta; - + free = percpu_counter_sum(&mp->m_fdblocks) - + xfs_fdblocks_unavailable(mp); + delta = request - mp->m_resblks; + if (delta > 0 && free > 0) { /* * We'll either succeed in getting space from the free block - * count or we'll get an ENOSPC. If we get a ENOSPC, it means - * things changed while we were calculating fdblks_delta and so - * we should try again to see if there is anything left to - * reserve. - * - * Don't set the reserved flag here - we don't want to reserve - * the extra reserve blocks from the reserve..... + * count or we'll get an ENOSPC. Don't set the reserved flag + * here - we don't want to reserve the extra reserve blocks + * from the reserve. */ + fdblks_delta = min(free, delta); spin_unlock(&mp->m_sb_lock); error = xfs_mod_fdblocks(mp, -fdblks_delta, 0); spin_lock(&mp->m_sb_lock); - } while (error == -ENOSPC); - /* - * Update the reserve counters if blocks have been successfully - * allocated. - */ - if (!error && fdblks_delta) { - mp->m_resblks += fdblks_delta; - mp->m_resblks_avail += fdblks_delta; + /* + * Update the reserve counters if blocks have been successfully + * allocated. + */ + if (!error) { + mp->m_resblks += fdblks_delta; + mp->m_resblks_avail += fdblks_delta; + } } - out: if (outval) { outval->resblks = mp->m_resblks; diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index dfa429b77ee2..3a6bc9dc11b5 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -406,6 +406,14 @@ extern int xfs_initialize_perag(xfs_mount_t *mp, xfs_agnumber_t agcount, xfs_agnumber_t *maxagi); extern void xfs_unmountfs(xfs_mount_t *); +/* Accessor added for 5.10.y backport */ +static inline uint64_t +xfs_fdblocks_unavailable( + struct xfs_mount *mp) +{ + return mp->m_alloc_set_aside; +} + extern int xfs_mod_fdblocks(struct xfs_mount *mp, int64_t delta, bool reserved); extern int xfs_mod_frextents(struct xfs_mount *mp, int64_t delta); From patchwork Sun Aug 28 12:46:09 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12957235 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6B2BC0502F for ; Sun, 28 Aug 2022 12:46:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229661AbiH1Mqe (ORCPT ); Sun, 28 Aug 2022 08:46:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229560AbiH1Mqc (ORCPT ); Sun, 28 Aug 2022 08:46:32 -0400 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 897A339BAC; Sun, 28 Aug 2022 05:46:31 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id m17-20020a7bce11000000b003a5bedec07bso6814498wmc.0; Sun, 28 Aug 2022 05:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=prmlFxfLiXr1FB/8uvb3m0FSiNPc2aaLRgWUmmtRPXQ=; b=qrn5DWQlWKUkjPR+v7gJnjT4Fl4dn8p8f52MsYH29O43k6rHx6s/ReWkRgxAB0uvdn 2yt7vx2ThyPnwvdWX6/AnKqGFOA5QPAcKPxHspc9HdlWWmDSRi1fFMVPJxx7toqP8B3a x2Ro++JclaED4xFkNVW6XM3Z5mp2M2IsC0IVoHS80lvzQTiCGOSNgjvBp3V6WxJ2TQ/8 8qRE0SM19C3b6BkdbXQYpTenv+WUVT84VOH+LQ3XAwu98XCivvjABoEgeSEkldZXGBW5 ySFPnLb7QJSioUiXkBziZxeU6Y0cjbCOs5bH85lq5jjZ6RYv6thMkQax+dyKH9eD8tVM Slwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=prmlFxfLiXr1FB/8uvb3m0FSiNPc2aaLRgWUmmtRPXQ=; b=tPMN/63NNEfItcwhLfENieQhwzFkuWSxgvWPwSgaXny5TBqi4mrO3FwouucQSCh7/b cqPSr96dRU03//Ht27GySEBxm7pkNJQM0pFa3uxAFA+QR26UxA8Oq1zuHDfcPFhGjfHU JNhqqfUOPE7/vFVAPBXT3VdpNchIphlpYAqqz/CQRWJIj1Efu1HVKbyOBV4De2ytldwm c47y5SSzT96J2Od7EKaEzkKem65AEr6sVn/AMNHba52D8iSd0PDE4DQg7QNvVYXVHZHs 3ypGtE5WL/fGTE2QaV4OvoskQ8mwTJcdN07rc5m5CO67102EA9KrBvVWEek9wmUTqYjO STzQ== X-Gm-Message-State: ACgBeo2aMdWDmGuXZTo4RiTFl5dMz1YQqkjPuHhYclqS7Go0GyM3kAOl BRWyjJea+SnUgzQKMj2E/ZikSB5PsAU= X-Google-Smtp-Source: AA6agR6pPSv0dTSgGb+PHhSJC9DcbwwrMScI+rpRkGcH2fprkhXyqstnb8uHun94UMattdvvOqFeBQ== X-Received: by 2002:a05:600c:1d9b:b0:3a5:d66e:6370 with SMTP id p27-20020a05600c1d9b00b003a5d66e6370mr4390887wms.73.1661690790101; Sun, 28 Aug 2022 05:46:30 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([2a0d:6fc2:4b00:1500:ecf5:e90e:2ba2:1534]) by smtp.gmail.com with ESMTPSA id k25-20020adfd239000000b0021e43b4edf0sm4443414wrh.20.2022.08.28.05.46.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Aug 2022 05:46:29 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Chandan Babu R , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Dave Chinner Subject: [PATCH 5.10 CANDIDATE 2/7] xfs: always succeed at setting the reserve pool size Date: Sun, 28 Aug 2022 15:46:09 +0300 Message-Id: <20220828124614.2190592-3-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220828124614.2190592-1-amir73il@gmail.com> References: <20220828124614.2190592-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: "Darrick J. Wong" commit 0baa2657dc4d79202148be79a3dc36c35f425060 upstream. Nowadays, xfs_mod_fdblocks will always choose to fill the reserve pool with freed blocks before adding to fdblocks. Therefore, we can change the behavior of xfs_reserve_blocks slightly -- setting the target size of the pool should always succeed, since a deficiency will eventually be made up as blocks get freed. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Amir Goldstein --- fs/xfs/xfs_fsops.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c index 6d4f4271e7be..dacead0d0934 100644 --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -380,11 +380,14 @@ xfs_reserve_blocks( * The code below estimates how many blocks it can request from * fdblocks to stash in the reserve pool. This is a classic TOCTOU * race since fdblocks updates are not always coordinated via - * m_sb_lock. + * m_sb_lock. Set the reserve size even if there's not enough free + * space to fill it because mod_fdblocks will refill an undersized + * reserve when it can. */ free = percpu_counter_sum(&mp->m_fdblocks) - xfs_fdblocks_unavailable(mp); delta = request - mp->m_resblks; + mp->m_resblks = request; if (delta > 0 && free > 0) { /* * We'll either succeed in getting space from the free block @@ -401,10 +404,8 @@ xfs_reserve_blocks( * Update the reserve counters if blocks have been successfully * allocated. */ - if (!error) { - mp->m_resblks += fdblks_delta; + if (!error) mp->m_resblks_avail += fdblks_delta; - } } out: if (outval) { From patchwork Sun Aug 28 12:46:10 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12957236 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6334BC54EE9 for ; Sun, 28 Aug 2022 12:46:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229560AbiH1Mqe (ORCPT ); Sun, 28 Aug 2022 08:46:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229663AbiH1Mqe (ORCPT ); Sun, 28 Aug 2022 08:46:34 -0400 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E816B39BAD; Sun, 28 Aug 2022 05:46:32 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id i188-20020a1c3bc5000000b003a7b6ae4eb2so1826134wma.4; Sun, 28 Aug 2022 05:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=ClUDeGC9nglyH/ITzPbEnTS1Qj4P8Cu3FgCkPcGFhY4=; b=qUna73fEWTQSKBkaCl8BwQUvBR5KhgOfvgm9542tk6J6ZC4W21+dvsiJlFIVW6Qn1b UFeP+iGy/fOa/EWiMiIIYngTNpu+yXTeSsIhh0moS53c+BMCGMT8uMGWXRDF8ijalqFG PEOvnrp7qG7TudjiIWuknjPhz/TGmFk9ALGxqSSspVzKbkGK8iPVQ9keMN9GTB337uz1 xky5wyJGR7xj5sfoUelbBSKjj/hfJXWPLZpx6c6eW6yHfM8uU7E1OH8z8enDf8Zuq5Gl crI2kVwtw4F8gA/sCETSlkHM/ioKpFMK1TuLyBWyAPjRtq80Vih7le8dXOkmMJmaF4Zu Z+3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=ClUDeGC9nglyH/ITzPbEnTS1Qj4P8Cu3FgCkPcGFhY4=; b=0+hy1oeqST6zi3QqFxN15irKcni5V/9lPfQjiSeNPgPLGmxUOe8Pxa+vWymnw1ns89 lOhd7Z0erB0BW7lyfk38WVCHuQw87QVU5Y4VzZfcpWXbGXpVWBeIM8vT0RmTb8kyAJuB DefEnIx3SL3FZSM2f3WPuUtaoItZ77cpoEegi1ldQTcqqXSheFTXCNezYSXri6OlqRDH iFVhn0AVGmAwVVJujwWadG69o8Co13d+zLNL+IMxnWzeEWj5BT7QWz14VqC1PW455KCM oeZWYRYm7u+NwGxCNZRFUEfml4943SwVp6k8UjMPs5xwNLBqBww64q3QWABPzMEQollV es4w== X-Gm-Message-State: ACgBeo0LUfQj4vD5GDaKorQTJaaeFCtoymEzT9idr7xM3D33b7gNA1h+ MczPbQmYUBl5cHBAliIDbW37ulMyFpI= X-Google-Smtp-Source: AA6agR6F1Ltj7MAi1+cqpkvCPG0Gxo/f4lyXNCcDs1ISgqUnXX5c1VftKzalV2OyIXzMQYshnBUTNQ== X-Received: by 2002:a05:600c:a0a:b0:3a6:71e5:fb70 with SMTP id z10-20020a05600c0a0a00b003a671e5fb70mr4359968wmp.141.1661690791351; Sun, 28 Aug 2022 05:46:31 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([2a0d:6fc2:4b00:1500:ecf5:e90e:2ba2:1534]) by smtp.gmail.com with ESMTPSA id k25-20020adfd239000000b0021e43b4edf0sm4443414wrh.20.2022.08.28.05.46.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Aug 2022 05:46:30 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Chandan Babu R , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Dave Chinner Subject: [PATCH 5.10 CANDIDATE 3/7] xfs: fix overfilling of reserve pool Date: Sun, 28 Aug 2022 15:46:10 +0300 Message-Id: <20220828124614.2190592-4-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220828124614.2190592-1-amir73il@gmail.com> References: <20220828124614.2190592-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: "Darrick J. Wong" commit 82be38bcf8a2e056b4c99ce79a3827fa743df6ec upstream. Due to cycling of m_sb_lock, it's possible for multiple callers of xfs_reserve_blocks to race at changing the pool size, subtracting blocks from fdblocks, and actually putting it in the pool. The result of all this is that we can overfill the reserve pool to hilarious levels. xfs_mod_fdblocks, when called with a positive value, already knows how to take freed blocks and either fill the reserve until it's full, or put them in fdblocks. Use that instead of setting m_resblks_avail directly. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Amir Goldstein --- fs/xfs/xfs_fsops.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c index dacead0d0934..775f833146e3 100644 --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -394,18 +394,17 @@ xfs_reserve_blocks( * count or we'll get an ENOSPC. Don't set the reserved flag * here - we don't want to reserve the extra reserve blocks * from the reserve. + * + * The desired reserve size can change after we drop the lock. + * Use mod_fdblocks to put the space into the reserve or into + * fdblocks as appropriate. */ fdblks_delta = min(free, delta); spin_unlock(&mp->m_sb_lock); error = xfs_mod_fdblocks(mp, -fdblks_delta, 0); - spin_lock(&mp->m_sb_lock); - - /* - * Update the reserve counters if blocks have been successfully - * allocated. - */ if (!error) - mp->m_resblks_avail += fdblks_delta; + xfs_mod_fdblocks(mp, fdblks_delta, 0); + spin_lock(&mp->m_sb_lock); } out: if (outval) { From patchwork Sun Aug 28 12:46:11 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12957237 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5973ECAAD5 for ; Sun, 28 Aug 2022 12:46:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229696AbiH1Mqf (ORCPT ); Sun, 28 Aug 2022 08:46:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229663AbiH1Mqf (ORCPT ); Sun, 28 Aug 2022 08:46:35 -0400 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F39C39BAD; Sun, 28 Aug 2022 05:46:34 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id bu22so6709396wrb.3; Sun, 28 Aug 2022 05:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=D9ELr1XH1ys1yFEaZ4pnTV2N0Zl0djkEo0M633+19Mw=; b=TJwaxL6/SGUenjObbAWHGfHaX10jjF1QO5ntIm2XUqzJDYKu5f/oMAOdlLMJpk1vw4 0lEMjoRZZkbMTDq+w9hBs9X+0EVNDaL0V67c2PaaQBliZi9B00PANRwZDGAz4z+Vqbun j5ZFUeXlONQ37bmkF3nSIaqqklDaSwLA0oFb3PteKTYJVGErlxg/0tkHe+fCEGEAfXcV URoawTWyKBbps95uOuggfkayjtrAI3qYlGQo6EzAxobZHDsWvXXGaq3/g/Xvc6rPpHaV 65dPnupqAlzoRsQLoe8iYpVC4yK5QNzbrkeXi6Lav3jP3a92xqGeV3brK8pRZh65Oyn7 PAxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=D9ELr1XH1ys1yFEaZ4pnTV2N0Zl0djkEo0M633+19Mw=; b=Jh8kyg8ucHI7KFLyDSVLhv81fiAV8W4xpPG0GgkM/chE52JUn/856XhqIEczIKyHcJ 8IDJgUfJEFrbc4Em/a3Sz0yps7+oOBgVlFEm9O2gWTsry9xc75IWKbkjUPutesDFzGaU 3SwWL3qLfUfPsYSXrwCambwCA35WO9miY2tU7EnNbOrgpaONeHhd/VSToxHDcfaT8StF aBMzrDc0D9LhzjQUqwnweYVCQSRD290if4yxH1AIddTry1lNDk0ULoMCtKXC/8pAcCtt MASqBzHN3SF3V9iOhHyW9EaGV5fCsakz5h/47NPCokatOp+O0RlyTNsbBmgqm+82ShSx e3sw== X-Gm-Message-State: ACgBeo0ZtmXL0M4dPFR8cokqsTakxT1PihRRpuj93Zu+Qfk0cjIC6dl5 OmQPV3tXlNYt0LSKdBxCK7E= X-Google-Smtp-Source: AA6agR7peMPIQtkkM5Pqi3GuahJ1o9atlPmEk6xluTupaLaZSHetsNtKflgZVTQh9urZGiKQbIVUlA== X-Received: by 2002:a5d:4d0b:0:b0:226:d5b3:9830 with SMTP id z11-20020a5d4d0b000000b00226d5b39830mr1827098wrt.261.1661690792936; Sun, 28 Aug 2022 05:46:32 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([2a0d:6fc2:4b00:1500:ecf5:e90e:2ba2:1534]) by smtp.gmail.com with ESMTPSA id k25-20020adfd239000000b0021e43b4edf0sm4443414wrh.20.2022.08.28.05.46.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Aug 2022 05:46:32 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Chandan Babu R , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Brian Foster , Christoph Hellwig , Dave Chinner Subject: [PATCH 5.10 CANDIDATE 4/7] xfs: fix soft lockup via spinning in filestream ag selection loop Date: Sun, 28 Aug 2022 15:46:11 +0300 Message-Id: <20220828124614.2190592-5-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220828124614.2190592-1-amir73il@gmail.com> References: <20220828124614.2190592-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Brian Foster commit f650df7171b882dca737ddbbeb414100b31f16af upstream. The filestream AG selection loop uses pagf data to aid in AG selection, which depends on pagf initialization. If the in-core structure is not initialized, the caller invokes the AGF read path to do so and carries on. If another task enters the loop and finds a pagf init already in progress, the AGF read returns -EAGAIN and the task continues the loop. This does not increment the current ag index, however, which means the task spins on the current AGF buffer until unlocked. If the AGF read I/O submitted by the initial task happens to be delayed for whatever reason, this results in soft lockup warnings via the spinning task. This is reproduced by xfs/170. To avoid this problem, fix the AGF trylock failure path to properly iterate to the next AG. If a task iterates all AGs without making progress, the trylock behavior is dropped in favor of blocking locks and thus a soft lockup is no longer possible. Fixes: f48e2df8a877ca1c ("xfs: make xfs_*read_agf return EAGAIN to ALLOC_FLAG_TRYLOCK callers") Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Amir Goldstein --- fs/xfs/xfs_filestream.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_filestream.c b/fs/xfs/xfs_filestream.c index db23e455eb91..bc41ec0c483d 100644 --- a/fs/xfs/xfs_filestream.c +++ b/fs/xfs/xfs_filestream.c @@ -128,11 +128,12 @@ xfs_filestream_pick_ag( if (!pag->pagf_init) { err = xfs_alloc_pagf_init(mp, NULL, ag, trylock); if (err) { - xfs_perag_put(pag); - if (err != -EAGAIN) + if (err != -EAGAIN) { + xfs_perag_put(pag); return err; + } /* Couldn't lock the AGF, skip this AG. */ - continue; + goto next_ag; } } From patchwork Sun Aug 28 12:46:12 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12957238 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85D30ECAAD5 for ; Sun, 28 Aug 2022 12:46:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229520AbiH1Mqh (ORCPT ); Sun, 28 Aug 2022 08:46:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229663AbiH1Mqg (ORCPT ); Sun, 28 Aug 2022 08:46:36 -0400 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 132773A485; Sun, 28 Aug 2022 05:46:36 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id ay12so3035868wmb.1; Sun, 28 Aug 2022 05:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=0DP2J2v+ugvsFOzrB/1jYykF9jBGuJcfo1ru3XQns8Q=; b=Wg+Am12rKbPWfdVVjPGqGuBBwQRJA23M2sIPODSi6MGBLLRfWAKpb6xznxPR6ikbFu oE+YAUwr+zzT66rpLNj23RQIY4eGrQesKih2ZSGYojPszGpQ3/jnPiiHDcqR4MuGLNq2 C6x+TB1GcjokXTayvPqQHJ2RTgRoai1uJalvPbqEcoOSR6TcpL9ypD9TgTWGSUFEeEzF Tmn1jf0mC8raHicFCeZfJIHG9/8UUoEOig8/XAHBiH3WOmORo8Zr7K53Cetld9xkuKbG VSzeX0g7YxzCwrEnr+zOkzyxpv8M95M5KNSYSBX24RhTEUDKPV5gAlN8xrbakQi7PwmF UVpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=0DP2J2v+ugvsFOzrB/1jYykF9jBGuJcfo1ru3XQns8Q=; b=YQIYesusKf0kUaXUI7Wfu9mshOox+kD4epPDJd5z+K/M5nP+QeFcsuSdydDzigcPId e+BuylURudKXkb7ihuR4UeGNu7RBGpM8LTg7YKI+D8bufyteB9s24wA545mCb9vuW4fN fYhqbjEtJWt19zrOgwNiWKXWJl/TJyKEOqZ8uRK45glP5bgM5CZg1XKufIyrabz+1LeE R1hBBQJIFNSsxfBmQTt6PDJnv1rxgv0Em0TkbWPp59XkPK1inkaj2Ihfgtox6aU560CP GpaUQmalZdTBFperN+prPk8A7gH+JXi8RhvxX2Sm31+xx4Zzrb/EWyZKFxRu/l/D73Ql t33Q== X-Gm-Message-State: ACgBeo219Zmsnhci+yKeOUiymrU6ovjw5oLvfRJLly268V8ydIunR9A2 dKxGsF0EARxKes3+KxVoYTFcG3oaOkU= X-Google-Smtp-Source: AA6agR4Cajkmg6jB/CV53fsS1jwJ6v4LOVaKrDbdGBXtoid6LvPy8xcvMZLgMyLMMoMURIYuPOIpGg== X-Received: by 2002:a1c:f20d:0:b0:3a8:4176:139b with SMTP id s13-20020a1cf20d000000b003a84176139bmr1687304wmc.177.1661690794610; Sun, 28 Aug 2022 05:46:34 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([2a0d:6fc2:4b00:1500:ecf5:e90e:2ba2:1534]) by smtp.gmail.com with ESMTPSA id k25-20020adfd239000000b0021e43b4edf0sm4443414wrh.20.2022.08.28.05.46.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Aug 2022 05:46:34 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Chandan Babu R , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Eric Sandeen , Dave Chinner , Dave Chinner Subject: [PATCH 5.10 CANDIDATE 5/7] xfs: revert "xfs: actually bump warning counts when we send warnings" Date: Sun, 28 Aug 2022 15:46:12 +0300 Message-Id: <20220828124614.2190592-6-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220828124614.2190592-1-amir73il@gmail.com> References: <20220828124614.2190592-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Eric Sandeen commit bc37e4fb5cac2925b2e286b1f1d4fc2b519f7d92 upstream. This reverts commit 4b8628d57b725b32616965e66975fcdebe008fe7. XFS quota has had the concept of a "quota warning limit" since the earliest Irix implementation, but a mechanism for incrementing the warning counter was never implemented, as documented in the xfs_quota(8) man page. We do know from the historical archive that it was never incremented at runtime during quota reservation operations. With this commit, the warning counter quickly increments for every allocation attempt after the user has crossed a quote soft limit threshold, and this in turn transitions the user to hard quota failures, rendering soft quota thresholds and timers useless. This was reported as a regression by users. Because the intended behavior of this warning counter has never been understood or documented, and the result of this change is a regression in soft quota functionality, revert this commit to make soft quota limits and timers operable again. Fixes: 4b8628d57b72 ("xfs: actually bump warning counts when we send warnings) Signed-off-by: Eric Sandeen Reviewed-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Amir Goldstein --- fs/xfs/xfs_trans_dquot.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/xfs/xfs_trans_dquot.c b/fs/xfs/xfs_trans_dquot.c index fe45b0c3970c..288ea38c43ad 100644 --- a/fs/xfs/xfs_trans_dquot.c +++ b/fs/xfs/xfs_trans_dquot.c @@ -615,7 +615,6 @@ xfs_dqresv_check( return QUOTA_NL_ISOFTLONGWARN; } - res->warnings++; return QUOTA_NL_ISOFTWARN; } From patchwork Sun Aug 28 12:46:13 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12957239 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79AF3ECAAD2 for ; Sun, 28 Aug 2022 12:46:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229701AbiH1Mqj (ORCPT ); Sun, 28 Aug 2022 08:46:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229663AbiH1Mqi (ORCPT ); Sun, 28 Aug 2022 08:46:38 -0400 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C019C3A48F; Sun, 28 Aug 2022 05:46:37 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id m16so7028396wru.9; Sun, 28 Aug 2022 05:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=2lKAAQGRXDFDgn5dHFEF57LITlT2u7jGFIO/enbJTdw=; b=bhX0bj31MDk5ULDadl4O4OxzddlK3okdaYsAgxO9v16u4CNdio6NzKlL5eea5IH86i 5tYUgfijtiGWdCmmb/3ewMYyEZOyrXl1WqnFkShCw2mPxJ/ldPY47hjQA3NXyQY1aqjY 96wEfQAkrIXkEHkW3+a5T5S7+xYYucKchFQtmUaoFQj4nj183GAm4q2ErpUO4QJR+618 URE8vTgececHwSyyIMEI0X5GFN2GIGrRSsWW/i1Auqhk5B1EhYnfoezzZjwORs+WB1J8 UeS8RQ0trAGHz4Wex89UQ4gapuqt0G18fxzWXHzBBoYvaMVdVdkzcv9YDN6ArATojGOL q0tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=2lKAAQGRXDFDgn5dHFEF57LITlT2u7jGFIO/enbJTdw=; b=TNSVGtYalK/3UNCIfZHHkm6vilFKbcykkMcVrLPnrUnYgwNppknQ/He4IjgwJKN4cR 2c/U1ka+Yow4TnM59EznBbJ0peLw1fTKyx/NsoFcTbr8CrXNLz8Cibq216tW5D2WCFms JqFXgdx5JYoqsk75BXY21OrXpY2Cv/AsMbu6wP+30PuzOPFOv7bWeV1Pp0tu7Ruo4KS7 gwFHnxeaUPS+vwcxlvvEYrOOlOepxxnpYGDDyX+PZtNUyJGk1beYYlhultXpH2B3AFtH w/CuIg1CQZnBN0XnvFfK9gFm2W1IQVVgyVeIrprCuYUb+PboMxZvqKfM3ejJenkYzFvn T4TA== X-Gm-Message-State: ACgBeo0no+A5d8h3i3YCwkQSR982YLP9k7nBL4+FGTlq33AbZ4DrQPJA gY0pqm2ivXS4KIy5DDkKE9g= X-Google-Smtp-Source: AA6agR7uHjXgZK/+0Y2cS3/yP+JzuYubAugKM9u0UaxTAPZfiTJEsUZFSaVb7no4Wul511tJt+PFuA== X-Received: by 2002:a5d:59aa:0:b0:21f:57a:77cc with SMTP id p10-20020a5d59aa000000b0021f057a77ccmr4007032wrr.384.1661690796301; Sun, 28 Aug 2022 05:46:36 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([2a0d:6fc2:4b00:1500:ecf5:e90e:2ba2:1534]) by smtp.gmail.com with ESMTPSA id k25-20020adfd239000000b0021e43b4edf0sm4443414wrh.20.2022.08.28.05.46.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Aug 2022 05:46:35 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Chandan Babu R , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Dave Chinner , Frank Hofmann , "Darrick J . Wong" , Dave Chinner Subject: [PATCH 5.10 CANDIDATE 6/7] xfs: reorder iunlink remove operation in xfs_ifree Date: Sun, 28 Aug 2022 15:46:13 +0300 Message-Id: <20220828124614.2190592-7-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220828124614.2190592-1-amir73il@gmail.com> References: <20220828124614.2190592-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Dave Chinner commit 9a5280b312e2e7898b6397b2ca3cfd03f67d7be1 upstream. [backport for 5.10.y] The O_TMPFILE creation implementation creates a specific order of operations for inode allocation/freeing and unlinked list modification. Currently both are serialised by the AGI, so the order doesn't strictly matter as long as the are both in the same transaction. However, if we want to move the unlinked list insertions largely out from under the AGI lock, then we have to be concerned about the order in which we do unlinked list modification operations. O_TMPFILE creation tells us this order is inode allocation/free, then unlinked list modification. Change xfs_ifree() to use this same ordering on unlinked list removal. This way we always guarantee that when we enter the iunlinked list removal code from this path, we already have the AGI locked and we don't have to worry about lock nesting AGI reads inside unlink list locks because it's already locked and attached to the transaction. We can do this safely as the inode freeing and unlinked list removal are done in the same transaction and hence are atomic operations with respect to log recovery. Reported-by: Frank Hofmann Fixes: 298f7bec503f ("xfs: pin inode backing buffer to the inode log item") Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Dave Chinner Signed-off-by: Amir Goldstein --- fs/xfs/xfs_inode.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index 1f61e085676b..929ed3bc5619 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -2669,14 +2669,13 @@ xfs_ifree_cluster( } /* - * This is called to return an inode to the inode free list. - * The inode should already be truncated to 0 length and have - * no pages associated with it. This routine also assumes that - * the inode is already a part of the transaction. + * This is called to return an inode to the inode free list. The inode should + * already be truncated to 0 length and have no pages associated with it. This + * routine also assumes that the inode is already a part of the transaction. * - * The on-disk copy of the inode will have been added to the list - * of unlinked inodes in the AGI. We need to remove the inode from - * that list atomically with respect to freeing it here. + * The on-disk copy of the inode will have been added to the list of unlinked + * inodes in the AGI. We need to remove the inode from that list atomically with + * respect to freeing it here. */ int xfs_ifree( @@ -2694,13 +2693,16 @@ xfs_ifree( ASSERT(ip->i_d.di_nblocks == 0); /* - * Pull the on-disk inode from the AGI unlinked list. + * Free the inode first so that we guarantee that the AGI lock is going + * to be taken before we remove the inode from the unlinked list. This + * makes the AGI lock -> unlinked list modification order the same as + * used in O_TMPFILE creation. */ - error = xfs_iunlink_remove(tp, ip); + error = xfs_difree(tp, ip->i_ino, &xic); if (error) return error; - error = xfs_difree(tp, ip->i_ino, &xic); + error = xfs_iunlink_remove(tp, ip); if (error) return error; From patchwork Sun Aug 28 12:46:14 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12957240 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5ABCC0502A for ; Sun, 28 Aug 2022 12:46:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229663AbiH1Mqk (ORCPT ); Sun, 28 Aug 2022 08:46:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229700AbiH1Mqj (ORCPT ); Sun, 28 Aug 2022 08:46:39 -0400 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 409DB3A490; Sun, 28 Aug 2022 05:46:38 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id m17-20020a7bce11000000b003a5bedec07bso6814566wmc.0; Sun, 28 Aug 2022 05:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=ypn/DEQ5yZ3JfSoonTbWK72ruVR6qZV5ozeFWT9uBJY=; b=SHdLoNAqSclemXrehclcReC4xaciiy65wcXFRWNArsEjVmAyMV4DUH1TsZdogQYTT+ ZVyj/ksJwA594uEprXqRtlBH1wa4ULKlZj4XJy73HAZ90lTxMQh1obNRHSbFDLPxqMCy RxzQ3p8miN4MEIs6x406f7zzwC+m5vzEv5rqwajHoWtQS1TaAeaxm0eZj9ubRXTNHPLz 0gSYZNFDZtY+fRYdTOa2pVilRHNiEkdA8o20MVYNwcpjJViqGzr2CC0ZF9+J8GOIHwyY An1yYpdG4HgdEpE9sp9cad/GpJ1eht1/o+Gn/AxeyJgCp7wsJDTKDhrYFoUdSsau7UpF 2diQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=ypn/DEQ5yZ3JfSoonTbWK72ruVR6qZV5ozeFWT9uBJY=; b=3CIDRpkoh1NZysTxlm+NSKaScBMXgLFJyoTKLOmTiqwPieP4E7iTAD1RZ6eoQ2556B BSd7dUFFE+JGS6YzkxrKZAPvlXZbTFJktv5NTj5eXVEIF422irOk9xEcQO3gjfkS1WQY 4eiFKby/u62Q3RSnwl84/av+If8vVYrj1E1KjG/Emna855v7PGFv2GRFD31NmwR3lvsh CuBtYC/iEt7pCJhcFEd0CM3Ho5KhRfRcuwFZLfF6tHa9N99TDsfz/RZ5A8iOgeQxVv3Q RZqLIQmWTa6VQoEsbe1DvZchs05KWZB29tEnpTlcgYchTXjSV9SWEZVZzVkUDWoE2S5r unEw== X-Gm-Message-State: ACgBeo0JzLgnlh454QCfFjD69CB8MoYyUBc+C7U36/J1LpmcDbjOCQQV kWnF7AeiFT2jQO9715PYMuM= X-Google-Smtp-Source: AA6agR6viWGC6NN4aUbscG5J28nzTBR6FPI/Ob+KMvyf+GVOSXBWr4ujJnNGqkuKjxAFlDZm2RN7Qg== X-Received: by 2002:a05:600c:ad4:b0:3a5:50b2:f991 with SMTP id c20-20020a05600c0ad400b003a550b2f991mr4232648wmr.146.1661690797774; Sun, 28 Aug 2022 05:46:37 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([2a0d:6fc2:4b00:1500:ecf5:e90e:2ba2:1534]) by smtp.gmail.com with ESMTPSA id k25-20020adfd239000000b0021e43b4edf0sm4443414wrh.20.2022.08.28.05.46.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Aug 2022 05:46:37 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" Cc: Leah Rumancik , Chandan Babu R , linux-xfs@vger.kernel.org, fstests@vger.kernel.org, Dave Chinner , Christoph Hellwig , Dave Chinner Subject: [PATCH 5.10 CANDIDATE 7/7] xfs: validate inode fork size against fork format Date: Sun, 28 Aug 2022 15:46:14 +0300 Message-Id: <20220828124614.2190592-8-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220828124614.2190592-1-amir73il@gmail.com> References: <20220828124614.2190592-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Dave Chinner commit 1eb70f54c445fcbb25817841e774adb3d912f3e8 upstream. [backport for 5.10.y] xfs_repair catches fork size/format mismatches, but the in-kernel verifier doesn't, leading to null pointer failures when attempting to perform operations on the fork. This can occur in the xfs_dir_is_empty() where the in-memory fork format does not match the size and so the fork data pointer is accessed incorrectly. Note: this causes new failures in xfs/348 which is testing mode vs ftype mismatches. We now detect a regular file that has been changed to a directory or symlink mode as being corrupt because the data fork is for a symlink or directory should be in local form when there are only 3 bytes of data in the data fork. Hence the inode verify for the regular file now fires w/ -EFSCORRUPTED because the inode fork format does not match the format the corrupted mode says it should be in. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Dave Chinner Signed-off-by: Amir Goldstein --- fs/xfs/libxfs/xfs_inode_buf.c | 35 ++++++++++++++++++++++++++--------- 1 file changed, 26 insertions(+), 9 deletions(-) diff --git a/fs/xfs/libxfs/xfs_inode_buf.c b/fs/xfs/libxfs/xfs_inode_buf.c index c667c63f2cb0..fa8aefe6b7ec 100644 --- a/fs/xfs/libxfs/xfs_inode_buf.c +++ b/fs/xfs/libxfs/xfs_inode_buf.c @@ -358,19 +358,36 @@ xfs_dinode_verify_fork( int whichfork) { uint32_t di_nextents = XFS_DFORK_NEXTENTS(dip, whichfork); + mode_t mode = be16_to_cpu(dip->di_mode); + uint32_t fork_size = XFS_DFORK_SIZE(dip, mp, whichfork); + uint32_t fork_format = XFS_DFORK_FORMAT(dip, whichfork); - switch (XFS_DFORK_FORMAT(dip, whichfork)) { + /* + * For fork types that can contain local data, check that the fork + * format matches the size of local data contained within the fork. + * + * For all types, check that when the size says the should be in extent + * or btree format, the inode isn't claiming it is in local format. + */ + if (whichfork == XFS_DATA_FORK) { + if (S_ISDIR(mode) || S_ISLNK(mode)) { + if (be64_to_cpu(dip->di_size) <= fork_size && + fork_format != XFS_DINODE_FMT_LOCAL) + return __this_address; + } + + if (be64_to_cpu(dip->di_size) > fork_size && + fork_format == XFS_DINODE_FMT_LOCAL) + return __this_address; + } + + switch (fork_format) { case XFS_DINODE_FMT_LOCAL: /* - * no local regular files yet + * No local regular files yet. */ - if (whichfork == XFS_DATA_FORK) { - if (S_ISREG(be16_to_cpu(dip->di_mode))) - return __this_address; - if (be64_to_cpu(dip->di_size) > - XFS_DFORK_SIZE(dip, mp, whichfork)) - return __this_address; - } + if (S_ISREG(mode) && whichfork == XFS_DATA_FORK) + return __this_address; if (di_nextents) return __this_address; break;