From patchwork Fri May 27 13:02:15 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12863333 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 6A789C4332F for ; Fri, 27 May 2022 13:02:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351614AbiE0NCn (ORCPT ); Fri, 27 May 2022 09:02:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238766AbiE0NCm (ORCPT ); Fri, 27 May 2022 09:02:42 -0400 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 234EA36171; Fri, 27 May 2022 06:02:41 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id l188-20020a1c25c5000000b003978df8a1e2so625342wml.1; Fri, 27 May 2022 06:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=2qWgwOMIZoZnoqcx4izZwNBl2nOWFWpcJl0NLoI3n8I=; b=D1asEyurKfOj4O5wyIM2tCD77qiG2CDbf5Rm4L+CPlOeY05rXGZ42wq0lRN87FsOBx vtA6XNJYHu82PXphIrsIqiv7wEEDZyxiROgBhER/IegsC4js781gTLAPu4SWQ9dTlnzz XRVOkhdhPUk8gWCshQ5Oh70vUnaBXqXuziDEh2Eq+q1FhONkFoLzLnnlFSuZYFbh00e8 RHGvigeRP3HT4/asV/J5pgLylsKOPBcskqb4teBN7ArlOmhpnmvtpkTkWKX2cccLr/CZ C+/F1ridNKYVlD76tJZnryRvjrfmy/S5zI4EimJ1NbBTNxHdPA2Pc6/3huTuYQnDd5Zf YioQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2qWgwOMIZoZnoqcx4izZwNBl2nOWFWpcJl0NLoI3n8I=; b=AOImio6jZVa6PN8igIaGTB0PtiJnsIz9nbAIofuAXxDL6KU4dhmiAqIbXJteo1+lnj Hg8+TS9D2NbYc7Emj+1bFVokT8P4ogxammQ/kxOX3eeKU5aZmdvbFahfANyCRyay/FLC JhjHDjRm1mpq8LCy90ZKFCtmlogZXY/9aSLB1FvWWRk94LVcbn4ENLOvtojv8kOgrx0a VBrsW3IwZyBoj/RHDDzTE2KQzwJPdk2gtxn2I1wAiMJnNE/VEGye4aOdCHXXAAK9X43r DaoKFwfnIoM2u2SwPPI1WyHDrYy/a53jAYg9RtbESxfpC7oPKz7ypZVaWSKN+OMwtV14 ruHw== X-Gm-Message-State: AOAM531j8JqeCOfticLh4MciCJvlRsLrwrvCdJzwTjhBsWC/iyG8u/+z K8qN3z/w7owvV3nwgUVD71o= X-Google-Smtp-Source: ABdhPJyZMS3hMDKVoKJL4EN8AfFxBYaewcCJ18FDO7g7uVvOcs6VQGCWuBZUahHthiSIqZqYE/IRcg== X-Received: by 2002:a7b:cd0b:0:b0:397:49cf:2ef0 with SMTP id f11-20020a7bcd0b000000b0039749cf2ef0mr7005306wmj.156.1653656559614; Fri, 27 May 2022 06:02:39 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id l36-20020a05600c08a400b003942a244f48sm1932569wmp.33.2022.05.27.06.02.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 May 2022 06:02:39 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Luis Chamberlain , Theodore Ts'o , Leah Rumancik , Chandan Babu R , Adam Manzanares , Tyler Hicks , Jan Kara , linux-xfs@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH 5.10 v2 1/5] xfs: detect overflows in bmbt records Date: Fri, 27 May 2022 16:02:15 +0300 Message-Id: <20220527130219.3110260-2-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220527130219.3110260-1-amir73il@gmail.com> References: <20220527130219.3110260-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 acf104c2331c1ba2a667e65dd36139d1555b1432 upstream. Detect file block mappings with a blockcount that's either so large that integer overflows occur or are zero, because neither are valid in the filesystem. Worse yet, attempting directory modifications causes the iext code to trip over the bmbt key handling and takes the filesystem down. We can fix most of this by preventing the bad metadata from entering the incore structures in the first place. Found by setting blockcount=0 in a directory data fork mapping and watching the fireworks. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Amir Goldstein --- fs/xfs/libxfs/xfs_bmap.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c index d9a692484eae..de9c27ef68d8 100644 --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -6229,6 +6229,11 @@ xfs_bmap_validate_extent( xfs_fsblock_t endfsb; bool isrt; + if (irec->br_startblock + irec->br_blockcount <= irec->br_startblock) + return __this_address; + if (irec->br_startoff + irec->br_blockcount <= irec->br_startoff) + return __this_address; + isrt = XFS_IS_REALTIME_INODE(ip); endfsb = irec->br_startblock + irec->br_blockcount - 1; if (isrt && whichfork == XFS_DATA_FORK) { From patchwork Fri May 27 13:02:16 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12863334 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 9CEB3C433F5 for ; Fri, 27 May 2022 13:02:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240328AbiE0NCq (ORCPT ); Fri, 27 May 2022 09:02:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238766AbiE0NCq (ORCPT ); Fri, 27 May 2022 09:02:46 -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 D918A38DA5; Fri, 27 May 2022 06:02:43 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id f23-20020a7bcc17000000b003972dda143eso4534008wmh.3; Fri, 27 May 2022 06:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=LuV2WNWBzFzDFM9UzO8H2iJ9QFWj2tDa1lgS6fde0JU=; b=UvvABez8z9lZbkFJbj4IVJXKTyWP60hfRwmj8uhW2+hn4U1iQQbSVlNjLJj6JzsDvv dkfqaUixXEd8l0L7AijSNvw/t8RUb4NiIvD7pIFPvIBFLwp6kgL4lesmCjG3qACe/e3F MJhJoMoEZd0vBm/TY2/A09Ga98djpZBtJ8TdG/h1hsZnR1dUotLFRFZdZH04jGolLm3Y ++tksUi/5t8gVMQZqkdOoicsQbDeV/8qp63Tc5uRy2lmcUqY96a/DUh6VZcUje2TUxWZ Z79q+Ef1cPoYuN6klaYXfXlk3RMJxAyn9HhQjWewtr7AzNUn8RGum5OWbZyaUH8Ml6q5 Nb6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=LuV2WNWBzFzDFM9UzO8H2iJ9QFWj2tDa1lgS6fde0JU=; b=cofpERDbE4rfFECfpE2aqVZH4zlgaGsoxZFQWbs6A9tqwY/axaoXNO4Ttw5LSt5PBB wWR1rjduqJIYCXLyfy3HMzCVDF4OPNR319F1QOKe6Icnvu1u6BBM9sPe+rlPL/gk8o2/ xYswje9GIDP5yAB2M8xK8a6FaGdwk69apZU2g7jdNjfaHU9gjBD46OaV+zOPHg7pu8mb o/V6P5RIueIe96Hau5ixrmdRg2Bm7mM3kw1VF9vZAAqy7a1mZL+IOmdN+1jhMlNygXaT rQeEowImZdH1V/KgnDmpKhYBk0tk1yKXNFXXRRV6sG0cDujEP8WzmKSH2wKRQkJiotkX D9CQ== X-Gm-Message-State: AOAM532LlxDIklD24ayg1x1YYu0Tmt3xIsXN8gKxIfFKeajus8oKGjki mrRb83PfcOzUWHQPubxwhGA= X-Google-Smtp-Source: ABdhPJwsxtxffw7pnTMq8yhgFiR9e6Tit/BAK9nBylpRWsfXZIdOd72ycjqt3uI8ZhN4FIicAqtwaQ== X-Received: by 2002:a05:600c:2053:b0:397:36f3:c95e with SMTP id p19-20020a05600c205300b0039736f3c95emr6940543wmg.185.1653656561818; Fri, 27 May 2022 06:02:41 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id l36-20020a05600c08a400b003942a244f48sm1932569wmp.33.2022.05.27.06.02.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 May 2022 06:02:41 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Luis Chamberlain , Theodore Ts'o , Leah Rumancik , Chandan Babu R , Adam Manzanares , Tyler Hicks , Jan Kara , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Kaixu Xia Subject: [PATCH 5.10 v2 2/5] xfs: show the proper user quota options Date: Fri, 27 May 2022 16:02:16 +0300 Message-Id: <20220527130219.3110260-3-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220527130219.3110260-1-amir73il@gmail.com> References: <20220527130219.3110260-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Kaixu Xia commit 237d7887ae723af7d978e8b9a385fdff416f357b upstream. The quota option 'usrquota' should be shown if both the XFS_UQUOTA_ACCT and XFS_UQUOTA_ENFD flags are set. The option 'uqnoenforce' should be shown when only the XFS_UQUOTA_ACCT flag is set. The current code logic seems wrong, Fix it and show proper options. Signed-off-by: Kaixu Xia Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein --- fs/xfs/xfs_super.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index e3e229e52512..5ebd6cdc44a7 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -199,10 +199,12 @@ xfs_fs_show_options( seq_printf(m, ",swidth=%d", (int)XFS_FSB_TO_BB(mp, mp->m_swidth)); - if (mp->m_qflags & (XFS_UQUOTA_ACCT|XFS_UQUOTA_ENFD)) - seq_puts(m, ",usrquota"); - else if (mp->m_qflags & XFS_UQUOTA_ACCT) - seq_puts(m, ",uqnoenforce"); + if (mp->m_qflags & XFS_UQUOTA_ACCT) { + if (mp->m_qflags & XFS_UQUOTA_ENFD) + seq_puts(m, ",usrquota"); + else + seq_puts(m, ",uqnoenforce"); + } if (mp->m_qflags & XFS_PQUOTA_ACCT) { if (mp->m_qflags & XFS_PQUOTA_ENFD) From patchwork Fri May 27 13:02:17 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12863335 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 BD5BFC433EF for ; Fri, 27 May 2022 13:02:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351652AbiE0NCt (ORCPT ); Fri, 27 May 2022 09:02:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238766AbiE0NCs (ORCPT ); Fri, 27 May 2022 09:02:48 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0CFB3BBF6; Fri, 27 May 2022 06:02:45 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id e2so5829558wrc.1; Fri, 27 May 2022 06:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=GX4MGgyF/rjjoLGNo+9vAqeePSGvpBNozK+r4g9/A+k=; b=WF5HqPxbrl/Q0v5xS46WO1rdGfy3EU8Ofaho5g9NSk0r5JGrIU41JYpKF3I4HTr8HD Yj+JGTfZeNs7XnviBu8b6O4DK6MvNBQepI8Ul1QIfni/dkmL1lT42rWxcrPpLJ6SiQau 6NHbwO/BYVcG5249uVPL/iFmNMP6QfGeVaBDmx3zXBLiPDQxU1oRAfldywMe+YOMACNU unfMV5VpqgFsGNT8s8FyXBlRGMW6jPk2Pe3rRkvZ4LOGq1cj6MnQsW6bMK88SZpdPF2f tArFk3Uhqr1vbZj6sH2aWpJbV4uxSH+nonJS4AVzJG0b3K2T2DfZv1FyCgk7tHMMgFPL V4rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=GX4MGgyF/rjjoLGNo+9vAqeePSGvpBNozK+r4g9/A+k=; b=OioIdla4XHvyfsKgOBhgBrj+eScesWMKrtmxi+yakK8ROBOfte07i4YQ+CvPqI0PGV hGwAqI1PvmuJfabV9BUo5gXWbJQUlCsWGADOS+P8aU/vdziC2GmfP4IOinFC2c4IC+Gk iHylbOQu5WXMeb7FuRjyyuZxY0os9qpSozeKUbuRsdHq+VMM3GqE6tR7+8nZL+lQuXmY ykeyKG00NG2zWxim9aVHqHxzeBOGsLVrztLcmcztF5LYv3IKbdg5N+4XWVJyB4pG40fL 1ivzoH4etnQmjaFrdNDk3RXNiE7d6EF1dsRpPJNFrq1c334mtgUy6P+liulONSqCXsiS dDtg== X-Gm-Message-State: AOAM530xfpFn98JslyPykhyTF9S1Yc/MwD82sUZ0rhaBjM0/kLfxd/kc 7XBURuqPatchCySA2i0OcU0= X-Google-Smtp-Source: ABdhPJy1q3PRNZwMMAFcy5ZRipoCnbeFWrR/Mu0fze51q6kG+gtQQO4yW+vNSHIcK0KgSJt1oBFUDg== X-Received: by 2002:adf:f145:0:b0:210:598:4042 with SMTP id y5-20020adff145000000b0021005984042mr7755494wro.139.1653656563929; Fri, 27 May 2022 06:02:43 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id l36-20020a05600c08a400b003942a244f48sm1932569wmp.33.2022.05.27.06.02.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 May 2022 06:02:43 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Luis Chamberlain , Theodore Ts'o , Leah Rumancik , Chandan Babu R , Adam Manzanares , Tyler Hicks , Jan Kara , linux-xfs@vger.kernel.org, stable@vger.kernel.org, zlang@redhat.com, Dave Chinner Subject: [PATCH 5.10 v2 3/5] xfs: fix the forward progress assertion in xfs_iwalk_run_callbacks Date: Fri, 27 May 2022 16:02:17 +0300 Message-Id: <20220527130219.3110260-4-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220527130219.3110260-1-amir73il@gmail.com> References: <20220527130219.3110260-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 a5336d6bb2d02d0e9d4d3c8be04b80b8b68d56c8 upstream. In commit 27c14b5daa82 we started tracking the last inode seen during an inode walk to avoid infinite loops if a corrupt inobt record happens to have a lower ir_startino than the record preceeding it. Unfortunately, the assertion trips over the case where there are completely empty inobt records (which can happen quite easily on 64k page filesystems) because we advance the tracking cursor without actually putting the empty record into the processing buffer. Fix the assert to allow for this case. Reported-by: zlang@redhat.com Fixes: 27c14b5daa82 ("xfs: ensure inobt record walks always make forward progress") Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang Reviewed-by: Dave Chinner Signed-off-by: Amir Goldstein --- fs/xfs/xfs_iwalk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/xfs_iwalk.c b/fs/xfs/xfs_iwalk.c index 2a45138831e3..eae3aff9bc97 100644 --- a/fs/xfs/xfs_iwalk.c +++ b/fs/xfs/xfs_iwalk.c @@ -363,7 +363,7 @@ xfs_iwalk_run_callbacks( /* Delete cursor but remember the last record we cached... */ xfs_iwalk_del_inobt(tp, curpp, agi_bpp, 0); irec = &iwag->recs[iwag->nr_recs - 1]; - ASSERT(next_agino == irec->ir_startino + XFS_INODES_PER_CHUNK); + ASSERT(next_agino >= irec->ir_startino + XFS_INODES_PER_CHUNK); error = xfs_iwalk_ag_recs(iwag); if (error) From patchwork Fri May 27 13:02:18 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12863336 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 A460EC4332F for ; Fri, 27 May 2022 13:02:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351718AbiE0NCt (ORCPT ); Fri, 27 May 2022 09:02:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351708AbiE0NCt (ORCPT ); Fri, 27 May 2022 09:02:49 -0400 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D10BA3D1CA; Fri, 27 May 2022 06:02:47 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id t13so5782271wrg.9; Fri, 27 May 2022 06:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=JLC0ja767iUSkq7vhFyAS50rOOoNLE8fxflV1RxjsDw=; b=Ce6wcdcXt1TAE8vflH0kt2qVCXUEDquQRzoIk1QsLPSGKJrxv3/TWyDqkldiZiWz0i k8BmU2cHFMYpYIz7l/TmmHqM4jECDfOmJDkNpEnSV1UYyVN1PwGyjkOT1sFLztdxuf7j 03V0sclyQft903HsVmOJyNBGyJkQM0BQ14QvteT6NOt384n6wmrEAFffIkYzFpiIBADj VbIWdsAnwG+4FO8kXzCPL/xz9Eb0/wvN9KzgOtWNWbRmy9qwdujT4zn5Cqcy6qEhHy3g 4+5AgZiSQwx0RQSCSK635GjjPyUPTpUjkH66gAVXE/iAC+1EsH7aVDhVhJdROlx8mR+/ zfsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JLC0ja767iUSkq7vhFyAS50rOOoNLE8fxflV1RxjsDw=; b=45gzbWS2yG3VVVCbA8F2IhVnbxtgS+6hupEzX/rhOKG5lelpuz+4vg9U8R0+S2b266 GK4uQZgHagtj/JH6xxbPX+DnPfzlYczkBdSqb4azmww7x8QLlFIOKDrarh9nYERu18kS MADukhc9+zpRdTC9JBJg+NeuItvydJzpVI3Lbp4SB/xNK+Q8Qjyuo8LhYlK0YOVDmN0V 0jF6HjUvZsQGbPYhnV7U5/p/I1GktCA0vMd2Oie0ZERZDlMb/eJUbnmgYA5bWadRhXsv 8GBNJkc0DKyVxpTuSn8BEWVD2Q4H7XZEXObIw7Os8XpNpO4kiPo0D5S/eUWBGROB94UV ylXw== X-Gm-Message-State: AOAM530Wje47LQprJmMgsdrqGHTfzPn2iaEO++/ikdRq0rCsS+5st0s7 dTbs3ZqhPM+C4AAfcJ34DfA= X-Google-Smtp-Source: ABdhPJyGfv0GNalT3vaY58hB+nHmb/F/PaoEmeY5GqBbuarpYL5V3V1J4FYuHWh3NQwVeXwyIPLoSA== X-Received: by 2002:a05:6000:791:b0:20e:615c:aae4 with SMTP id bu17-20020a056000079100b0020e615caae4mr35246264wrb.206.1653656566234; Fri, 27 May 2022 06:02:46 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id l36-20020a05600c08a400b003942a244f48sm1932569wmp.33.2022.05.27.06.02.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 May 2022 06:02:45 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Luis Chamberlain , Theodore Ts'o , Leah Rumancik , Chandan Babu R , Adam Manzanares , Tyler Hicks , Jan Kara , linux-xfs@vger.kernel.org, stable@vger.kernel.org, wenli xie , Brian Foster Subject: [PATCH 5.10 v2 4/5] xfs: fix an ABBA deadlock in xfs_rename Date: Fri, 27 May 2022 16:02:18 +0300 Message-Id: <20220527130219.3110260-5-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220527130219.3110260-1-amir73il@gmail.com> References: <20220527130219.3110260-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 6da1b4b1ab36d80a3994fd4811c8381de10af604 upstream. When overlayfs is running on top of xfs and the user unlinks a file in the overlay, overlayfs will create a whiteout inode and ask xfs to "rename" the whiteout file atop the one being unlinked. If the file being unlinked loses its one nlink, we then have to put the inode on the unlinked list. This requires us to grab the AGI buffer of the whiteout inode to take it off the unlinked list (which is where whiteouts are created) and to grab the AGI buffer of the file being deleted. If the whiteout was created in a higher numbered AG than the file being deleted, we'll lock the AGIs in the wrong order and deadlock. Therefore, grab all the AGI locks we think we'll need ahead of time, and in order of increasing AG number per the locking rules. Reported-by: wenli xie Fixes: 93597ae8dac0 ("xfs: Fix deadlock between AGI and AGF when target_ip exists in xfs_rename()") Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster Signed-off-by: Amir Goldstein --- fs/xfs/libxfs/xfs_dir2.h | 2 -- fs/xfs/libxfs/xfs_dir2_sf.c | 2 +- fs/xfs/xfs_inode.c | 42 ++++++++++++++++++++++--------------- 3 files changed, 26 insertions(+), 20 deletions(-) diff --git a/fs/xfs/libxfs/xfs_dir2.h b/fs/xfs/libxfs/xfs_dir2.h index e55378640b05..d03e6098ded9 100644 --- a/fs/xfs/libxfs/xfs_dir2.h +++ b/fs/xfs/libxfs/xfs_dir2.h @@ -47,8 +47,6 @@ extern int xfs_dir_lookup(struct xfs_trans *tp, struct xfs_inode *dp, extern int xfs_dir_removename(struct xfs_trans *tp, struct xfs_inode *dp, struct xfs_name *name, xfs_ino_t ino, xfs_extlen_t tot); -extern bool xfs_dir2_sf_replace_needblock(struct xfs_inode *dp, - xfs_ino_t inum); extern int xfs_dir_replace(struct xfs_trans *tp, struct xfs_inode *dp, struct xfs_name *name, xfs_ino_t inum, xfs_extlen_t tot); diff --git a/fs/xfs/libxfs/xfs_dir2_sf.c b/fs/xfs/libxfs/xfs_dir2_sf.c index 2463b5d73447..8c4f76bba88b 100644 --- a/fs/xfs/libxfs/xfs_dir2_sf.c +++ b/fs/xfs/libxfs/xfs_dir2_sf.c @@ -1018,7 +1018,7 @@ xfs_dir2_sf_removename( /* * Check whether the sf dir replace operation need more blocks. */ -bool +static bool xfs_dir2_sf_replace_needblock( struct xfs_inode *dp, xfs_ino_t inum) diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index 2bfbcf28b1bd..e958b1c74561 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -3152,7 +3152,7 @@ xfs_rename( struct xfs_trans *tp; struct xfs_inode *wip = NULL; /* whiteout inode */ struct xfs_inode *inodes[__XFS_SORT_INODES]; - struct xfs_buf *agibp; + int i; int num_inodes = __XFS_SORT_INODES; bool new_parent = (src_dp != target_dp); bool src_is_directory = S_ISDIR(VFS_I(src_ip)->i_mode); @@ -3265,6 +3265,30 @@ xfs_rename( } } + /* + * Lock the AGI buffers we need to handle bumping the nlink of the + * whiteout inode off the unlinked list and to handle dropping the + * nlink of the target inode. Per locking order rules, do this in + * increasing AG order and before directory block allocation tries to + * grab AGFs because we grab AGIs before AGFs. + * + * The (vfs) caller must ensure that if src is a directory then + * target_ip is either null or an empty directory. + */ + for (i = 0; i < num_inodes && inodes[i] != NULL; i++) { + if (inodes[i] == wip || + (inodes[i] == target_ip && + (VFS_I(target_ip)->i_nlink == 1 || src_is_directory))) { + struct xfs_buf *bp; + xfs_agnumber_t agno; + + agno = XFS_INO_TO_AGNO(mp, inodes[i]->i_ino); + error = xfs_read_agi(mp, tp, agno, &bp); + if (error) + goto out_trans_cancel; + } + } + /* * Directory entry creation below may acquire the AGF. Remove * the whiteout from the unlinked list first to preserve correct @@ -3317,22 +3341,6 @@ xfs_rename( * In case there is already an entry with the same * name at the destination directory, remove it first. */ - - /* - * Check whether the replace operation will need to allocate - * blocks. This happens when the shortform directory lacks - * space and we have to convert it to a block format directory. - * When more blocks are necessary, we must lock the AGI first - * to preserve locking order (AGI -> AGF). - */ - if (xfs_dir2_sf_replace_needblock(target_dp, src_ip->i_ino)) { - error = xfs_read_agi(mp, tp, - XFS_INO_TO_AGNO(mp, target_ip->i_ino), - &agibp); - if (error) - goto out_trans_cancel; - } - error = xfs_dir_replace(tp, target_dp, target_name, src_ip->i_ino, spaceres); if (error) From patchwork Fri May 27 13:02:19 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 12863337 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 AEC3EC433FE for ; Fri, 27 May 2022 13:02:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351675AbiE0NCw (ORCPT ); Fri, 27 May 2022 09:02:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351708AbiE0NCw (ORCPT ); Fri, 27 May 2022 09:02:52 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C3A112775; Fri, 27 May 2022 06:02:50 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id h11so2075884wrb.0; Fri, 27 May 2022 06:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=awDlFL+bYrWYCpmdDy8d4vZm/t1y9I17P2EbBw7saVA=; b=FUeZElUhH19V2GJPnZdvy7a075a9NzFq3aWU8zWRbPz3e+psiKDQu7I9GevfY/92Ct 3JGg+RTekbkIW6vapm/9DcYJK0wlvh99dDe/4CfnWcoQrfTStjZ6NDT7Oq7ff3M78uia 7XF9LFZ689ehOkmbxjkw2Lwub7U7Lj8x88QKG9JZjYpAMbl6GJFFteGO/LfN0A8p5J9g IP82sBZi8zshUaN4pheuCmjdR6KpMBxZdAi2XM2pxzRCL/ldJDALfs8rBaVtxVbGEci3 JdRXZQ0TMYtgxWScmZSKDF+L9AOTOJt52ZWQTyGG9Ccgg9nwXJYR6s+Pcqc2JglNr3qz DA9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=awDlFL+bYrWYCpmdDy8d4vZm/t1y9I17P2EbBw7saVA=; b=5F/Ehp9Qqn26C0I9aA42lk4wJsOtOOv9wjbQnhSawO/9v+1E3sv/eVplxEEDNZv76z V1GfMAVshCKuSr5v+jgiis5aht7rZ0DtGkqL9GJoOAkdtDBAYfGvXbTgXIH9n61SxzVV FfCNQIQcImziqCmhIg5/1NyJNXoRJYkoV/fKRYwwLYUtbXVjvI8tH1bMrmy8OG/vIYLB gcRrTBb8t3SXDHhWROmB/r2VA6GAAnGHEPaQN7GTQoHV0lr7n/8IwTCid2Ot81+ZHqKq mFvgdNHJ9uF+fMoPwk1uwYz+xR4+APKu/TAaAcLbT7Jj5Q4mWAxW/XMzmiLhMBD0ooNc liTA== X-Gm-Message-State: AOAM5326AJb2CzaINnOoctQrUQ+0zDYzRh13xUhYcONkMLvjSdMfvsVj bbSUQ94bZC7YP7seBD1ziY8RS8ht2IQEgKO7 X-Google-Smtp-Source: ABdhPJzRwa2zCPmWPGrgLkyIau4FZN7ampo7iIuQPtwohObZRbrJBnqlD5rXTHD5pnBLyPSpRf5a3g== X-Received: by 2002:adf:f20a:0:b0:20f:fcf7:b07f with SMTP id p10-20020adff20a000000b0020ffcf7b07fmr11108034wro.476.1653656568834; Fri, 27 May 2022 06:02:48 -0700 (PDT) Received: from amir-ThinkPad-T480.lan ([77.137.79.96]) by smtp.gmail.com with ESMTPSA id l36-20020a05600c08a400b003942a244f48sm1932569wmp.33.2022.05.27.06.02.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 May 2022 06:02:48 -0700 (PDT) From: Amir Goldstein To: Greg Kroah-Hartman Cc: Sasha Levin , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Luis Chamberlain , Theodore Ts'o , Leah Rumancik , Chandan Babu R , Adam Manzanares , Tyler Hicks , Jan Kara , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner , Donald Buczek , Brian Foster , Chandan Babu R , "Darrick J . Wong" , Allison Henderson Subject: [PATCH 5.10 v2 5/5] xfs: Fix CIL throttle hang when CIL space used going backwards Date: Fri, 27 May 2022 16:02:19 +0300 Message-Id: <20220527130219.3110260-6-amir73il@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220527130219.3110260-1-amir73il@gmail.com> References: <20220527130219.3110260-1-amir73il@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner commit 19f4e7cc819771812a7f527d7897c2deffbf7a00 upstream. A hang with tasks stuck on the CIL hard throttle was reported and largely diagnosed by Donald Buczek, who discovered that it was a result of the CIL context space usage decrementing in committed transactions once the hard throttle limit had been hit and processes were already blocked. This resulted in the CIL push not waking up those waiters because the CIL context was no longer over the hard throttle limit. The surprising aspect of this was the CIL space usage going backwards regularly enough to trigger this situation. Assumptions had been made in design that the relogging process would only increase the size of the objects in the CIL, and so that space would only increase. This change and commit message fixes the issue and documents the result of an audit of the triggers that can cause the CIL space to go backwards, how large the backwards steps tend to be, the frequency in which they occur, and what the impact on the CIL accounting code is. Even though the CIL ctx->space_used can go backwards, it will only do so if the log item is already logged to the CIL and contains a space reservation for it's entire logged state. This is tracked by the shadow buffer state on the log item. If the item is not previously logged in the CIL it has no shadow buffer nor log vector, and hence the entire size of the logged item copied to the log vector is accounted to the CIL space usage. i.e. it will always go up in this case. If the item has a log vector (i.e. already in the CIL) and the size decreases, then the existing log vector will be overwritten and the space usage will go down. This is the only condition where the space usage reduces, and it can only occur when an item is already tracked in the CIL. Hence we are safe from CIL space usage underruns as a result of log items decreasing in size when they are relogged. Typically this reduction in CIL usage occurs from metadata blocks being free, such as when a btree block merge occurs or a directory enter/xattr entry is removed and the da-tree is reduced in size. This generally results in a reduction in size of around a single block in the CIL, but also tends to increase the number of log vectors because the parent and sibling nodes in the tree needs to be updated when a btree block is removed. If a multi-level merge occurs, then we see reduction in size of 2+ blocks, but again the log vector count goes up. The other vector is inode fork size changes, which only log the current size of the fork and ignore the previously logged size when the fork is relogged. Hence if we are removing items from the inode fork (dir/xattr removal in shortform, extent record removal in extent form, etc) the relogged size of the inode for can decrease. No other log items can decrease in size either because they are a fixed size (e.g. dquots) or they cannot be relogged (e.g. relogging an intent actually creates a new intent log item and doesn't relog the old item at all.) Hence the only two vectors for CIL context size reduction are relogging inode forks and marking buffers active in the CIL as stale. Long story short: the majority of the code does the right thing and handles the reduction in log item size correctly, and only the CIL hard throttle implementation is problematic and needs fixing. This patch makes that fix, as well as adds comments in the log item code that result in items shrinking in size when they are relogged as a clear reminder that this can and does happen frequently. The throttle fix is based upon the change Donald proposed, though it goes further to ensure that once the throttle is activated, it captures all tasks until the CIL push issues a wakeup, regardless of whether the CIL space used has gone back under the throttle threshold. This ensures that we prevent tasks reducing the CIL slightly under the throttle threshold and then making more changes that push it well over the throttle limit. This is acheived by checking if the throttle wait queue is already active as a condition of throttling. Hence once we start throttling, we continue to apply the throttle until the CIL context push wakes everything on the wait queue. We can use waitqueue_active() for the waitqueue manipulations and checks as they are all done under the ctx->xc_push_lock. Hence the waitqueue has external serialisation and we can safely peek inside the wait queue without holding the internal waitqueue locks. Many thanks to Donald for his diagnostic and analysis work to isolate the cause of this hang. Reported-and-tested-by: Donald Buczek Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Chandan Babu R Reviewed-by: Darrick J. Wong Reviewed-by: Allison Henderson Signed-off-by: Darrick J. Wong Signed-off-by: Christoph Hellwig --- fs/xfs/xfs_buf_item.c | 37 ++++++++++++++++++------------------- fs/xfs/xfs_inode_item.c | 14 ++++++++++++++ fs/xfs/xfs_log_cil.c | 22 +++++++++++++++++----- 3 files changed, 49 insertions(+), 24 deletions(-) diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c index 0356f2e340a1..8c6e26d62ef2 100644 --- a/fs/xfs/xfs_buf_item.c +++ b/fs/xfs/xfs_buf_item.c @@ -56,14 +56,12 @@ xfs_buf_log_format_size( } /* - * This returns the number of log iovecs needed to log the - * given buf log item. + * Return the number of log iovecs and space needed to log the given buf log + * item segment. * - * It calculates this as 1 iovec for the buf log format structure - * and 1 for each stretch of non-contiguous chunks to be logged. - * Contiguous chunks are logged in a single iovec. - * - * If the XFS_BLI_STALE flag has been set, then log nothing. + * It calculates this as 1 iovec for the buf log format structure and 1 for each + * stretch of non-contiguous chunks to be logged. Contiguous chunks are logged + * in a single iovec. */ STATIC void xfs_buf_item_size_segment( @@ -119,11 +117,8 @@ xfs_buf_item_size_segment( } /* - * This returns the number of log iovecs needed to log the given buf log item. - * - * It calculates this as 1 iovec for the buf log format structure and 1 for each - * stretch of non-contiguous chunks to be logged. Contiguous chunks are logged - * in a single iovec. + * Return the number of log iovecs and space needed to log the given buf log + * item. * * Discontiguous buffers need a format structure per region that is being * logged. This makes the changes in the buffer appear to log recovery as though @@ -133,7 +128,11 @@ xfs_buf_item_size_segment( * what ends up on disk. * * If the XFS_BLI_STALE flag has been set, then log nothing but the buf log - * format structures. + * format structures. If the item has previously been logged and has dirty + * regions, we do not relog them in stale buffers. This has the effect of + * reducing the size of the relogged item by the amount of dirty data tracked + * by the log item. This can result in the committing transaction reducing the + * amount of space being consumed by the CIL. */ STATIC void xfs_buf_item_size( @@ -147,9 +146,9 @@ xfs_buf_item_size( ASSERT(atomic_read(&bip->bli_refcount) > 0); if (bip->bli_flags & XFS_BLI_STALE) { /* - * The buffer is stale, so all we need to log - * is the buf log format structure with the - * cancel flag in it. + * The buffer is stale, so all we need to log is the buf log + * format structure with the cancel flag in it as we are never + * going to replay the changes tracked in the log item. */ trace_xfs_buf_item_size_stale(bip); ASSERT(bip->__bli_format.blf_flags & XFS_BLF_CANCEL); @@ -164,9 +163,9 @@ xfs_buf_item_size( if (bip->bli_flags & XFS_BLI_ORDERED) { /* - * The buffer has been logged just to order it. - * It is not being included in the transaction - * commit, so no vectors are used at all. + * The buffer has been logged just to order it. It is not being + * included in the transaction commit, so no vectors are used at + * all. */ trace_xfs_buf_item_size_ordered(bip); *nvecs = XFS_LOG_VEC_ORDERED; diff --git a/fs/xfs/xfs_inode_item.c b/fs/xfs/xfs_inode_item.c index 17e20a6d8b4e..6ff91e5bf3cd 100644 --- a/fs/xfs/xfs_inode_item.c +++ b/fs/xfs/xfs_inode_item.c @@ -28,6 +28,20 @@ static inline struct xfs_inode_log_item *INODE_ITEM(struct xfs_log_item *lip) return container_of(lip, struct xfs_inode_log_item, ili_item); } +/* + * The logged size of an inode fork is always the current size of the inode + * fork. This means that when an inode fork is relogged, the size of the logged + * region is determined by the current state, not the combination of the + * previously logged state + the current state. This is different relogging + * behaviour to most other log items which will retain the size of the + * previously logged changes when smaller regions are relogged. + * + * Hence operations that remove data from the inode fork (e.g. shortform + * dir/attr remove, extent form extent removal, etc), the size of the relogged + * inode gets -smaller- rather than stays the same size as the previously logged + * size and this can result in the committing transaction reducing the amount of + * space being consumed by the CIL. + */ STATIC void xfs_inode_item_data_fork_size( struct xfs_inode_log_item *iip, diff --git a/fs/xfs/xfs_log_cil.c b/fs/xfs/xfs_log_cil.c index b0ef071b3cb5..cd5c04dabe2e 100644 --- a/fs/xfs/xfs_log_cil.c +++ b/fs/xfs/xfs_log_cil.c @@ -668,9 +668,14 @@ xlog_cil_push_work( ASSERT(push_seq <= ctx->sequence); /* - * Wake up any background push waiters now this context is being pushed. + * As we are about to switch to a new, empty CIL context, we no longer + * need to throttle tasks on CIL space overruns. Wake any waiters that + * the hard push throttle may have caught so they can start committing + * to the new context. The ctx->xc_push_lock provides the serialisation + * necessary for safely using the lockless waitqueue_active() check in + * this context. */ - if (ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log)) + if (waitqueue_active(&cil->xc_push_wait)) wake_up_all(&cil->xc_push_wait); /* @@ -907,7 +912,7 @@ xlog_cil_push_background( ASSERT(!list_empty(&cil->xc_cil)); /* - * don't do a background push if we haven't used up all the + * Don't do a background push if we haven't used up all the * space available yet. */ if (cil->xc_ctx->space_used < XLOG_CIL_SPACE_LIMIT(log)) { @@ -931,9 +936,16 @@ xlog_cil_push_background( /* * If we are well over the space limit, throttle the work that is being - * done until the push work on this context has begun. + * done until the push work on this context has begun. Enforce the hard + * throttle on all transaction commits once it has been activated, even + * if the committing transactions have resulted in the space usage + * dipping back down under the hard limit. + * + * The ctx->xc_push_lock provides the serialisation necessary for safely + * using the lockless waitqueue_active() check in this context. */ - if (cil->xc_ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log)) { + if (cil->xc_ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log) || + waitqueue_active(&cil->xc_push_wait)) { trace_xfs_log_cil_wait(log, cil->xc_ctx->ticket); ASSERT(cil->xc_ctx->space_used < log->l_logsize); xlog_wait(&cil->xc_push_wait, &cil->xc_push_lock);