From patchwork Fri Aug 19 18:14:23 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 12949061 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 5F4D3C32773 for ; Fri, 19 Aug 2022 18:15:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349825AbiHSSPt (ORCPT ); Fri, 19 Aug 2022 14:15:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350397AbiHSSP1 (ORCPT ); Fri, 19 Aug 2022 14:15:27 -0400 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 256E51C92C; Fri, 19 Aug 2022 11:14:39 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id x23so4784587pll.7; Fri, 19 Aug 2022 11:14:39 -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=pftLU29xMcYVd4FlVJDw7N6M2k1bSEeTfLrx5irx0dE=; b=StOsznHxXSwtAmfQ1OuRRZjX5sJ8iYXa3jlwHdJgayOv3kNDis15T6dLfYImDV/4rE Gq/7kfBFLmNmO4sh0qPWZZuZTebji9r4ySKuXEhbDqa8OjHZMzeRD1312rE5Jm4D6dfp +mh+ibaGXm94UITwZzfvOpq2xU57OOSVHD8fb2bq/JIRKPUjClNyhLDyHBOy0eYBt11e uED1I3LrFPxoe/zNtGy5eBGCUdqUdIScPfp+p6eCIWbYJ+Wr4iIUt6NzsB01jeyv07/G XTC84egAamLjgeqgOnLGj0jJ9JCrZ5TmctQmnaRJ7bwGdHooIWBRMi6y/gaigFaKEz+s ECXQ== 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=pftLU29xMcYVd4FlVJDw7N6M2k1bSEeTfLrx5irx0dE=; b=U7PCIt8aSF4y4kKRz8RKD2nsH0hXb4wU1F8zTn+eL3Psm7NHpVh1sTtMZ+NSUnXcO6 V6ViLLqsR5JRw+Aihb9oomwsrXs4KNzynJQNknLguTsjcQ5C/ld7JFYf9IEut9t1wRJe 6RBQaMqD8VyNXV5E/+gmP1krA1s6ZGj240Z18UqPe6ATwAkfyPtEOsT0vsEQVgKvevF/ 6Mid2PvcyWoemWMdBZCxl7c6xpbCOYL8LW6Baj0qg7kUMpNxm2lZ/ijW5GDZ5QWWnMqm 7ah9JGu3lQDZyUqn3hFCeTQ5RIOxADVsNHNZERtG3KRAW6/yeKrziCxotXkjhjErW4A2 sXsQ== X-Gm-Message-State: ACgBeo17Tp/EwBVTr9y/KZdtRo5FHtYDOLcxMYiUZ1gxYGugZQoJmAmu AlBvDDZ9mT96RQhQvxDyVEcYr/UPFaqyLA== X-Google-Smtp-Source: AA6agR4X16QF3zT5pcI1/z4USbvMsLDqicRXRZXly7VpHXXc2nBYGpENm7D8hozbbUs9TlSvVYBOAQ== X-Received: by 2002:a17:90a:5d8a:b0:1f7:3c7a:9cc7 with SMTP id t10-20020a17090a5d8a00b001f73c7a9cc7mr9761216pji.207.1660932878328; Fri, 19 Aug 2022 11:14:38 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:3995:f9b1:1e6b:e373]) by smtp.gmail.com with ESMTPSA id t14-20020a170902e84e00b0015ee60ef65bsm3460918plg.260.2022.08.19.11.14.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 11:14:38 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, Brian Foster , "Darrick J . Wong" , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 1/9] xfs: flush inodegc workqueue tasks before cancel Date: Fri, 19 Aug 2022 11:14:23 -0700 Message-Id: <20220819181431.4113819-2-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog In-Reply-To: <20220819181431.4113819-1-leah.rumancik@gmail.com> References: <20220819181431.4113819-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Brian Foster [ Upstream commit 6191cf3ad59fda5901160633fef8e41b064a5246 ] The xfs_inodegc_stop() helper performs a high level flush of pending work on the percpu queues and then runs a cancel_work_sync() on each of the percpu work tasks to ensure all work has completed before returning. While cancel_work_sync() waits for wq tasks to complete, it does not guarantee work tasks have started. This means that the _stop() helper can queue and instantly cancel a wq task without having completed the associated work. This can be observed by tracepoint inspection of a simple "rm -f ; fsfreeze -f " test: xfs_destroy_inode: ... ino 0x83 ... xfs_inode_set_need_inactive: ... ino 0x83 ... xfs_inodegc_stop: ... ... xfs_inodegc_start: ... xfs_inodegc_worker: ... xfs_inode_inactivating: ... ino 0x83 ... The first few lines show that the inode is removed and need inactive state set, but the inactivation work has not completed before the inodegc mechanism stops. The inactivation doesn't actually occur until the fs is unfrozen and the gc mechanism starts back up. Note that this test requires fsfreeze to reproduce because xfs_freeze indirectly invokes xfs_fs_statfs(), which calls xfs_inodegc_flush(). When this occurs, the workqueue try_to_grab_pending() logic first tries to steal the pending bit, which does not succeed because the bit has been set by queue_work_on(). Subsequently, it checks for association of a pool workqueue from the work item under the pool lock. This association is set at the point a work item is queued and cleared when dequeued for processing. If the association exists, the work item is removed from the queue and cancel_work_sync() returns true. If the pwq association is cleared, the remove attempt assumes the task is busy and retries (eventually returning false to the caller after waiting for the work task to complete). To avoid this race, we can flush each work item explicitly before cancel. However, since the _queue_all() already schedules each underlying work item, the workqueue level helpers are sufficient to achieve the same ordering effect. E.g., the inodegc enabled flag prevents scheduling any further work in the _stop() case. Use the drain_workqueue() helper in this particular case to make the intent a bit more self explanatory. Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/xfs_icache.c | 22 ++++------------------ 1 file changed, 4 insertions(+), 18 deletions(-) diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index f2210d927481..5e44d7bbd8fc 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -1872,28 +1872,20 @@ xfs_inodegc_worker( } /* - * Force all currently queued inode inactivation work to run immediately, and - * wait for the work to finish. Two pass - queue all the work first pass, wait - * for it in a second pass. + * Force all currently queued inode inactivation work to run immediately and + * wait for the work to finish. */ void xfs_inodegc_flush( struct xfs_mount *mp) { - struct xfs_inodegc *gc; - int cpu; - if (!xfs_is_inodegc_enabled(mp)) return; trace_xfs_inodegc_flush(mp, __return_address); xfs_inodegc_queue_all(mp); - - for_each_online_cpu(cpu) { - gc = per_cpu_ptr(mp->m_inodegc, cpu); - flush_work(&gc->work); - } + flush_workqueue(mp->m_inodegc_wq); } /* @@ -1904,18 +1896,12 @@ void xfs_inodegc_stop( struct xfs_mount *mp) { - struct xfs_inodegc *gc; - int cpu; - if (!xfs_clear_inodegc_enabled(mp)) return; xfs_inodegc_queue_all(mp); + drain_workqueue(mp->m_inodegc_wq); - for_each_online_cpu(cpu) { - gc = per_cpu_ptr(mp->m_inodegc, cpu); - cancel_work_sync(&gc->work); - } trace_xfs_inodegc_stop(mp, __return_address); } From patchwork Fri Aug 19 18:14:24 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 12949062 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 1F9B1C28B2B for ; Fri, 19 Aug 2022 18:15:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349902AbiHSSPv (ORCPT ); Fri, 19 Aug 2022 14:15:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45488 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350573AbiHSSP2 (ORCPT ); Fri, 19 Aug 2022 14:15:28 -0400 Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA0F92DC6; Fri, 19 Aug 2022 11:14:40 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id 12so4296322pga.1; Fri, 19 Aug 2022 11:14:40 -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=zyEmZ6pSXSCb2FIby9CbhEWVxXTomK0HClRyYX/LZAo=; b=cSUzeR5nplM760GgjUDWnSXnwFRwPvLZKSwVljnDX0dNWn8DuxvBoygPVuyXWuel93 rZvoXpicV0O7O8cNGRCB2IIPn60X//26ORwXwpoI44hA/SyIagbVehDrWNvx5bwSCnyS WaK0Pw6nWsoSpS5fTH2PnDBEdKMEvWmjUYHgyW8L9a8d9zJd/2fxX+HqqdvFZLu3hpY/ H0mdiPVvWQE/2/MAF6SUbgQGB10WszZjpNPdJ5qIqR+JWXge4gdxI+/pHuGFrITLSiUN GgUxPhPATekp6ZKxtcy+DRqphMaIGfncrIpRfrxQR6PcogzXeAQUZM4QukxWvWLpHYhM 7/Sw== 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=zyEmZ6pSXSCb2FIby9CbhEWVxXTomK0HClRyYX/LZAo=; b=gJEEwiCY1nCG9EbuV28e0okP0X7BtUgd1zTW3JkOJ2wOA+/hQTR/NyBsAz/m3kKsHe 8IvA3OhKix+Oxh9PUCRrrB+g0qS2x45PggUFbbmtrYtUXLe+cmV/d4WAVQkGr6e7I1kB 81SiW0atVNQimVR2oLXCWFFDo14zHvvkFJaqR4vB6mnt9BEEnK1L9Gr02Y0vyzoZtf9M gsSpcJFEek76KXBtG47DjPAJOMbadKrzQmhrIujLELIFS25CCZ/oq/0SZn1J/ZQyr85n /zpICwuIxbM4yplrbjYWsutwaxcA9ocTP4x4V61a0lQAy5+494Sds+UKH9o/ODNVY8r8 4XjQ== X-Gm-Message-State: ACgBeo2DC7uTEPUu71QZCX9LKu2rDz9rYFvKoR7fepYC6ozo4digMs3H X3zvl2atTjZnq5OYgX6jI/YwuORGNOf00Q== X-Google-Smtp-Source: AA6agR46jbe9Ef5h6xd8p/t2t1VjRmZR/p7vyOA4Il6KRg3u1FEuJcg8NuBJAkS8ap2cfKDUCSuNSQ== X-Received: by 2002:a63:64a:0:b0:429:8c1a:81a2 with SMTP id 71-20020a63064a000000b004298c1a81a2mr6814032pgg.503.1660932879803; Fri, 19 Aug 2022 11:14:39 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:3995:f9b1:1e6b:e373]) by smtp.gmail.com with ESMTPSA id t14-20020a170902e84e00b0015ee60ef65bsm3460918plg.260.2022.08.19.11.14.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 11:14:39 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, "Darrick J. Wong" , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 2/9] xfs: reserve quota for dir expansion when linking/unlinking files Date: Fri, 19 Aug 2022 11:14:24 -0700 Message-Id: <20220819181431.4113819-3-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog In-Reply-To: <20220819181431.4113819-1-leah.rumancik@gmail.com> References: <20220819181431.4113819-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: "Darrick J. Wong" [ Upstream commit 871b9316e7a778ff97bdc34fdb2f2977f616651d ] XFS does not reserve quota for directory expansion when linking or unlinking children from a directory. This means that we don't reject the expansion with EDQUOT when we're at or near a hard limit, which means that unprivileged userspace can use link()/unlink() to exceed quota. The fix for this is nuanced -- link operations don't always expand the directory, and we allow a link to proceed with no space reservation if we don't need to add a block to the directory to handle the addition. Unlink operations generally do not expand the directory (you'd have to free a block and then cause a btree split) and we can defer the directory block freeing if there is no space reservation. Moreover, there is a further bug in that we do not trigger the blockgc workers to try to clear space when we're out of quota. To fix both cases, create a new xfs_trans_alloc_dir function that allocates the transaction, locks and joins the inodes, and reserves quota for the directory. If there isn't sufficient space or quota, we'll switch the caller to reservationless mode. This should prevent quota usage overruns with the least restriction in functionality. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/xfs_inode.c | 46 +++++++++---------------- fs/xfs/xfs_trans.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_trans.h | 3 ++ 3 files changed, 106 insertions(+), 29 deletions(-) diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index c19f3ca605af..f4dec7f6c6d0 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -1223,7 +1223,7 @@ xfs_link( { xfs_mount_t *mp = tdp->i_mount; xfs_trans_t *tp; - int error; + int error, nospace_error = 0; int resblks; trace_xfs_link(tdp, target_name); @@ -1242,19 +1242,11 @@ xfs_link( goto std_return; resblks = XFS_LINK_SPACE_RES(mp, target_name->len); - error = xfs_trans_alloc(mp, &M_RES(mp)->tr_link, resblks, 0, 0, &tp); - if (error == -ENOSPC) { - resblks = 0; - error = xfs_trans_alloc(mp, &M_RES(mp)->tr_link, 0, 0, 0, &tp); - } + error = xfs_trans_alloc_dir(tdp, &M_RES(mp)->tr_link, sip, &resblks, + &tp, &nospace_error); if (error) goto std_return; - xfs_lock_two_inodes(sip, XFS_ILOCK_EXCL, tdp, XFS_ILOCK_EXCL); - - xfs_trans_ijoin(tp, sip, XFS_ILOCK_EXCL); - xfs_trans_ijoin(tp, tdp, XFS_ILOCK_EXCL); - error = xfs_iext_count_may_overflow(tdp, XFS_DATA_FORK, XFS_IEXT_DIR_MANIP_CNT(mp)); if (error) @@ -1312,6 +1304,8 @@ xfs_link( error_return: xfs_trans_cancel(tp); std_return: + if (error == -ENOSPC && nospace_error) + error = nospace_error; return error; } @@ -2761,6 +2755,7 @@ xfs_remove( xfs_mount_t *mp = dp->i_mount; xfs_trans_t *tp = NULL; int is_dir = S_ISDIR(VFS_I(ip)->i_mode); + int dontcare; int error = 0; uint resblks; @@ -2778,31 +2773,24 @@ xfs_remove( goto std_return; /* - * We try to get the real space reservation first, - * allowing for directory btree deletion(s) implying - * possible bmap insert(s). If we can't get the space - * reservation then we use 0 instead, and avoid the bmap - * btree insert(s) in the directory code by, if the bmap - * insert tries to happen, instead trimming the LAST - * block from the directory. + * We try to get the real space reservation first, allowing for + * directory btree deletion(s) implying possible bmap insert(s). If we + * can't get the space reservation then we use 0 instead, and avoid the + * bmap btree insert(s) in the directory code by, if the bmap insert + * tries to happen, instead trimming the LAST block from the directory. + * + * Ignore EDQUOT and ENOSPC being returned via nospace_error because + * the directory code can handle a reservationless update and we don't + * want to prevent a user from trying to free space by deleting things. */ resblks = XFS_REMOVE_SPACE_RES(mp); - error = xfs_trans_alloc(mp, &M_RES(mp)->tr_remove, resblks, 0, 0, &tp); - if (error == -ENOSPC) { - resblks = 0; - error = xfs_trans_alloc(mp, &M_RES(mp)->tr_remove, 0, 0, 0, - &tp); - } + error = xfs_trans_alloc_dir(dp, &M_RES(mp)->tr_remove, ip, &resblks, + &tp, &dontcare); if (error) { ASSERT(error != -ENOSPC); goto std_return; } - xfs_lock_two_inodes(dp, XFS_ILOCK_EXCL, ip, XFS_ILOCK_EXCL); - - xfs_trans_ijoin(tp, dp, XFS_ILOCK_EXCL); - xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); - /* * If we're removing a directory perform some additional validation. */ diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c index 67dec11e34c7..95c183072e7a 100644 --- a/fs/xfs/xfs_trans.c +++ b/fs/xfs/xfs_trans.c @@ -1201,3 +1201,89 @@ xfs_trans_alloc_ichange( xfs_trans_cancel(tp); return error; } + +/* + * Allocate an transaction, lock and join the directory and child inodes to it, + * and reserve quota for a directory update. If there isn't sufficient space, + * @dblocks will be set to zero for a reservationless directory update and + * @nospace_error will be set to a negative errno describing the space + * constraint we hit. + * + * The caller must ensure that the on-disk dquots attached to this inode have + * already been allocated and initialized. The ILOCKs will be dropped when the + * transaction is committed or cancelled. + */ +int +xfs_trans_alloc_dir( + struct xfs_inode *dp, + struct xfs_trans_res *resv, + struct xfs_inode *ip, + unsigned int *dblocks, + struct xfs_trans **tpp, + int *nospace_error) +{ + struct xfs_trans *tp; + struct xfs_mount *mp = ip->i_mount; + unsigned int resblks; + bool retried = false; + int error; + +retry: + *nospace_error = 0; + resblks = *dblocks; + error = xfs_trans_alloc(mp, resv, resblks, 0, 0, &tp); + if (error == -ENOSPC) { + *nospace_error = error; + resblks = 0; + error = xfs_trans_alloc(mp, resv, resblks, 0, 0, &tp); + } + if (error) + return error; + + xfs_lock_two_inodes(dp, XFS_ILOCK_EXCL, ip, XFS_ILOCK_EXCL); + + xfs_trans_ijoin(tp, dp, XFS_ILOCK_EXCL); + xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); + + error = xfs_qm_dqattach_locked(dp, false); + if (error) { + /* Caller should have allocated the dquots! */ + ASSERT(error != -ENOENT); + goto out_cancel; + } + + error = xfs_qm_dqattach_locked(ip, false); + if (error) { + /* Caller should have allocated the dquots! */ + ASSERT(error != -ENOENT); + goto out_cancel; + } + + if (resblks == 0) + goto done; + + error = xfs_trans_reserve_quota_nblks(tp, dp, resblks, 0, false); + if (error == -EDQUOT || error == -ENOSPC) { + if (!retried) { + xfs_trans_cancel(tp); + xfs_blockgc_free_quota(dp, 0); + retried = true; + goto retry; + } + + *nospace_error = error; + resblks = 0; + error = 0; + } + if (error) + goto out_cancel; + +done: + *tpp = tp; + *dblocks = resblks; + return 0; + +out_cancel: + xfs_trans_cancel(tp); + return error; +} diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h index 50da47f23a07..faba74d4c702 100644 --- a/fs/xfs/xfs_trans.h +++ b/fs/xfs/xfs_trans.h @@ -265,6 +265,9 @@ int xfs_trans_alloc_icreate(struct xfs_mount *mp, struct xfs_trans_res *resv, int xfs_trans_alloc_ichange(struct xfs_inode *ip, struct xfs_dquot *udqp, struct xfs_dquot *gdqp, struct xfs_dquot *pdqp, bool force, struct xfs_trans **tpp); +int xfs_trans_alloc_dir(struct xfs_inode *dp, struct xfs_trans_res *resv, + struct xfs_inode *ip, unsigned int *dblocks, + struct xfs_trans **tpp, int *nospace_error); static inline void xfs_trans_set_context( From patchwork Fri Aug 19 18:14:25 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 12949063 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 14355C32792 for ; Fri, 19 Aug 2022 18:15:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349977AbiHSSPw (ORCPT ); Fri, 19 Aug 2022 14:15:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350621AbiHSSPa (ORCPT ); Fri, 19 Aug 2022 14:15:30 -0400 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B45E113CDA; Fri, 19 Aug 2022 11:14:41 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id bf22so5348164pjb.4; Fri, 19 Aug 2022 11:14:41 -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=C5lgC4kpzep5Mv+Wwyxx7oLNV95NU6fFpgEONgVs94g=; b=Gu8mk3GV1O5QAtdWHeCnTwIteSntblr7LMikhynBNeB8XDNUlzaDyAM+yufdgudeJc 64PYVZlfg0tAcvU3cN5TufQcAFl5GZuqwbgsHOzwCwFE8rhCJMtaIH2oo13PuHhiTsjH VcjJhrJFwQZevY6mEJQRUXDvEMhGkewAp6r/Ui2uqmvzoQKknqaL6plioJlhNBdr/aSJ suWRxbphigdSKYlSxLXNCAQJiNcrZPBZZ5N1w+ki/j61gbSAdqlKoOY1klMI2JdrCxAJ Zh4Mt3mT04y6xzd3sH8edcJjlo4YTOOpIdJTy7dT+236QM5ngfUOaJOvowG48tx9J3i6 ubqw== 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=C5lgC4kpzep5Mv+Wwyxx7oLNV95NU6fFpgEONgVs94g=; b=ruFjAS+FJ5Tp1rHi9NY7y1f3HBIwmEFdgkV/mKXG1zqMgwF+uKqR+po92mUecwsdXe 9Id1LxaYF++QHIDcSXCBVHazKkNVAk7U2DnsgejhyRcL9vL1dYdqhBNrnBmmmqsvF+jS VRMCddmqNYxd+yWS84I2gRkLcumpW8lgJ6ZMRIjC/Be/DabGgu90OkFkvDWKr6NeG1UD MSwQ0JozzP78C0vkAQb4RL/pI7QyqEDYzMMto2+ViJpOPED6NKqeHWoSDFXvvmeL4Wkw LE5OziFseepBfUdAc8l2LVgeHYFgB1XKVL4sSsWKJj5bCfqJIseTkZuM9Aa35OQEeCIj 2KCA== X-Gm-Message-State: ACgBeo19XZxx4iolIZHTneLoCVn406BXJy5LGz5zD68tFw2UpG9QfOFS 2IcSuiOnmquqwGKYebYPK52OH5MVV9b/hQ== X-Google-Smtp-Source: AA6agR6KYRhLTxVu+2c1A98fMP6mc4F8Wn23lN3HXoqfyRvUKMCz3DJ9m2N7uwjwbWZT1YzmX6VFbw== X-Received: by 2002:a17:90a:e586:b0:1fa:d28b:ab9b with SMTP id g6-20020a17090ae58600b001fad28bab9bmr8225271pjz.47.1660932880810; Fri, 19 Aug 2022 11:14:40 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:3995:f9b1:1e6b:e373]) by smtp.gmail.com with ESMTPSA id t14-20020a170902e84e00b0015ee60ef65bsm3460918plg.260.2022.08.19.11.14.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 11:14:40 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, "Darrick J. Wong" , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 3/9] xfs: reserve quota for target dir expansion when renaming files Date: Fri, 19 Aug 2022 11:14:25 -0700 Message-Id: <20220819181431.4113819-4-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog In-Reply-To: <20220819181431.4113819-1-leah.rumancik@gmail.com> References: <20220819181431.4113819-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: "Darrick J. Wong" [ Upstream commit 41667260bc84db4dfe566e3f6ab6da5293d60d8d ] XFS does not reserve quota for directory expansion when renaming children into a directory. This means that we don't reject the expansion with EDQUOT when we're at or near a hard limit, which means that unprivileged userspace can use rename() to exceed quota. Rename operations don't always expand the target directory, and we allow a rename to proceed with no space reservation if we don't need to add a block to the target directory to handle the addition. Moreover, the unlink operation on the source directory generally does not expand the directory (you'd have to free a block and then cause a btree split) and it's probably of little consequence to leave the corner case that renaming a file out of a directory can increase its size. As with link and unlink, there is a further bug in that we do not trigger the blockgc workers to try to clear space when we're out of quota. Because rename is its own special tricky animal, we'll patch xfs_rename directly to reserve quota to the rename transaction. We'll leave cleaning up the rest of xfs_rename for the metadata directory tree patchset. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/xfs_inode.c | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index f4dec7f6c6d0..fb7a97cdf99f 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -3103,7 +3103,8 @@ xfs_rename( bool new_parent = (src_dp != target_dp); bool src_is_directory = S_ISDIR(VFS_I(src_ip)->i_mode); int spaceres; - int error; + bool retried = false; + int error, nospace_error = 0; trace_xfs_rename(src_dp, target_dp, src_name, target_name); @@ -3127,9 +3128,12 @@ xfs_rename( xfs_sort_for_rename(src_dp, target_dp, src_ip, target_ip, wip, inodes, &num_inodes); +retry: + nospace_error = 0; spaceres = XFS_RENAME_SPACE_RES(mp, target_name->len); error = xfs_trans_alloc(mp, &M_RES(mp)->tr_rename, spaceres, 0, 0, &tp); if (error == -ENOSPC) { + nospace_error = error; spaceres = 0; error = xfs_trans_alloc(mp, &M_RES(mp)->tr_rename, 0, 0, 0, &tp); @@ -3183,6 +3187,31 @@ xfs_rename( target_dp, target_name, target_ip, spaceres); + /* + * Try to reserve quota to handle an expansion of the target directory. + * We'll allow the rename to continue in reservationless mode if we hit + * a space usage constraint. If we trigger reservationless mode, save + * the errno if there isn't any free space in the target directory. + */ + if (spaceres != 0) { + error = xfs_trans_reserve_quota_nblks(tp, target_dp, spaceres, + 0, false); + if (error == -EDQUOT || error == -ENOSPC) { + if (!retried) { + xfs_trans_cancel(tp); + xfs_blockgc_free_quota(target_dp, 0); + retried = true; + goto retry; + } + + nospace_error = error; + spaceres = 0; + error = 0; + } + if (error) + goto out_trans_cancel; + } + /* * Check for expected errors before we dirty the transaction * so we can return an error without a transaction abort. @@ -3429,6 +3458,8 @@ xfs_rename( out_release_wip: if (wip) xfs_irele(wip); + if (error == -ENOSPC && nospace_error) + error = nospace_error; return error; } From patchwork Fri Aug 19 18:14:26 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 12949064 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 A419BC38142 for ; Fri, 19 Aug 2022 18:15:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350203AbiHSSPx (ORCPT ); Fri, 19 Aug 2022 14:15:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350655AbiHSSPb (ORCPT ); Fri, 19 Aug 2022 14:15:31 -0400 Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FC0D25E9A; Fri, 19 Aug 2022 11:14:43 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id r22so4285985pgm.5; Fri, 19 Aug 2022 11:14:43 -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=S/EDilCN6R/rInC4ILcrmRd4Xiig+SrevRMQ+U2aGso=; b=gCCAwVIGWsS+wJtd07K2iy37HLgvpMWr3yaPCE8/RwiAO/pWSZO4bmm3syBycdWYu6 VBHkXA17W++6JhROi0LfjkJR+fIdlLe6eF62JEMWK3PSYEiBJcl8yngsnl0h50phLJjk ANHcXYeOUnu0ZkOJTCsk/iH8IKw4cFwaW9DroEnn34xbISsDkDRn7QLravqdjPHQoKZm X0Lrqgan5HzqHuO4KQo6YVg5R3otPk0ABtSmX5RMa6B/ala5jmFMfw68U3ET/Y/Q4Rn4 ZGOxWrmGKlaMGbFXKrepJSa/+BBTE8ArwWzzSx4owe1Uq7WQL5cdiJbXTgr3ZUPDdPvF K/Bw== 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=S/EDilCN6R/rInC4ILcrmRd4Xiig+SrevRMQ+U2aGso=; b=DgiLXAE8okKLGAznAXfeh3uTQbWN97TeRUTBu6LFMgQM989RWabjzYSrIvYMsbMiYI AemTEV+aVzJgKBfg1DtX2QJsJsKKNy/k5N5uGr9GhtYOPBqZah/uIypknkNnxJKzxWxt k6RJsr77uRkxPu4cT/U9ka4ldw8X6LS1/43aN5ScC0QyLmbTj1vsceP9mnG0B/Ia2V1u qRTZvzkeBDwhohKkoxjVdBSDW/Ns+n7Yp+0Qom59X3G/QMxh4cZ9LJgCSZamChR29Qyw aZPZO85W04HfbCLVl+4S3IgLYiJ6wlNNwE3UkKmRCewTJNkK44iEurL4ZFs/0xyU5V6T KE0A== X-Gm-Message-State: ACgBeo3NxdkUhtFJhagAhe+GiPX0vPUfrNTQhCcxDPzbLAP/jZDQ2aV0 e/FqQF9GF0kR4vsUwP0gojYHGR3C6AcDbQ== X-Google-Smtp-Source: AA6agR4CZaEFWfzkrJhW6yCBXAO9w6XmZASJDe7u0aikAaZrFJ42yEJCwupQBOWi7EUFc5BX1FqXSg== X-Received: by 2002:a65:6d98:0:b0:41d:d9:a338 with SMTP id bc24-20020a656d98000000b0041d00d9a338mr7081525pgb.421.1660932882356; Fri, 19 Aug 2022 11:14:42 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:3995:f9b1:1e6b:e373]) by smtp.gmail.com with ESMTPSA id t14-20020a170902e84e00b0015ee60ef65bsm3460918plg.260.2022.08.19.11.14.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 11:14:41 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, "Darrick J. Wong" , Brian Foster , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 4/9] xfs: remove infinite loop when reserving free block pool Date: Fri, 19 Aug 2022 11:14:26 -0700 Message-Id: <20220819181431.4113819-5-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog In-Reply-To: <20220819181431.4113819-1-leah.rumancik@gmail.com> References: <20220819181431.4113819-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: "Darrick J. Wong" [ Upstream commit 15f04fdc75aaaa1cccb0b8b3af1be290e118a7bc ] 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: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/xfs_fsops.c | 50 +++++++++++++++++++--------------------------- 1 file changed, 20 insertions(+), 30 deletions(-) diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c index 710e857bb825..3c6d9d6836ef 100644 --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -430,46 +430,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) - + free = percpu_counter_sum(&mp->m_fdblocks) - xfs_fdblocks_unavailable(mp); - 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; - + 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; From patchwork Fri Aug 19 18:14:27 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 12949065 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 CABC5C32771 for ; Fri, 19 Aug 2022 18:15:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350274AbiHSSPy (ORCPT ); Fri, 19 Aug 2022 14:15:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45594 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350658AbiHSSPb (ORCPT ); Fri, 19 Aug 2022 14:15:31 -0400 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FF2729CA7; Fri, 19 Aug 2022 11:14:44 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id p125so5000642pfp.2; Fri, 19 Aug 2022 11:14:44 -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=efHyiVC/LBZfOk0B9SIqlLuOFO1671uB7v4aNThPrT8=; b=ZCRdd9XKqIwQ+wAANySX+Cqf+Gy+Tki0P49CgHaTxaxH/Mi/35zDyQL2AQLx2troH3 uj4Y9gZezhoCcL+esBWQPnHgfsRQHcjaQBQbHm2++7esbRMDM/O20QJDIXJi6VUu0uU7 UtXQ3t/KDOIDb93IrsPTr2canCISrrbrLURjHQJ6MUjWW3m+zb4PUPVNAvoPDtFBrKwl 7YhEEXCcSMdRI+f928XtOWBfAN+VKijU4rdCLDHfMiUqPiOnvuf/rxYRbdZY87YF/3kn YbmqjN8DdAxGdYTQCW+yBrknOru1w+JVN5BIe9upekIaH99ICOJ9CtXTMBFOjfkOj+ZQ IHtQ== 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=efHyiVC/LBZfOk0B9SIqlLuOFO1671uB7v4aNThPrT8=; b=IkgzvDV+t3PajMMZ7S8d5yvzM/c0d0Aa6osYAPm1yA1NFTIXca+UVoheGxoeLGhZFu NhK2sZ+6hxS7xpvkADD/HRvlsxw8OGvCeof9f6YFQjbnNY1pwuS/bYN3q/Tdr45sMsbI Hs+JyJ1HJWdhgUKfMZKvz+EgUnVSBgyZe+bv2ZYucIC4jnPlYPdAb7YrMOOpgYBeH+TY EUnM/E55CPehUFdBLpDs3AOnpDtTltVDN/tP1bSYRYf7rDj8myktFnt6y1kXUGBxad14 3yV7Zy+3aZh4M/gSH+Tnycp0oX2rfsIDmkyF/eXCqBsdcXQm6Z1KjGTKz2aC6XKhlwRV aTpQ== X-Gm-Message-State: ACgBeo06PPGVK7glo3BO7fZ5G3BeOnaki4NO+O3B660j8J6Yqm+MfASH s5ukMPy5/7JXYQOtNIyB4Uzkj/LWgiWBfA== X-Google-Smtp-Source: AA6agR7fu4XQMf1LQ8nh5h1IZX1pyafVRA/zneKMr3D7nPkAEWjHber72MEzI5qHFXR0CQ9iALQytw== X-Received: by 2002:a05:6a00:2181:b0:51b:560b:dd30 with SMTP id h1-20020a056a00218100b0051b560bdd30mr9103855pfi.44.1660932883413; Fri, 19 Aug 2022 11:14:43 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:3995:f9b1:1e6b:e373]) by smtp.gmail.com with ESMTPSA id t14-20020a170902e84e00b0015ee60ef65bsm3460918plg.260.2022.08.19.11.14.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 11:14:43 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, "Darrick J. Wong" , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 5/9] xfs: always succeed at setting the reserve pool size Date: Fri, 19 Aug 2022 11:14:27 -0700 Message-Id: <20220819181431.4113819-6-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog In-Reply-To: <20220819181431.4113819-1-leah.rumancik@gmail.com> References: <20220819181431.4113819-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: "Darrick J. Wong" [ Upstream commit 0baa2657dc4d79202148be79a3dc36c35f425060 ] 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: Leah Rumancik 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 3c6d9d6836ef..5c2bea1e12a8 100644 --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -434,11 +434,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 @@ -455,10 +458,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 Fri Aug 19 18:14:28 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 12949066 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 6C4F0C28B2B for ; Fri, 19 Aug 2022 18:15:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350344AbiHSSPz (ORCPT ); Fri, 19 Aug 2022 14:15:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350674AbiHSSPc (ORCPT ); Fri, 19 Aug 2022 14:15:32 -0400 Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC8762AC6C; Fri, 19 Aug 2022 11:14:45 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id k14so5020636pfh.0; Fri, 19 Aug 2022 11:14:45 -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=A1jwGNihEua/xjlZ16qM8zyq+B6+JuBhAHdzSolMm6Y=; b=jdM57gWUMHVMskxpbHntWXIh5SW0mcMXugUNu4HIgdYHeeztmNHlYtPhfw7pHnSYWC VE8hLDZrIIBjlJSmYn3funuBs5ioYBgRkIwMfQKnU5zOQgsuO+uKbXtZ4fB7P7Gtdb20 XSuijMeu2GBqlEkFdtC7gN/DEgCC9ndFi/q4oM8ojMWeTl+c9j0aCDB8udh4pTsU11HK AL/8rxNZV+jjNbxX3UJY5rR9wPQwMS4j7LpcwZBOsk53gbRY/8gBbajToGxBruQQSUcv fks1sTRIs8Q1/Cb0CzPxjh8bOwWppRzxiZjwJKKOg/ignYh5XeR7l2f9cr99et4skMUf tqKg== 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=A1jwGNihEua/xjlZ16qM8zyq+B6+JuBhAHdzSolMm6Y=; b=dhCXhvssWPp80/Z4kcZoC0WYPuCUjr4MzVGnHKidx9SFZxDXSEyLIVNz3HtCQRvMcb vOCh+LfKqqHaBlGIvYYfnk3o9oV+9ktd8bs+FfxowUJkUZpWcQk0zH9/FWeHqA0gHzx7 XSQnObv3OBLHYpmf7gr5J1kABjP/y1Lgi4YUWdSfdvNfQGWE79sqEzBJkhib2G2D4bQ7 4/fwLX8H+dcw2F3oEBxOok9nDButwTveFIhPVAFJj+nz9Mk7jMnSkaL/UxrLI2McMJBV 0CmphVMqboI+C5nodXQHM7cmTqNdk6+gL7Ub6Jxu0JoSQJT5+SWDKv5ndYYq9g519dOn qlhg== X-Gm-Message-State: ACgBeo3DtXe1YSjRcO0fZDuqdC/DYLQxhQu8Dow6ykQGHVsVeqve3K0U k1MCblyQLIAyOaBHWFV45HFN040FrUrlwQ== X-Google-Smtp-Source: AA6agR4vjvmfjEry8TGGLjIsOWN+sND68pp/DiymiczffMnAqzE2LznJW+Rqiu2KDHsEqG8/PEYNqA== X-Received: by 2002:a05:6a00:428d:b0:52e:6305:14c with SMTP id bx13-20020a056a00428d00b0052e6305014cmr9040874pfb.10.1660932884839; Fri, 19 Aug 2022 11:14:44 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:3995:f9b1:1e6b:e373]) by smtp.gmail.com with ESMTPSA id t14-20020a170902e84e00b0015ee60ef65bsm3460918plg.260.2022.08.19.11.14.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 11:14:44 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, "Darrick J. Wong" , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 6/9] xfs: fix overfilling of reserve pool Date: Fri, 19 Aug 2022 11:14:28 -0700 Message-Id: <20220819181431.4113819-7-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog In-Reply-To: <20220819181431.4113819-1-leah.rumancik@gmail.com> References: <20220819181431.4113819-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: "Darrick J. Wong" [ Upstream commit 82be38bcf8a2e056b4c99ce79a3827fa743df6ec ] 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: Leah Rumancik 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 5c2bea1e12a8..5b5b68affe66 100644 --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -448,18 +448,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 Fri Aug 19 18:14:29 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 12949067 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 E7B11C38147 for ; Fri, 19 Aug 2022 18:15:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350388AbiHSSPz (ORCPT ); Fri, 19 Aug 2022 14:15:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54176 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350677AbiHSSPc (ORCPT ); Fri, 19 Aug 2022 14:15:32 -0400 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC60A167E1; Fri, 19 Aug 2022 11:14:46 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id y127so2026680pfy.5; Fri, 19 Aug 2022 11:14:46 -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=xf7q2uZJ9/EeuM4aGbB6um/xCXexSzccPg0zIf1ywqc=; b=qT0zGuXKeC6J8pgeDXYeeHywNkG1rYQl4LM42tUj3sNLkmYtmqFj3vNjx4vbKj3JOr JJEaSnVn28oqzV5Z/cYThLLQRATGuf62lvUzgna8O2uqcsQblK2tcfx1Dy3BiME4Z/3Q lBDE3zF9bCbST1utHkPMOexrdJ7neVUMQQpddQtGf3Q4DQ+3yzmh9URA3RhqpgKRXTav 3CfN/VaBSX/pZm0q5+j3/ObOQEPfCjl5HAHrQ8PAgz+mNIC83w7+tAWZMp85HCNrJQHF XjnRjHoLyx4DZmJwgSAJNYCSlc2LIgYshKSZw+eteiVRLMLg/w9fPONMrBVjc+ltqZrh qVbw== 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=xf7q2uZJ9/EeuM4aGbB6um/xCXexSzccPg0zIf1ywqc=; b=p8e2uVHZXEBUL/H3Ajp0mtEJnymehroN9BY3sQM0JY9BHs0rDHMcrHzkAk/43YBab0 I/PPcZzpnwzpQWREuTzcDXsDAQqPfXjvDSiv6ouShIoY6ncChashhdVWhg530l27YfOh IN/shDKLdUfvbFbIF2sPC9bXkz2y012Zrt1JDmEJX+5xpepu5OiI77t5zZEyk7YE02H3 6VbtNNe9txrpzIbJ/JUMnGkUakUU2mLjuyp/Ae74QuDmNMMzUmifzeSAJPqiHFwJoR2v uSu/0FeGEJAzXjGbNGt6WN2YTyI+sDN+FU0vMToFn+ORt3Qk9hhIY7jCAecHN2ha1HFM jpPw== X-Gm-Message-State: ACgBeo2f/zMBEsShgh/a0P6k7rbF1Uo9yuxCEurJb+UASPn23hdkFGxy KUm5ZZghTSNFXiRyJnaKQYyu9ha76PTMfQ== X-Google-Smtp-Source: AA6agR4+qKUsowB7oZMTqJjY13Ew0mdog/mLSAjkvNz7NYE1q1rZwuDFdRuzNhmKpbXOaD3DDf4/tQ== X-Received: by 2002:a05:6a00:1ac6:b0:52f:55f8:c3d3 with SMTP id f6-20020a056a001ac600b0052f55f8c3d3mr8995307pfv.76.1660932886084; Fri, 19 Aug 2022 11:14:46 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:3995:f9b1:1e6b:e373]) by smtp.gmail.com with ESMTPSA id t14-20020a170902e84e00b0015ee60ef65bsm3460918plg.260.2022.08.19.11.14.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 11:14:45 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, Brian Foster , "Darrick J . Wong" , Christoph Hellwig , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 7/9] xfs: fix soft lockup via spinning in filestream ag selection loop Date: Fri, 19 Aug 2022 11:14:29 -0700 Message-Id: <20220819181431.4113819-8-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog In-Reply-To: <20220819181431.4113819-1-leah.rumancik@gmail.com> References: <20220819181431.4113819-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Brian Foster [ Upstream commit f650df7171b882dca737ddbbeb414100b31f16af ] 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: Leah Rumancik 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 6a3ce0f6dc9e..be9bcf8a1f99 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 Fri Aug 19 18:14:30 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 12949068 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 EB55DC32796 for ; Fri, 19 Aug 2022 18:15:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350407AbiHSSP4 (ORCPT ); Fri, 19 Aug 2022 14:15:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350693AbiHSSPd (ORCPT ); Fri, 19 Aug 2022 14:15:33 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78BA337F8A; Fri, 19 Aug 2022 11:14:48 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id x23so4784886pll.7; Fri, 19 Aug 2022 11:14:48 -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=Eg8lLnZD45tjnJs2FISMJ0GzB1uwNmqz0NlD8+uXijU=; b=mv/ttqkxqIB5nUnVjGsAm00z7k+W9h3i2s3SRzCBJhen+yoHgbcf/4ULZ7lxb+lCBl UaD0iKEedBTCdk3Tma3acs7btv/zuk/XgBS/W+AS8ONF+kH/z7ixI3+N83mfHhTdAelz ppNWxwkE335QdjXsFuBgshQITduzjMU5u9db/22B5UIILTsamPtiYxCFjP5gv2pbXCpc BKw2cfvarNVmd4JTnJz1twd6L+kDhmTaqUKi8VIaA5FfQXfpsOvgjthpoEtyhnMDIxKA fhPw7SgYGWDZdduE6eK13oHfasM/Rp1nPwGmltUriv1XkcPW6u8YGpbH5VtLf/yKi32+ 4UGQ== 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=Eg8lLnZD45tjnJs2FISMJ0GzB1uwNmqz0NlD8+uXijU=; b=YflOctWzLe0RuM12Gh4xHU7+BAG+g3rGfMEuThPVRONCVXHxnv668RJJuvMoGs+col nWue16a4StuPlChUKOvv+M8iABMjafGS3C/Hm99YlqQq1S/iKd1lwuKoiAyDdvUBiluU kymZ+VyvPX1woPhQ82qEjicuzsgPdwhQVDU5q29PMFbw5+DUMVz+/qg+v2JmTXr3JyEm 7zbr1kKIcI2IMR8Ak0eWA9+3psK7WAVoo0nmghUtBjFPRt5rhwr5/nJBYNNONo/1ZMQi G5WqpG/IgB6s2vNQBsGTw/tlWyafeWx9YGqWb+JTbp1XvEM0ftRWojDjecaMgqYEckzC Ioug== X-Gm-Message-State: ACgBeo1+GTHnn9GSAXRQQ5vyC5b7q00Bn9I78a7a9NalmQq1R0NKP1al YVvPxS8am/EqnZT6HB+lCtiXNPQ00oG9KA== X-Google-Smtp-Source: AA6agR54hD55doPt8LuwvfDzoepYyBUWslS8HkPB8ST3Y3KihmVlMJN9u4BfwWU2R5Wy0sM487KmKQ== X-Received: by 2002:a17:90b:4d91:b0:1f5:24a:ff7e with SMTP id oj17-20020a17090b4d9100b001f5024aff7emr9583028pjb.194.1660932887730; Fri, 19 Aug 2022 11:14:47 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:3995:f9b1:1e6b:e373]) by smtp.gmail.com with ESMTPSA id t14-20020a170902e84e00b0015ee60ef65bsm3460918plg.260.2022.08.19.11.14.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 11:14:46 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, Eric Sandeen , "Darrick J . Wong" , Dave Chinner , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 8/9] xfs: revert "xfs: actually bump warning counts when we send warnings" Date: Fri, 19 Aug 2022 11:14:30 -0700 Message-Id: <20220819181431.4113819-9-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog In-Reply-To: <20220819181431.4113819-1-leah.rumancik@gmail.com> References: <20220819181431.4113819-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Eric Sandeen [ Upstream commit bc37e4fb5cac2925b2e286b1f1d4fc2b519f7d92 ] 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: Leah Rumancik 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 3872ce671411..955c457e585a 100644 --- a/fs/xfs/xfs_trans_dquot.c +++ b/fs/xfs/xfs_trans_dquot.c @@ -603,7 +603,6 @@ xfs_dqresv_check( return QUOTA_NL_ISOFTLONGWARN; } - res->warnings++; return QUOTA_NL_ISOFTWARN; } From patchwork Fri Aug 19 18:14:31 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 12949069 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 4A34DC32771 for ; Fri, 19 Aug 2022 18:15:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350449AbiHSSP5 (ORCPT ); Fri, 19 Aug 2022 14:15:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350713AbiHSSPe (ORCPT ); Fri, 19 Aug 2022 14:15:34 -0400 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C48E260A; Fri, 19 Aug 2022 11:14:50 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id w138so2368453pfc.10; Fri, 19 Aug 2022 11:14:50 -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=e+XtPeC3pjXDO7mdGWjhmTQzwtsJL/vQCieYQy7ut4E=; b=RX96LJt+nOABWd+tsDkCkJJ7ntjNDGsnLZCKTN40l1WMltyOWXnXDzPzO83USsN0PV 3A0TvTZm3VkCGrBPHBt74Dd7yArIlqYRJwJilL9Iyr6dNNsYbXshY6sqUJz6UG7z2VOo bskFlEjh3nC75nA86dV3NdKadcJTVwH+aT3rHLZFSEgwhb/Xd1x0RyGQlXhT0G5UcKeu DmquNOwyGoQXfC/w5Z4m3gWP9NvLKLj+r1/yhyHgfckukKJ5d4qAegqo6pjSkYtaqJyN JALqwvzSJpBN2TplDQAJ/OBLYDmZ5e7v9IzeNJwHMNFnNN0IO7ljorTbiUQT0I08PbOs BT7Q== 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=e+XtPeC3pjXDO7mdGWjhmTQzwtsJL/vQCieYQy7ut4E=; b=ic0C89BEnciL20zS9DuonzPei84T0QVHzmG+L5/NbVOdnU8Qr0P2WLsB5SrvY9L8RU 0f6rJuKYIi8u867iuJhJrUHRpkj6qf/4y4LPJwzV2+FqiBYH5j4j3s+/RD8pSsfgAQdy N4sCPHOFxspTzpfLOiNa6LU0Pn7Wb/lTINT14todw0g+4nnOd/pagNCwnaxHtUe1D9WG 7vqDkKkPoSDKOIxBkOkAPSOvViqXaU/j+ZXJ5mIz2Ivgd292DyP+5434WtE34MaOV/GV Nnk2Hi2op3JV1VhaC/B6baf6zsN7TA3xU1xqAgd2z0o9isJdZyBH5ZrYWsRWlpK8cDF3 ycdw== X-Gm-Message-State: ACgBeo2RM+ktGBk3Mi0iseVOzOO0HTNljyc9uY4Mwkurj3UjGdLR+07L LPBMcCfVawAFWlQsd8xAAqkdcZM5+uIPpw== X-Google-Smtp-Source: AA6agR7xTFAzynYIJYRzrlVVHR6OZIAJi++KYll4/saep5sBM9gyrbqjn5FwfEdFJjQ9izY7rFGCUg== X-Received: by 2002:a63:d5:0:b0:41a:58f:929e with SMTP id 204-20020a6300d5000000b0041a058f929emr7103736pga.260.1660932888846; Fri, 19 Aug 2022 11:14:48 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2d4:203:3995:f9b1:1e6b:e373]) by smtp.gmail.com with ESMTPSA id t14-20020a170902e84e00b0015ee60ef65bsm3460918plg.260.2022.08.19.11.14.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 11:14:48 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, "Darrick J. Wong" , Allison Henderson , Catherine Hoang , Leah Rumancik Subject: [PATCH 5.15 9/9] xfs: reject crazy array sizes being fed to XFS_IOC_GETBMAP* Date: Fri, 19 Aug 2022 11:14:31 -0700 Message-Id: <20220819181431.4113819-10-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog In-Reply-To: <20220819181431.4113819-1-leah.rumancik@gmail.com> References: <20220819181431.4113819-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: "Darrick J. Wong" [ Upstream commit 29d650f7e3ab55283b89c9f5883d0c256ce478b5 ] Syzbot tripped over the following complaint from the kernel: WARNING: CPU: 2 PID: 15402 at mm/util.c:597 kvmalloc_node+0x11e/0x125 mm/util.c:597 While trying to run XFS_IOC_GETBMAP against the following structure: struct getbmap fubar = { .bmv_count = 0x22dae649, }; Obviously, this is a crazy huge value since the next thing that the ioctl would do is allocate 37GB of memory. This is enough to make kvmalloc mad, but isn't large enough to trip the validation functions. In other words, I'm fussing with checks that were **already sufficient** because that's easier than dealing with 644 internal bug reports. Yes, that's right, six hundred and forty-four. Signed-off-by: Darrick J. Wong Reviewed-by: Allison Henderson Reviewed-by: Catherine Hoang Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/xfs_ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c index fba52e75e98b..bcc3c18c8080 100644 --- a/fs/xfs/xfs_ioctl.c +++ b/fs/xfs/xfs_ioctl.c @@ -1545,7 +1545,7 @@ xfs_ioc_getbmap( if (bmx.bmv_count < 2) return -EINVAL; - if (bmx.bmv_count > ULONG_MAX / recsize) + if (bmx.bmv_count >= INT_MAX / recsize) return -ENOMEM; buf = kvzalloc(bmx.bmv_count * sizeof(*buf), GFP_KERNEL);