From patchwork Thu Sep 1 05:48:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12961825 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 F25C7ECAAD1 for ; Thu, 1 Sep 2022 05:49:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231668AbiIAFts (ORCPT ); Thu, 1 Sep 2022 01:49:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233235AbiIAFtd (ORCPT ); Thu, 1 Sep 2022 01:49:33 -0400 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0821B1178EB; Wed, 31 Aug 2022 22:49:17 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id d5so8415095wms.5; Wed, 31 Aug 2022 22:49:16 -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:subject:date; bh=6yyRgULoHRta/eb3LyurLgmxqUUvQOMkvOIjaPH3158=; b=g6NuDieey/R+ImRzcZ1wTMrdAV5kCw1Q+Czn5Cfe1WToMyqnG7/QXRKJ6WXjFHgDQW zoOK8QNUGf+dVhc6xklD/POc3tHL9egSXMATDefOCne8FIz7f9LAVsXrFbtgIlsyockc YB4g2IAU9BF+FZd2ncNFwfnbCDLXDiJzsN84AQd0ZJ4elH3CcZNrsqiU5HC+nspXbVjE Kf8RDN/wO9SSh5sSVHI0AfijvJ85ZIuw1Mo4gpLAKG0d/ASAaXyFQY95crGOqWhsfmof kjz1lT398+7vSzvaBIpGI5XNWa5AbfJd41n+Ys4J4rtED0KEXdQUpTb4q9T0s4spaWAF +l+w== 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 :subject:date; bh=6yyRgULoHRta/eb3LyurLgmxqUUvQOMkvOIjaPH3158=; b=wkkKR5we1Fl41cQ2I3lopI8d5dYUFbUrZnuncNDKZj2fnydnwe6OULUg1QgFZSQhMk hTTq61s0oQObZKSy1gxK6uAEKuNXQAmW628GpcKN50YHMLodYFjIW5/Z31S4o6eDWU3Q /NJbPQUaYJmOOqqfv7Qs4PVAbNhPDTf9voKlhoNem3uih1Y9Z1VRSO41Qao3Q2yjn0xs ijkPQ96yM9QFsQN/o2VAQliXR6H0WbPUvx6lPIxRoCxACxBPs5shX5iRuMnmsDz3asP6 g/C083t4waUlrQ46T9ebmfvD93vgYMRWL+e4nvOBJK2vl+nbybxuUxWOwgxGMIOAqG5V 9Jcw== X-Gm-Message-State: ACgBeo0Mx0hkMuegwtEhxng2xV/BtFT23HSZMNPcuGY3/fXHGX+locYk yiXfLx9a2IHSCq8/J+JTxZc= X-Google-Smtp-Source: AA6agR6lJRveGsUJMNiN6foTfoqKPphM/QrPewa0sAkh7Dmx37qve++Ac4G1+VxmEL6xC14o1W07BA== X-Received: by 2002:a05:600c:1992:b0:3a6:23f6:8417 with SMTP id t18-20020a05600c199200b003a623f68417mr3757460wmq.14.1662011343318; Wed, 31 Aug 2022 22:49:03 -0700 (PDT) Received: from localhost.localdomain ([77.137.66.49]) by smtp.gmail.com with ESMTPSA id bg15-20020a05600c3c8f00b003a4f08495b7sm4447262wmb.34.2022.08.31.22.49.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 22:49:02 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner Subject: [PATCH 5.10 v2 1/7] xfs: remove infinite loop when reserving free block pool Date: Thu, 1 Sep 2022 08:48:48 +0300 Message-Id: <20220901054854.2449416-2-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220901054854.2449416-1-amir73il@gmail.com> References: <20220901054854.2449416-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@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 Acked-by: Darrick J. Wong --- 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 Thu Sep 1 05:48:49 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12961823 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 75AEEC65C0D for ; Thu, 1 Sep 2022 05:49:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233202AbiIAFtr (ORCPT ); Thu, 1 Sep 2022 01:49:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233233AbiIAFtd (ORCPT ); Thu, 1 Sep 2022 01:49:33 -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 12C8F1166E7; Wed, 31 Aug 2022 22:49:18 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id k17so8425547wmr.2; Wed, 31 Aug 2022 22:49:18 -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:subject:date; bh=pbhYhCVy+vOkWyvQ7AmT+FzIvJlqjatuYMTY3L/HslY=; b=awdXfoYpXIAfEtRAqa38uaehlbxB2VqdXmQn98llkOb0kOa+7liVeAGKTXn8RPUscI CUNjO1d/lIMCfa5PzBexSKs9QprjWuh9EDqfveiwmns3Q7Q4yOjKWQnrdrIoO6oLrtKI /Rqs/rjVLKSin36nP1blaOisw1NtgDKkKvR2Fh/bcdHjT7EuKDZE2w7A47PZYHmoWDs3 ilNEJl5GkRwjdZpdx0ihnxHi2kjGlgNwwqQPYFvp+Ebm2WTcZ4lNpqrdRhcM/opH3TQ9 uv0esPkf4OSWxsC0fWbRBkHy3lIBdLMaKki29jrbDi0KPYWdUK0gUMUqdqTfv5i0b/dg 4w5Q== 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 :subject:date; bh=pbhYhCVy+vOkWyvQ7AmT+FzIvJlqjatuYMTY3L/HslY=; b=uZYyQzEkegxwgf8dZ4Zr7R1lf0mjuJi5yKHkvrxN6JaK1Y5LqWCnKv1yrSC6XQBRxn ktd6dPcHDr+IXJApTTJxsji+bj9Ead3YsFE0nnShmPUxll6ZamcIQ3Zdvbau19LeBjP9 B/f32h5sXuJebgS8nplhW//S08juGkzmf9kPmUf66Bxy09lFzJGfog9P+gkGStQjd8X6 5wEPjq5viSHPSMNFfxiwzQKcsa220+GHFhM4OeeWewqT2kTP6990o7zo2VZVX7OG0rnx 7c4Op+DBjTvhgEOVOfOQ51pRGRpRUmC6QmMT9Tu+j19JsWyyNc6JxO+DdI8C9VFF4o46 almw== X-Gm-Message-State: ACgBeo2ny19NQwwp7KpUiAlNa2GAUzt5uZKIft5yORbTVRyack2DAUvk 37fr7+X16nDiX/Ku+BuZTjM= X-Google-Smtp-Source: AA6agR4gY3GwLOr/wKH8JJWN97nfLFUSHK+XwdoZy6WgryF/3sFK3/1QCXuNd1mDhaysFShnsL/Bpw== X-Received: by 2002:a05:600c:4ec7:b0:3a8:4622:ad27 with SMTP id g7-20020a05600c4ec700b003a84622ad27mr4141193wmq.88.1662011344941; Wed, 31 Aug 2022 22:49:04 -0700 (PDT) Received: from localhost.localdomain ([77.137.66.49]) by smtp.gmail.com with ESMTPSA id bg15-20020a05600c3c8f00b003a4f08495b7sm4447262wmb.34.2022.08.31.22.49.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 22:49:04 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner Subject: [PATCH 5.10 v2 2/7] xfs: always succeed at setting the reserve pool size Date: Thu, 1 Sep 2022 08:48:49 +0300 Message-Id: <20220901054854.2449416-3-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220901054854.2449416-1-amir73il@gmail.com> References: <20220901054854.2449416-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@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 Acked-by: Darrick J. Wong --- 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 Thu Sep 1 05:48:50 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12961824 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 9C40DECAAD8 for ; Thu, 1 Sep 2022 05:49:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232374AbiIAFtr (ORCPT ); Thu, 1 Sep 2022 01:49:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233234AbiIAFtd (ORCPT ); Thu, 1 Sep 2022 01:49:33 -0400 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F4FA1178F8; Wed, 31 Aug 2022 22:49:18 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id n23-20020a7bc5d7000000b003a62f19b453so709387wmk.3; Wed, 31 Aug 2022 22:49:18 -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:subject:date; bh=rXO269FD1Qqh/3kSRd+jcHDLkTXo4nk6CloH8biq0G4=; b=lcBt1D2ozbfxCreI8a5QDg6/ghKxaGngsLVwnAdnPAygerzAQSYoe3s8OksG+rl4d0 /myztBG8tQiuKXMBdzcwdpcxDoZ6TeYx59gZ/4/wZnUgcAgvYBNvVCdNFM/G5lzkNb2z 7krFgN0kkMlXyaFuu1MbqsfrtQFFUwPo3nPISnXAfPbBWPRChQ93WqVcOl0FMJ1/mZ8/ 1USYKzYxOqCVScMZ3WYm6EQQ+a0O5GAJvNIKng9zIcFYxNKKJ8Bb4CxF1wSsBw44La/h HqqvJ6EYVgxFaFCRgGU4hYUgfClKP1U5FCd9sNd8q83eVKAT6mo2tXMfn5mAwCp5EAYx rsWQ== 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 :subject:date; bh=rXO269FD1Qqh/3kSRd+jcHDLkTXo4nk6CloH8biq0G4=; b=Yio69aXhtA4Nb51rZyRchpHNePRWpQ6VP5Yy+2Q/tKtakaiGzBvXaepqdWBWjkCeW1 pJCJvpagj5VNhKvjAFA6VOsOyFu3CvuADEAKATFbFDm3co+DnsZnNDHP59Dk2X+o/rAU eqTquJeDTjPk9tcTJzh8OC1ldf6bkiAcwvHKX+Rf97jEXuD0Y9tNcEK/EsWlHQ4i54EV Cs6klg+tBplIdXjdFhfafNZCpbNWrwZ2/Oiy/tcgEfbugkqyBjW85NPeguy348oHKJnj idJcF12oVEzNO5sJpl8eoRPPuUnqIHeAPvxGuYjJiW7etdqcEWpoPlTQGgKgZKIL24LU s32A== X-Gm-Message-State: ACgBeo0HpzVOfJo73zfOs8hswX7fHw2NNT/2VP2UHiSkhw4AZp0nTraf 1B4P2g2BkwMpJPlR4FlmciM= X-Google-Smtp-Source: AA6agR6wP+xXOYpv+/W1Z5iqSGaKFtnj7VDL4EtJOlAuDX0SRIiKSnJggYSRVh+OkSgusl+5zmSVng== X-Received: by 2002:a05:600c:3b92:b0:3a6:5645:5fc7 with SMTP id n18-20020a05600c3b9200b003a656455fc7mr3891845wms.148.1662011346725; Wed, 31 Aug 2022 22:49:06 -0700 (PDT) Received: from localhost.localdomain ([77.137.66.49]) by smtp.gmail.com with ESMTPSA id bg15-20020a05600c3c8f00b003a4f08495b7sm4447262wmb.34.2022.08.31.22.49.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 22:49:06 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner Subject: [PATCH 5.10 v2 3/7] xfs: fix overfilling of reserve pool Date: Thu, 1 Sep 2022 08:48:50 +0300 Message-Id: <20220901054854.2449416-4-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220901054854.2449416-1-amir73il@gmail.com> References: <20220901054854.2449416-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@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 Acked-by: Darrick J. Wong --- 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 Thu Sep 1 05:48:51 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12961826 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 C37CEC67868 for ; Thu, 1 Sep 2022 05:49:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233214AbiIAFtt (ORCPT ); Thu, 1 Sep 2022 01:49:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233236AbiIAFtd (ORCPT ); Thu, 1 Sep 2022 01:49:33 -0400 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98B751178FB; Wed, 31 Aug 2022 22:49:18 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id m17-20020a7bce11000000b003a5bedec07bso738296wmc.0; Wed, 31 Aug 2022 22:49:18 -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:subject:date; bh=xLW9Gby42tyiBFlIoDzW7LpOcnfeeekTuyuaQuWlQqE=; b=g5h3FoJOwX1B/0q2TzBNU8HK5HFXNm3CfXKFc71pJYk04OeKbSr/Xri6VQvGfF8EYU GFN1BqNZ0vo4ZCecNeK864N13E8kVOMjlwFW0KidBaApGVNcNPJsRUF8P6vQrbh5tPC0 /F63ULDpTvsGQTS2zoxNkLBaj1c10w6QOQyWIXC08jYOO4XjJaVXmaBZiTgJK3oNjhvK xy9jCJIMhabxnrBpLwBru76InUebvagezSbpeYyWHC9TNX/NrlGzwBSbfvgRRpR3lqUo +y2/ABJPRX2Z6vYomlnQenwBizG2pkG9LFBF3JEhdHkQXU01DSPSG5TK7z/EO9+kWr7+ e0YQ== 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 :subject:date; bh=xLW9Gby42tyiBFlIoDzW7LpOcnfeeekTuyuaQuWlQqE=; b=hqKPqzmft1hlVXNI3VgeVjlSjW/q+2JzJsjUAoINL5pRsweU6e5BJ/nzrr5hNp0QrS HeOSgBT+bmbwOKvlQwPZri5o2sI8HH/50ltuer309nUgfslhfsjpGTOoq4+iM7emfJV3 eyKC2RWaMDD1tbrus0BzW74cuAr9TyGjyK+GneWBjlqvV4tqqAFv3xeEKNJ3D9SPZQlD WVExacfIAciMv93TYLSfskyoNZZTj52i+vEOqBBRj/L2hu0dgZIFGaXaIdXRpDEaMCD4 yCREbUiDaYB1+KYdHtPv4CebVNgbHnulSs7wEANAm2ZxeMXlMv59eP9XCacUXscv7BBx ERGw== X-Gm-Message-State: ACgBeo0DXw8HCe+OHyF/UtFGFWCM8KI+en//fNf0rvN8bUPaxm064Rmq rHxENc1xcNRxQShm8M3H8nM= X-Google-Smtp-Source: AA6agR6lpyfen3E7ZZCl4CVsrYGtXwlqRud7ZXBehC5nogXSgojiQRclt8jcM6AlFw9ZEijwPW+8OA== X-Received: by 2002:a05:600c:384f:b0:3a6:603c:4338 with SMTP id s15-20020a05600c384f00b003a6603c4338mr3948107wmr.192.1662011348618; Wed, 31 Aug 2022 22:49:08 -0700 (PDT) Received: from localhost.localdomain ([77.137.66.49]) by smtp.gmail.com with ESMTPSA id bg15-20020a05600c3c8f00b003a4f08495b7sm4447262wmb.34.2022.08.31.22.49.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 22:49:08 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Brian Foster , Christoph Hellwig , Dave Chinner Subject: [PATCH 5.10 v2 4/7] xfs: fix soft lockup via spinning in filestream ag selection loop Date: Thu, 1 Sep 2022 08:48:51 +0300 Message-Id: <20220901054854.2449416-5-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220901054854.2449416-1-amir73il@gmail.com> References: <20220901054854.2449416-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@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 Acked-by: Darrick J. Wong --- 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 Thu Sep 1 05:48:52 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12961828 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 AE031C6FA86 for ; Thu, 1 Sep 2022 05:49:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231838AbiIAFtu (ORCPT ); Thu, 1 Sep 2022 01:49:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233237AbiIAFtd (ORCPT ); Thu, 1 Sep 2022 01:49:33 -0400 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13E481178D1; Wed, 31 Aug 2022 22:49:18 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id e13so19946061wrm.1; Wed, 31 Aug 2022 22:49:18 -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:subject:date; bh=4oxQGuYR2UpJS0BVOv4mLxNV2a7chSFxPlvyuLBVozo=; b=WnIo4RCLAX4ieqoTb/VLjaFosBF1UY2gcAQHiVcDHiKznOSWTTLqfIwTf6n0LUht19 TBTorPVH2qhv8goh//74w7c7mVCw0k9YyOugXe3mOKWB/7XA24Kh1+CuHpqbG9iqrcOg 8WsK714TlYnPOVN4LOmkYxiaYv/Q0Naza/nAQnGH/+99QW7St58O5UfabzMYtzQunfr/ 4Zr1WrwMSX18K6TqTQIyIuT64cDSF2Q5s1nnO9iaLPx5w69MXv0xZ4090Wy356jzIHQb qk4v6UEIYY1VNsEzeT/lvx/iAqeJdXxR3QF0Ya05lpPMhNEr8exraCszr1UOi6VgYvrk Ca5w== 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 :subject:date; bh=4oxQGuYR2UpJS0BVOv4mLxNV2a7chSFxPlvyuLBVozo=; b=z9YoJTq1H82IATQaM1kN4WV1VIgNUkwZ3biDHdfuIIv5e6d9DNX1KaeZzAHWwP1Ijw a/nVO0Zz6hKWPzkiS8W9NjmyvvNMds36BNMWB6kagvvRpB+u/nnCRpwerS85v/maMA2/ stWCxjA71XsHcrbh8RE21ZQm56BGrWrBDgtZ0bAc6jaR8hGw/B7eczdiylNUZOawhJJE p34MVWwG8wwkPw0B850D0NM/fmXAtAtulik8zlas9XcHBwThTFcS53tFaXS9v7zUoyCr nnFSxXPI/TetoZugJmU1fp24bKm0UipWAW0BwVnEfB9KYtEnnkTldQ6/wsCsN9RZ+01r 2vvg== X-Gm-Message-State: ACgBeo1dxm//rFQXyw7EMIQ29aBRm3poTapsFtG5s8hVeUumnydW49sZ CYHup1ZppiBZMTwlnFNIplz2nAf53bk= X-Google-Smtp-Source: AA6agR5joboXJ50eoG2Z6BF5GBW6Yh5sfKVgZPkKsN9Ofcq93h+RS3Gip+6Kf0tI6cmW3ZIknNaXKw== X-Received: by 2002:a5d:4b4f:0:b0:226:e3d0:b6f8 with SMTP id w15-20020a5d4b4f000000b00226e3d0b6f8mr6342409wrs.355.1662011350617; Wed, 31 Aug 2022 22:49:10 -0700 (PDT) Received: from localhost.localdomain ([77.137.66.49]) by smtp.gmail.com with ESMTPSA id bg15-20020a05600c3c8f00b003a4f08495b7sm4447262wmb.34.2022.08.31.22.49.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 22:49:10 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Eric Sandeen , Dave Chinner , Dave Chinner Subject: [PATCH 5.10 v2 5/7] xfs: revert "xfs: actually bump warning counts when we send warnings" Date: Thu, 1 Sep 2022 08:48:52 +0300 Message-Id: <20220901054854.2449416-6-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220901054854.2449416-1-amir73il@gmail.com> References: <20220901054854.2449416-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@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 Acked-by: Darrick J. Wong --- 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 Thu Sep 1 05:48:53 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12961829 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 342FEC6FA85 for ; Thu, 1 Sep 2022 05:49:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232470AbiIAFtv (ORCPT ); Thu, 1 Sep 2022 01:49:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231443AbiIAFtg (ORCPT ); Thu, 1 Sep 2022 01:49: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 B9F291178E6; Wed, 31 Aug 2022 22:49:19 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id m3-20020a05600c3b0300b003a5e0557150so2667849wms.0; Wed, 31 Aug 2022 22:49:19 -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:subject:date; bh=esm7WY5NBPF0ohza2iIRHTShjFzVuQEeXBALGm/uCz0=; b=f3BwabQXtFLB3sxcrI4AExoIkU478Q8Jxpm2w9lj9pBCD+cbfY8Uv6g81zSDZoMDsz twHcHeOU1vNxl6UMErBxjozzoYlMcMN553ZIT+wmXHKF555+uLZ1KdnswWAKKHNDLl4U wLWuUASVVTvxdbT4Ckkc2q7H7vXUokYILLCBb49+zmKg00iagU/e8klfu11nz0juXVh9 kAIi+jZXHi2YvYT63sDn+0JS2sVC5HOXyB9K0kkE+K6OCVUMdVyJkxOshdy2Z7cBy0ab BXZAoR+KM1yXfkG/jBAHaGYA6oIDW/RQZP52/Y0hLmU3xN9Sge2HG+ivl7td0f6AoGGX tzAQ== 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 :subject:date; bh=esm7WY5NBPF0ohza2iIRHTShjFzVuQEeXBALGm/uCz0=; b=sKDRiVJq3iy5eBiDE1psiqgAJrSPoJ1zsrl4CMCf4lXKw8N7+4ouop9hTZCksViaj4 RdP7ia3ZzL5ndqnhmLjGUQ6+XbsbYx4H2ktxJYThg3b9CpPYu+zpsuHg/p+LQhNcbf1i nZQ3U+2olEYSaAgvDpUcH+ksaDi+/BexXW9dPQhSpo0aJNce8pvdaTqmtBjD/y1RZDM1 lrMXYAtFF3xhGKBG3zuCWHy8ZIEkhusqSenUi4xjG/r47BD1RalnguXpcOXfY0zwIdvz 8C5TrmbFf9rSoFer9YxRMkswMpHgd+e83AIhHZNNiNANRMV9/YhukZ//02L9Tx1lYW+4 xxyQ== X-Gm-Message-State: ACgBeo2d3ENpH+EpQTxfy1GuKMk/uAGveZx+c/ceHkjJAGgbNY9g7KUK LEjuR0xqyELFe8/HFmxv8sA= X-Google-Smtp-Source: AA6agR5fg+7Au2KoQmAhTByhBycyzCYTbLAzUG//LZsbjYv4u+RKV64y8EHg21CMHJ/uDh5TGIX6Sw== X-Received: by 2002:a1c:3b55:0:b0:3a6:7b62:3901 with SMTP id i82-20020a1c3b55000000b003a67b623901mr3927634wma.113.1662011352705; Wed, 31 Aug 2022 22:49:12 -0700 (PDT) Received: from localhost.localdomain ([77.137.66.49]) by smtp.gmail.com with ESMTPSA id bg15-20020a05600c3c8f00b003a4f08495b7sm4447262wmb.34.2022.08.31.22.49.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 22:49:12 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner , Frank Hofmann , "Darrick J . Wong" , Dave Chinner Subject: [PATCH 5.10 v2 6/7] xfs: reorder iunlink remove operation in xfs_ifree Date: Thu, 1 Sep 2022 08:48:53 +0300 Message-Id: <20220901054854.2449416-7-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220901054854.2449416-1-amir73il@gmail.com> References: <20220901054854.2449416-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@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 Acked-by: Darrick J. Wong Acked-by: Frank Hofmann --- 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 Thu Sep 1 05:48:54 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12961827 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 29DB3ECAAD2 for ; Thu, 1 Sep 2022 05:49:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231717AbiIAFtu (ORCPT ); Thu, 1 Sep 2022 01:49:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233239AbiIAFte (ORCPT ); Thu, 1 Sep 2022 01:49:34 -0400 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 62382117ACB; Wed, 31 Aug 2022 22:49:20 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id m16so20829486wru.9; Wed, 31 Aug 2022 22:49:20 -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:subject:date; bh=M3jAT3YQCl4NufeW6oCkMl9aVNOp6TjzxP0+mQ9Dows=; b=q74S3j9a2DH2WQcHC5XMVxoVDw/gyodqLA0RLf2ByvyojIvpvtfmtB7Lu66e+pc6dL 4Lxla631n8+TW2rNUGZ1tjXENxN+51Up7tPqyyXNXI/3fb3gdD82OTBua6nuvuQyowkC Vk2J+vl7h79XyH6g61NZMz7PjcmbYE2JFgdFNVusxZP3Jsj0t0D10HCB1DO07vVt+fqW psPCQg53dGojhx/sPTAwEggvbNR/PEe0IOkOM7hkG5xzMx2V8JHVVzabLaeLapWl7yfw AMYDnLf0ItvaasNmbdq6rTAX60GbcW7Oo/TUU0vSDPPbhM1kRNfWO1/NZzXcXfL0mQFl uerA== 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 :subject:date; bh=M3jAT3YQCl4NufeW6oCkMl9aVNOp6TjzxP0+mQ9Dows=; b=GKtlr5kwT08qp3AQ8waVMfQgknrPV8VgHlBW+F+jZmBzpuLdZb2/j88Nq8fn3N4OZt IPFZeKQqpbaq0OH48TIGZVzpiS/jniXtTqdR1r2dMlwN+A7fnGinpokUbzO7z7waT3wj Kf65GJiNiGJAZEaxSrjDQmRc94Y7ARo9qlyw/CbNDQvlHKOf+eRLzR+iXjUIcyL3m8ih 679cO+FWh69UFuzk3EMPjUN4BWO/zKd3k+6uc2zBC63X5mOZkAiyNpYZrKg5viV4pN9F HVy/cSS7YrOWTDldYNw8GTdxgD+lWezmf6f538YH7OGWtULCUVhACkmuAB+fVXQ2cfAF xiYw== X-Gm-Message-State: ACgBeo24hgMY8EOBbYCJnG7vdAqaA4C6rC75frPDntcXglCaTi7V5JHY kMT+YOf3nNtXvlzxcfjdrkA= X-Google-Smtp-Source: AA6agR5ylTkx2uA7K//Y5OfnOmGzIarMLx3C+fZn4k9NX2XzlPcp0IAPpeD+4lFd9V3BJkARXK41sQ== X-Received: by 2002:a5d:598f:0:b0:220:8005:7def with SMTP id n15-20020a5d598f000000b0022080057defmr13924910wri.435.1662011354515; Wed, 31 Aug 2022 22:49:14 -0700 (PDT) Received: from localhost.localdomain ([77.137.66.49]) by smtp.gmail.com with ESMTPSA id bg15-20020a05600c3c8f00b003a4f08495b7sm4447262wmb.34.2022.08.31.22.49.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 22:49:14 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , "Darrick J . Wong" , Leah Rumancik , Chandan Babu R , Luis Chamberlain , Adam Manzanares , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner , Christoph Hellwig , Dave Chinner Subject: [PATCH 5.10 v2 7/7] xfs: validate inode fork size against fork format Date: Thu, 1 Sep 2022 08:48:54 +0300 Message-Id: <20220901054854.2449416-8-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220901054854.2449416-1-amir73il@gmail.com> References: <20220901054854.2449416-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@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 Acked-by: Darrick J. Wong --- 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;