From patchwork Fri Sep 22 01:01:51 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13394854 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 C6DCCE7D0BB for ; Fri, 22 Sep 2023 01:02:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229969AbjIVBCK (ORCPT ); Thu, 21 Sep 2023 21:02:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229452AbjIVBCJ (ORCPT ); Thu, 21 Sep 2023 21:02:09 -0400 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E40B1102; Thu, 21 Sep 2023 18:02:02 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1c328b53aeaso14246165ad.2; Thu, 21 Sep 2023 18:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695344522; x=1695949322; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=3ej1VaYkETo5to6v5QOq2ep9cnGTeTAFm8phePWQ360=; b=WZnR8173aLmjgtVpyUyMFcXQASwsmgFLQTce8Xq7jnUCNsaQNAedO8x/K6W5D7P7HY Tt4ASUl3qgmVnzhZ0D/owTr+fjUh8MgRIsGFBuPglMcocjj9SCyyvdcpCAZJlzkDzgUR 2Cac4+6d23bw2dOMdwJJJcA2CNrkdNtLJF2o0J6YqEILjpwbMywLEK+fA5BGAwf9MtXq TJ2hcUn1HEpEC/1EAN0gJWsSVJriWZyaswI+u+P6GR0le32ghh0CNScRm28jP5JaIy+G rt0V3aSGtoZf0lFuyu+OSKRIeJ2q51H/5EQXK9n+69aVAV4BXmjA1c2JQ/klQLyNiZ+3 rYcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695344522; x=1695949322; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3ej1VaYkETo5to6v5QOq2ep9cnGTeTAFm8phePWQ360=; b=ZzT5g4dXGGkRI0bQXhiGKkI7t/7lFPQCtTaZ9ddVj0zPL4LdzkLZq+3gPO0rj5AbTY hlwGP/a9BQLLxPuELWEIs9rhyyCBxRfRITtaRWgV8fuzp1p2R6PFUINnGhvuzHZnu68Z Kr/GemzLgYBzm4MQquClBWfSFfRq/b6jTLqkACrIurk+o7mQnIE5Dmf9V2RPglifcW9x qAFeLY7Mds7U8bDWRh1B3cv2L4RQ1oQ7vVGjsVdiKx6ja/Bd0cJv4lJo0hQfHMiAK7X9 A4ulq/d34NCkzGvRJFuQO5I7m8x76SXq2KsMBbY7N3K5AD8bN1VMz0iRaVM7PY1fyj8L 6YHw== X-Gm-Message-State: AOJu0YwucuMJkaTKgsWqW635EyRg8zNlH4hnsP8lrW+Iv50ahJlaFEJ7 IDk2jejRMuBw+3SfExEsqBGnsSLSm4fxNA== X-Google-Smtp-Source: AGHT+IEHlUXYjdpsDLHS4fD/eeIWItgFnydKzl/JDBO05DpymUtRp17MaP1HftrjNq7qs3x6MA0dcw== X-Received: by 2002:a17:903:2786:b0:1c5:6309:e1e2 with SMTP id jw6-20020a170903278600b001c56309e1e2mr6706842plb.48.1695344521837; Thu, 21 Sep 2023 18:02:01 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2a3:200:d5ff:b7b0:7028:8af6]) by smtp.gmail.com with ESMTPSA id u2-20020a17090282c200b001bc445e2497sm2178815plz.79.2023.09.21.18.02.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 18:02:01 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, Dave Chinner , "Darrick J . Wong" , Leah Rumancik Subject: [PATCH 5.15 1/6] xfs: bound maximum wait time for inodegc work Date: Thu, 21 Sep 2023 18:01:51 -0700 Message-ID: <20230922010156.1718782-1-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.42.0.515.g380fc7ccd1-goog MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner [ Upstream commit 7cf2b0f9611b9971d663e1fc3206eeda3b902922 ] Currently inodegc work can sit queued on the per-cpu queue until the workqueue is either flushed of the queue reaches a depth that triggers work queuing (and later throttling). This means that we could queue work that waits for a long time for some other event to trigger flushing. Hence instead of just queueing work at a specific depth, use a delayed work that queues the work at a bound time. We can still schedule the work immediately at a given depth, but we no long need to worry about leaving a number of items on the list that won't get processed until external events prevail. Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/xfs_icache.c | 36 ++++++++++++++++++++++-------------- fs/xfs/xfs_mount.h | 2 +- fs/xfs/xfs_super.c | 2 +- 3 files changed, 24 insertions(+), 16 deletions(-) diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index 5e44d7bbd8fc..2c3ef553f5ef 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -458,7 +458,7 @@ xfs_inodegc_queue_all( for_each_online_cpu(cpu) { gc = per_cpu_ptr(mp->m_inodegc, cpu); if (!llist_empty(&gc->list)) - queue_work_on(cpu, mp->m_inodegc_wq, &gc->work); + mod_delayed_work_on(cpu, mp->m_inodegc_wq, &gc->work, 0); } } @@ -1851,8 +1851,8 @@ void xfs_inodegc_worker( struct work_struct *work) { - struct xfs_inodegc *gc = container_of(work, struct xfs_inodegc, - work); + struct xfs_inodegc *gc = container_of(to_delayed_work(work), + struct xfs_inodegc, work); struct llist_node *node = llist_del_all(&gc->list); struct xfs_inode *ip, *n; @@ -2021,6 +2021,7 @@ xfs_inodegc_queue( struct xfs_inodegc *gc; int items; unsigned int shrinker_hits; + unsigned long queue_delay = 1; trace_xfs_inode_set_need_inactive(ip); spin_lock(&ip->i_flags_lock); @@ -2032,19 +2033,26 @@ xfs_inodegc_queue( items = READ_ONCE(gc->items); WRITE_ONCE(gc->items, items + 1); shrinker_hits = READ_ONCE(gc->shrinker_hits); - put_cpu_ptr(gc); - if (!xfs_is_inodegc_enabled(mp)) + /* + * We queue the work while holding the current CPU so that the work + * is scheduled to run on this CPU. + */ + if (!xfs_is_inodegc_enabled(mp)) { + put_cpu_ptr(gc); return; - - if (xfs_inodegc_want_queue_work(ip, items)) { - trace_xfs_inodegc_queue(mp, __return_address); - queue_work(mp->m_inodegc_wq, &gc->work); } + if (xfs_inodegc_want_queue_work(ip, items)) + queue_delay = 0; + + trace_xfs_inodegc_queue(mp, __return_address); + mod_delayed_work(mp->m_inodegc_wq, &gc->work, queue_delay); + put_cpu_ptr(gc); + if (xfs_inodegc_want_flush_work(ip, items, shrinker_hits)) { trace_xfs_inodegc_throttle(mp, __return_address); - flush_work(&gc->work); + flush_delayed_work(&gc->work); } } @@ -2061,7 +2069,7 @@ xfs_inodegc_cpu_dead( unsigned int count = 0; dead_gc = per_cpu_ptr(mp->m_inodegc, dead_cpu); - cancel_work_sync(&dead_gc->work); + cancel_delayed_work_sync(&dead_gc->work); if (llist_empty(&dead_gc->list)) return; @@ -2080,12 +2088,12 @@ xfs_inodegc_cpu_dead( llist_add_batch(first, last, &gc->list); count += READ_ONCE(gc->items); WRITE_ONCE(gc->items, count); - put_cpu_ptr(gc); if (xfs_is_inodegc_enabled(mp)) { trace_xfs_inodegc_queue(mp, __return_address); - queue_work(mp->m_inodegc_wq, &gc->work); + mod_delayed_work(mp->m_inodegc_wq, &gc->work, 0); } + put_cpu_ptr(gc); } /* @@ -2180,7 +2188,7 @@ xfs_inodegc_shrinker_scan( unsigned int h = READ_ONCE(gc->shrinker_hits); WRITE_ONCE(gc->shrinker_hits, h + 1); - queue_work_on(cpu, mp->m_inodegc_wq, &gc->work); + mod_delayed_work_on(cpu, mp->m_inodegc_wq, &gc->work, 0); no_items = false; } } diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 86564295fce6..3d58938a6f75 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -61,7 +61,7 @@ struct xfs_error_cfg { */ struct xfs_inodegc { struct llist_head list; - struct work_struct work; + struct delayed_work work; /* approximate count of inodes in the list */ unsigned int items; diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index df1d6be61bfa..8fe6ca9208de 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1061,7 +1061,7 @@ xfs_inodegc_init_percpu( gc = per_cpu_ptr(mp->m_inodegc, cpu); init_llist_head(&gc->list); gc->items = 0; - INIT_WORK(&gc->work, xfs_inodegc_worker); + INIT_DELAYED_WORK(&gc->work, xfs_inodegc_worker); } return 0; } From patchwork Fri Sep 22 01:01:52 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13394856 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 7F091E7D0BE for ; Fri, 22 Sep 2023 01:02:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229873AbjIVBCL (ORCPT ); Thu, 21 Sep 2023 21:02:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229532AbjIVBCJ (ORCPT ); Thu, 21 Sep 2023 21:02:09 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BEA32122; Thu, 21 Sep 2023 18:02:03 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1c5db4925f9so9141245ad.1; Thu, 21 Sep 2023 18:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695344523; x=1695949323; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bOqjqLKBsBB4hITnkzqZ6Dh7CcePl0xuVQ/ZcmiPf/Q=; b=VKKwsLch/S/zBSnfHYkqAmg/bLF7wEsv9orwEGU9TGu1Ukuvxx6yUuScSlfrj1ngZl HfSOia6QBDrHf2ZFBbraIoFwr6UG5ZZdF1PsN/FcQMnYV/tKgNCxD3rWMjAYD4XNCVGH CcdRREywL4Fcr+wmlaJV8EIkwuq36KzBtZPmx2LWymRIrlFR4hh2JblORKtI/gf5timx nM+eLFg/H8HlCy0UGUmdHSUNR+b09Ln7d7oTiJrYL+LvlN0IXEij0Gs5v7NYjg1Fmfgu VKz49Gjmyzfdhjdcy8RDhX9M4Cjv9F67YMeZyW6iWWI02LUlN1xmuJn63qT8lkmCvOi9 g5zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695344523; x=1695949323; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bOqjqLKBsBB4hITnkzqZ6Dh7CcePl0xuVQ/ZcmiPf/Q=; b=WBlKvencSeOjPcHRXn0WkMWCKpCECdXkvCvRFwqRC4S/1pkRUjhIe51W3HZRWbHqy8 9NkpLz7nZ+iFHDQmDG9b03+NMHYVgAaJBIuFFrMAG4Ohn3b07wCdu/qAIqXeacT5hTcu xtYZfVK/vChb3CSUoo+trSopaDZGBRvc19t1Vj/IJ/uIMS8oP+u0rqPmvrsbf9fQQgef sNTEqhk8WTlhUCqOHjmAXOJX6ayewuGHrQBbcnlHlOVjZo/Wtu4S/zJhXDH+gHNXLCtM fkRxH0EzudddF+wOZNreoIaQTm1oSzDuPF03dDClZhc05BdCGnmznWEV0KZH/Qz+R9xJ 8Hlg== X-Gm-Message-State: AOJu0YzIfph0Bt5IxqMUPNHAS/1gAZK+9ULIxXxYUsvO45pEhYYi9i7t mDa8qQuk92MV6x/griAJTupClGUD/6XMnQ== X-Google-Smtp-Source: AGHT+IHjhXQJaq6+lZQvCuP0q8dpitXt3UJhlxxd1an1RngaCUSEEzNu8NZISpUSFhx7J+DfzgQlZw== X-Received: by 2002:a17:902:f689:b0:1b4:5699:aac1 with SMTP id l9-20020a170902f68900b001b45699aac1mr1918881plg.12.1695344522839; Thu, 21 Sep 2023 18:02:02 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2a3:200:d5ff:b7b0:7028:8af6]) by smtp.gmail.com with ESMTPSA id u2-20020a17090282c200b001bc445e2497sm2178815plz.79.2023.09.21.18.02.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 18:02:02 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, Dave Chinner , Chris Dunlop , "Darrick J . Wong" , Leah Rumancik Subject: [PATCH 5.15 2/6] xfs: introduce xfs_inodegc_push() Date: Thu, 21 Sep 2023 18:01:52 -0700 Message-ID: <20230922010156.1718782-2-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.42.0.515.g380fc7ccd1-goog In-Reply-To: <20230922010156.1718782-1-leah.rumancik@gmail.com> References: <20230922010156.1718782-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Dave Chinner [ Upstream commit 5e672cd69f0a534a445df4372141fd0d1d00901d ] The current blocking mechanism for pushing the inodegc queue out to disk can result in systems becoming unusable when there is a long running inodegc operation. This is because the statfs() implementation currently issues a blocking flush of the inodegc queue and a significant number of common system utilities will call statfs() to discover something about the underlying filesystem. This can result in userspace operations getting stuck on inodegc progress, and when trying to remove a heavily reflinked file on slow storage with a full journal, this can result in delays measuring in hours. Avoid this problem by adding "push" function that expedites the flushing of the inodegc queue, but doesn't wait for it to complete. Convert xfs_fs_statfs() and xfs_qm_scall_getquota() to use this mechanism so they don't block but still ensure that queued operations are expedited. Fixes: ab23a7768739 ("xfs: per-cpu deferred inode inactivation queues") Reported-by: Chris Dunlop Signed-off-by: Dave Chinner [djwong: fix _getquota_next to use _inodegc_push too] Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Leah Rumancik Acked-by: Darrick J. Wong --- fs/xfs/xfs_icache.c | 20 +++++++++++++++----- fs/xfs/xfs_icache.h | 1 + fs/xfs/xfs_qm_syscalls.c | 9 ++++++--- fs/xfs/xfs_super.c | 7 +++++-- fs/xfs/xfs_trace.h | 1 + 5 files changed, 28 insertions(+), 10 deletions(-) diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index 2c3ef553f5ef..e9ebfe6f8015 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -1872,19 +1872,29 @@ xfs_inodegc_worker( } /* - * Force all currently queued inode inactivation work to run immediately and - * wait for the work to finish. + * Expedite all pending inodegc work to run immediately. This does not wait for + * completion of the work. */ void -xfs_inodegc_flush( +xfs_inodegc_push( struct xfs_mount *mp) { if (!xfs_is_inodegc_enabled(mp)) return; + trace_xfs_inodegc_push(mp, __return_address); + xfs_inodegc_queue_all(mp); +} +/* + * 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) +{ + xfs_inodegc_push(mp); trace_xfs_inodegc_flush(mp, __return_address); - - xfs_inodegc_queue_all(mp); flush_workqueue(mp->m_inodegc_wq); } diff --git a/fs/xfs/xfs_icache.h b/fs/xfs/xfs_icache.h index 2e4cfddf8b8e..6cd180721659 100644 --- a/fs/xfs/xfs_icache.h +++ b/fs/xfs/xfs_icache.h @@ -76,6 +76,7 @@ void xfs_blockgc_stop(struct xfs_mount *mp); void xfs_blockgc_start(struct xfs_mount *mp); void xfs_inodegc_worker(struct work_struct *work); +void xfs_inodegc_push(struct xfs_mount *mp); void xfs_inodegc_flush(struct xfs_mount *mp); void xfs_inodegc_stop(struct xfs_mount *mp); void xfs_inodegc_start(struct xfs_mount *mp); diff --git a/fs/xfs/xfs_qm_syscalls.c b/fs/xfs/xfs_qm_syscalls.c index 47fe60e1a887..322a111dfbc0 100644 --- a/fs/xfs/xfs_qm_syscalls.c +++ b/fs/xfs/xfs_qm_syscalls.c @@ -481,9 +481,12 @@ xfs_qm_scall_getquota( struct xfs_dquot *dqp; int error; - /* Flush inodegc work at the start of a quota reporting scan. */ + /* + * Expedite pending inodegc work at the start of a quota reporting + * scan but don't block waiting for it to complete. + */ if (id == 0) - xfs_inodegc_flush(mp); + xfs_inodegc_push(mp); /* * Try to get the dquot. We don't want it allocated on disk, so don't @@ -525,7 +528,7 @@ xfs_qm_scall_getquota_next( /* Flush inodegc work at the start of a quota reporting scan. */ if (*id == 0) - xfs_inodegc_flush(mp); + xfs_inodegc_push(mp); error = xfs_qm_dqget_next(mp, *id, type, &dqp); if (error) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 8fe6ca9208de..9b3af7611eaa 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -795,8 +795,11 @@ xfs_fs_statfs( xfs_extlen_t lsize; int64_t ffree; - /* Wait for whatever inactivations are in progress. */ - xfs_inodegc_flush(mp); + /* + * Expedite background inodegc but don't wait. We do not want to block + * here waiting hours for a billion extent file to be truncated. + */ + xfs_inodegc_push(mp); statp->f_type = XFS_SUPER_MAGIC; statp->f_namelen = MAXNAMELEN - 1; diff --git a/fs/xfs/xfs_trace.h b/fs/xfs/xfs_trace.h index 1033a95fbf8e..ebd17ddba024 100644 --- a/fs/xfs/xfs_trace.h +++ b/fs/xfs/xfs_trace.h @@ -240,6 +240,7 @@ DEFINE_EVENT(xfs_fs_class, name, \ TP_PROTO(struct xfs_mount *mp, void *caller_ip), \ TP_ARGS(mp, caller_ip)) DEFINE_FS_EVENT(xfs_inodegc_flush); +DEFINE_FS_EVENT(xfs_inodegc_push); DEFINE_FS_EVENT(xfs_inodegc_start); DEFINE_FS_EVENT(xfs_inodegc_stop); DEFINE_FS_EVENT(xfs_inodegc_queue); From patchwork Fri Sep 22 01:01:53 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13394855 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 6A78BE7D0BD for ; Fri, 22 Sep 2023 01:02:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229975AbjIVBCM (ORCPT ); Thu, 21 Sep 2023 21:02:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229936AbjIVBCK (ORCPT ); Thu, 21 Sep 2023 21:02:10 -0400 Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 989BB191; Thu, 21 Sep 2023 18:02:04 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-517ab9a4a13so1154617a12.1; Thu, 21 Sep 2023 18:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695344524; x=1695949324; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=j4RpEijZkHhrZhok0AVAG9y8sjWcEhatG6TrQcYg+Rk=; b=VE8DJYTchENIckpeTkz0DjpTLxInLx8u7B4g1Kow99Epn36D+uUT2cfe3gesYWIUgS 4IeCivuUnGql+Q3bIbXmJFxdsHLPj5Vo4TiRL7+C1uGEb/dOkeCJ0vcOc9dYjSqAgc0W V0flqUilDn+dEhFKDdyZjlSkhXUVEBRLGM6cDLovizDA0IfR3+S0Q0zwXPykSXiyCwXn 9dJELxJFh9i/qey7aaM+WonR3bIMiMzD1Yzx+qt2+Xkgf2TujIxJOJAsq0FB4rYgJZc+ sY1o8xq1qE2w7OPHHGWnsnhuqXJ/CB0X6KWky83ay1pc2hWsjujbhqYN4VqjfK6MZjwU yqgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695344524; x=1695949324; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=j4RpEijZkHhrZhok0AVAG9y8sjWcEhatG6TrQcYg+Rk=; b=L3qmB2Lkr/yMHfrjAHJkDYJaElKO5NwqNWCkDMPeCNF3IKvB+1gEEr0+SpHSCGcZnO /+jwtqr0FsGvbIvzaClr3NVrMdiYRbBX/JQPamrTqQxMeuWLNHiumAgU2tXXx02UkbxO JCvbn8m5w5LHFSaFChhblDPEPwD1rX5MDb0Vxty/2JKIDAbugwwFkqBiMLy5+mbEmmop Wf54vtghlD34KmsWcV8xNCAMZwe9DmU3EzU3AugxA9Ftsp4f0CkO93XOg2+F9XD/YywG W/zjn5aNcN6/Ec4H0ZGkGBGygd3eYoYTnah3yoc5CWIG0v4uE2AfGTVSglcIVIyMfKJt beaA== X-Gm-Message-State: AOJu0YxHl05l58CishRnUDmScMlwuiaqm1oAAVyV4zw7AT18K15TGeyd e+YLCOZcNdTePC2UPOfVdTLOPwevw6Uxtg== X-Google-Smtp-Source: AGHT+IEPdUDx33rJnEJYgcT1KfTEkHAsW96L9CiCvIMYSUMYhtq99kFMe1fRhDkmm4Q9Z/tOUCigtg== X-Received: by 2002:a05:6a21:a5a3:b0:153:40c3:aa71 with SMTP id gd35-20020a056a21a5a300b0015340c3aa71mr9188349pzc.43.1695344523834; Thu, 21 Sep 2023 18:02:03 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2a3:200:d5ff:b7b0:7028:8af6]) by smtp.gmail.com with ESMTPSA id u2-20020a17090282c200b001bc445e2497sm2178815plz.79.2023.09.21.18.02.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 18:02:03 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, "Darrick J. Wong" , Dave Chinner , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 3/6] xfs: explicitly specify cpu when forcing inodegc delayed work to run immediately Date: Thu, 21 Sep 2023 18:01:53 -0700 Message-ID: <20230922010156.1718782-3-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.42.0.515.g380fc7ccd1-goog In-Reply-To: <20230922010156.1718782-1-leah.rumancik@gmail.com> References: <20230922010156.1718782-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 03e0add80f4cf3f7393edb574eeb3a89a1db7758 ] I've been noticing odd racing behavior in the inodegc code that could only be explained by one cpu adding an inode to its inactivation llist at the same time that another cpu is processing that cpu's llist. Preemption is disabled between get/put_cpu_ptr, so the only explanation is scheduler mayhem. I inserted the following debug code into xfs_inodegc_worker (see the next patch): ASSERT(gc->cpu == smp_processor_id()); This assertion tripped during overnight tests on the arm64 machines, but curiously not on x86_64. I think we haven't observed any resource leaks here because the lockfree list code can handle simultaneous llist_add and llist_del_all functions operating on the same list. However, the whole point of having percpu inodegc lists is to take advantage of warm memory caches by inactivating inodes on the last processor to touch the inode. The incorrect scheduling seems to occur after an inodegc worker is subjected to mod_delayed_work(). This wraps mod_delayed_work_on with WORK_CPU_UNBOUND specified as the cpu number. Unbound allows for scheduling on any cpu, not necessarily the same one that scheduled the work. Because preemption is disabled for as long as we have the gc pointer, I think it's safe to use current_cpu() (aka smp_processor_id) to queue the delayed work item on the correct cpu. Fixes: 7cf2b0f9611b ("xfs: bound maximum wait time for inodegc work") Signed-off-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_icache.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index e9ebfe6f8015..ab8181f8d08a 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -2057,7 +2057,8 @@ xfs_inodegc_queue( queue_delay = 0; trace_xfs_inodegc_queue(mp, __return_address); - mod_delayed_work(mp->m_inodegc_wq, &gc->work, queue_delay); + mod_delayed_work_on(current_cpu(), mp->m_inodegc_wq, &gc->work, + queue_delay); put_cpu_ptr(gc); if (xfs_inodegc_want_flush_work(ip, items, shrinker_hits)) { @@ -2101,7 +2102,8 @@ xfs_inodegc_cpu_dead( if (xfs_is_inodegc_enabled(mp)) { trace_xfs_inodegc_queue(mp, __return_address); - mod_delayed_work(mp->m_inodegc_wq, &gc->work, 0); + mod_delayed_work_on(current_cpu(), mp->m_inodegc_wq, &gc->work, + 0); } put_cpu_ptr(gc); } From patchwork Fri Sep 22 01:01:54 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13394857 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 74A4EE7D0C0 for ; Fri, 22 Sep 2023 01:02:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229982AbjIVBCM (ORCPT ); Thu, 21 Sep 2023 21:02:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229931AbjIVBCL (ORCPT ); Thu, 21 Sep 2023 21:02:11 -0400 Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B491B192; Thu, 21 Sep 2023 18:02:05 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-578a91ac815so1236360a12.1; Thu, 21 Sep 2023 18:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695344525; x=1695949325; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5KzxESXZkFDTp3cAkXdAn0yBd85C7ZZTAhXTSFq606w=; b=FqBkDtaX/Ea5bGzIwYj9BtMovBy16QgvEs0h/x2CxJaR1WNhNMX3JZO6vR41mcORGA Xp5fXwJ+IwrzzJgAmDrbRNQNe0pjGXAQ+0VmhYSJdiEo10vwAqOWgnOsN1wdmw/DOZw+ CwiT4Mq+bzDZClXqMe0gTTw2M6wCgNXcms+fcgQHR6TXcEpRdjZDCv6Pwg9sueXFn6YJ rypN0XTWF9pZXFWXmFFdWRJkS+bdSSpoKGUTTkL0BzVoyf7vHetCUvw00wSzCFOq7R99 CtzPXJ2nqJukW2EE1t4ZC6cpjGf3ifgKW/g5KP0IR2FgAYxi0vDhujJi+B5rmm3DXHgK DjCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695344525; x=1695949325; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5KzxESXZkFDTp3cAkXdAn0yBd85C7ZZTAhXTSFq606w=; b=kmgXSRweO2f+vrF/YM+q0/v8vGOyg6M/TgXOjtyqnvh8aGa6jZMlkepQadRw6J/VEc 9Y59vW12OnIy6Q5anXrdVzwkOhURMKntllqwIuzm35W8yWnFiSAFwG+jeQJUYW6VIlmj J5FP+4+M9nY2bymIRgPWw3BWwxAAA76r5ITdGeIWDoACvutJUhapzDxAzix88eyyxqhE aiSUGU8qi6M3yJ+4C06zfV+GhM7PXUmMKb64t2ZsPf5W+1EKJnFQ0xo+VqrhRpqNWnGh iwQvQ9VmvW97euF47t7psSmYyuKWjFkpuJdNJD77gp1Git6a2atr0s/FC7aD41VQxTcn 7XTA== X-Gm-Message-State: AOJu0YxeE7GR0v/Iscsz6K33jfIEZ6gEaY6MbzLL9ysur9RPKiF1lzSz XyjKiPWcq2sEr9eKlo/CvFiuF1DLsSRnGg== X-Google-Smtp-Source: AGHT+IHz+rmFhGYxkc2yBrjyXvYlXVvmndGszepY/GJRL6ByHqffYXuw57OLi2XBPqaiYzqbYLWxxg== X-Received: by 2002:a17:90b:314c:b0:26d:b12:8383 with SMTP id ip12-20020a17090b314c00b0026d0b128383mr7151444pjb.8.1695344524952; Thu, 21 Sep 2023 18:02:04 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2a3:200:d5ff:b7b0:7028:8af6]) by smtp.gmail.com with ESMTPSA id u2-20020a17090282c200b001bc445e2497sm2178815plz.79.2023.09.21.18.02.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 18:02:04 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, "Darrick J. Wong" , Dave Chinner , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 4/6] xfs: check that per-cpu inodegc workers actually run on that cpu Date: Thu, 21 Sep 2023 18:01:54 -0700 Message-ID: <20230922010156.1718782-4-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.42.0.515.g380fc7ccd1-goog In-Reply-To: <20230922010156.1718782-1-leah.rumancik@gmail.com> References: <20230922010156.1718782-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 b37c4c8339cd394ea6b8b415026603320a185651 ] Now that we've allegedly worked out the problem of the per-cpu inodegc workers being scheduled on the wrong cpu, let's put in a debugging knob to let us know if a worker ever gets mis-scheduled again. Signed-off-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_icache.c | 2 ++ fs/xfs/xfs_mount.h | 3 +++ fs/xfs/xfs_super.c | 3 +++ 3 files changed, 8 insertions(+) diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index ab8181f8d08a..02022164772d 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -1856,6 +1856,8 @@ xfs_inodegc_worker( struct llist_node *node = llist_del_all(&gc->list); struct xfs_inode *ip, *n; + ASSERT(gc->cpu == smp_processor_id()); + WRITE_ONCE(gc->items, 0); if (!node) diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 3d58938a6f75..29f35169bf9c 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -66,6 +66,9 @@ struct xfs_inodegc { /* approximate count of inodes in the list */ unsigned int items; unsigned int shrinker_hits; +#if defined(DEBUG) || defined(XFS_WARN) + unsigned int cpu; +#endif }; /* diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 9b3af7611eaa..569960e4ea3a 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1062,6 +1062,9 @@ xfs_inodegc_init_percpu( for_each_possible_cpu(cpu) { gc = per_cpu_ptr(mp->m_inodegc, cpu); +#if defined(DEBUG) || defined(XFS_WARN) + gc->cpu = cpu; +#endif init_llist_head(&gc->list); gc->items = 0; INIT_DELAYED_WORK(&gc->work, xfs_inodegc_worker); From patchwork Fri Sep 22 01:01:55 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13394858 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 64BB7E7D0BB for ; Fri, 22 Sep 2023 01:02:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229931AbjIVBCO (ORCPT ); Thu, 21 Sep 2023 21:02:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230022AbjIVBCN (ORCPT ); Thu, 21 Sep 2023 21:02:13 -0400 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D211F18F; Thu, 21 Sep 2023 18:02:06 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1c44c7dbaf9so14348825ad.1; Thu, 21 Sep 2023 18:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695344526; x=1695949326; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=CpuIb36KvZnpZfH7+q/puboxyBEihDDT25sPVXr25tY=; b=eaacrl5UHGu33xz7lX1M9Tt1fMv6457QMhBKmbdnHT3v3oHprK90N3ex+wcAIuwT+f In4ySBSWg7bqBvtsCA9xoYXx/muEMRWdAWSX3Ha1t/K0lBn9JD2BlzOnLvmve/TpUF4W CuQU9Ezy6ZijA/JQjETXnavOh5ND/9PRM2+4enkEwemTdHbEbcEHsTi9zRRdYxKLeyXY 3/9h56Sy0wRpuGEFGotBFe+MnFv3QGqcTMcLXMtREQXP4CtAPlQ5ZfAvDXq/tk/2Ekqc uMH8v+THuvUJ3RKyys+j8e/IEZB2w7LfWm/DQa85c7aBJ1u0fAgfs7YINobR5xhpWqoV YrNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695344526; x=1695949326; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CpuIb36KvZnpZfH7+q/puboxyBEihDDT25sPVXr25tY=; b=bGcBTIZePMLyMPW0n9eR9eiNdtte3zISYy5a+7cd0JFGgZYb9z0lwJi3LhhaHyoryW /d6A9s2WG3b5+3IMh/HhfxUdtGcdlAhoNHtUDd0Y+wnOofxRb3vrFqZMML+dBXreTJyj cJL1UG1VnfOQtT9TdvZ+hn36n21zWsxYUXP4sG/a+cnDf1HXT/IXtNuQtZANJXrl/rZj 3ExzlOEagCe6OJPgUOHotN4Z+O7j626JZPI0Tk/i8xynPVrtVimIJ+ojtCOXh1Hvbl9T flAhGVLe6TYCfwdOI2C5f3QAMc9m8EJdzWyTnuaCPtWlkccf3UY1C/KIqzMaZu4Lpbj4 vUHQ== X-Gm-Message-State: AOJu0Yzr8tdLofcA1z6pl7b/EkzL8ODWYRYOAP7uEgHa609J1Uenos+7 XA88zgGaxZNSTnF/66SSbT6Sg9yMw27mMQ== X-Google-Smtp-Source: AGHT+IGmoy2zInwdPsn9sHbP/IJvqP99BOqdSwpvTnuMTvCSeIfaG3fW4H6xOeNn1rwhwFaeir0NlQ== X-Received: by 2002:a17:903:2352:b0:1b8:90bd:d157 with SMTP id c18-20020a170903235200b001b890bdd157mr9049343plh.26.1695344526062; Thu, 21 Sep 2023 18:02:06 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2a3:200:d5ff:b7b0:7028:8af6]) by smtp.gmail.com with ESMTPSA id u2-20020a17090282c200b001bc445e2497sm2178815plz.79.2023.09.21.18.02.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 18:02:05 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, "Darrick J. Wong" , Dave Chinner , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 5/6] xfs: disable reaping in fscounters scrub Date: Thu, 21 Sep 2023 18:01:55 -0700 Message-ID: <20230922010156.1718782-5-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.42.0.515.g380fc7ccd1-goog In-Reply-To: <20230922010156.1718782-1-leah.rumancik@gmail.com> References: <20230922010156.1718782-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 2d5f38a31980d7090f5bf91021488dc61a0ba8ee ] The fscounters scrub code doesn't work properly because it cannot quiesce updates to the percpu counters in the filesystem, hence it returns false corruption reports. This has been fixed properly in one of the online repair patchsets that are under review by replacing the xchk_disable_reaping calls with an exclusive filesystem freeze. Disabling background gc isn't sufficient to fix the problem. In other words, scrub doesn't need to call xfs_inodegc_stop, which is just as well since it wasn't correct to allow scrub to call xfs_inodegc_start when something else could be calling xfs_inodegc_stop (e.g. trying to freeze the filesystem). Neuter the scrubber for now, and remove the xchk_*_reaping functions. Signed-off-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/scrub/common.c | 25 ------------------------- fs/xfs/scrub/common.h | 2 -- fs/xfs/scrub/fscounters.c | 13 ++++++------- fs/xfs/scrub/scrub.c | 2 -- fs/xfs/scrub/scrub.h | 1 - 5 files changed, 6 insertions(+), 37 deletions(-) diff --git a/fs/xfs/scrub/common.c b/fs/xfs/scrub/common.c index bf1f3607d0b6..08df23edea72 100644 --- a/fs/xfs/scrub/common.c +++ b/fs/xfs/scrub/common.c @@ -864,28 +864,3 @@ xchk_ilock_inverted( return -EDEADLOCK; } -/* Pause background reaping of resources. */ -void -xchk_stop_reaping( - struct xfs_scrub *sc) -{ - sc->flags |= XCHK_REAPING_DISABLED; - xfs_blockgc_stop(sc->mp); - xfs_inodegc_stop(sc->mp); -} - -/* Restart background reaping of resources. */ -void -xchk_start_reaping( - struct xfs_scrub *sc) -{ - /* - * Readonly filesystems do not perform inactivation or speculative - * preallocation, so there's no need to restart the workers. - */ - if (!xfs_is_readonly(sc->mp)) { - xfs_inodegc_start(sc->mp); - xfs_blockgc_start(sc->mp); - } - sc->flags &= ~XCHK_REAPING_DISABLED; -} diff --git a/fs/xfs/scrub/common.h b/fs/xfs/scrub/common.h index 454145db10e7..2ca80102e704 100644 --- a/fs/xfs/scrub/common.h +++ b/fs/xfs/scrub/common.h @@ -148,7 +148,5 @@ static inline bool xchk_skip_xref(struct xfs_scrub_metadata *sm) int xchk_metadata_inode_forks(struct xfs_scrub *sc); int xchk_ilock_inverted(struct xfs_inode *ip, uint lock_mode); -void xchk_stop_reaping(struct xfs_scrub *sc); -void xchk_start_reaping(struct xfs_scrub *sc); #endif /* __XFS_SCRUB_COMMON_H__ */ diff --git a/fs/xfs/scrub/fscounters.c b/fs/xfs/scrub/fscounters.c index 48a6cbdf95d0..037541339d80 100644 --- a/fs/xfs/scrub/fscounters.c +++ b/fs/xfs/scrub/fscounters.c @@ -128,13 +128,6 @@ xchk_setup_fscounters( if (error) return error; - /* - * Pause background reclaim while we're scrubbing to reduce the - * likelihood of background perturbations to the counters throwing off - * our calculations. - */ - xchk_stop_reaping(sc); - return xchk_trans_alloc(sc, 0); } @@ -353,6 +346,12 @@ xchk_fscounters( if (fdblocks > mp->m_sb.sb_dblocks) xchk_set_corrupt(sc); + /* + * XXX: We can't quiesce percpu counter updates, so exit early. + * This can be re-enabled when we gain exclusive freeze functionality. + */ + return 0; + /* * If ifree exceeds icount by more than the minimum variance then * something's probably wrong with the counters. diff --git a/fs/xfs/scrub/scrub.c b/fs/xfs/scrub/scrub.c index 51e4c61916d2..e4d2a41983f7 100644 --- a/fs/xfs/scrub/scrub.c +++ b/fs/xfs/scrub/scrub.c @@ -171,8 +171,6 @@ xchk_teardown( } if (sc->sm->sm_flags & XFS_SCRUB_IFLAG_REPAIR) mnt_drop_write_file(sc->file); - if (sc->flags & XCHK_REAPING_DISABLED) - xchk_start_reaping(sc); if (sc->flags & XCHK_HAS_QUOTAOFFLOCK) { mutex_unlock(&sc->mp->m_quotainfo->qi_quotaofflock); sc->flags &= ~XCHK_HAS_QUOTAOFFLOCK; diff --git a/fs/xfs/scrub/scrub.h b/fs/xfs/scrub/scrub.h index 80e5026bba44..e8d9fe9de26e 100644 --- a/fs/xfs/scrub/scrub.h +++ b/fs/xfs/scrub/scrub.h @@ -89,7 +89,6 @@ struct xfs_scrub { /* XCHK state flags grow up from zero, XREP state flags grown down from 2^31 */ #define XCHK_TRY_HARDER (1 << 0) /* can't get resources, try again */ #define XCHK_HAS_QUOTAOFFLOCK (1 << 1) /* we hold the quotaoff lock */ -#define XCHK_REAPING_DISABLED (1 << 2) /* background block reaping paused */ #define XREP_ALREADY_FIXED (1 << 31) /* checking our repair work */ /* Metadata scrubbers */ From patchwork Fri Sep 22 01:01:56 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leah Rumancik X-Patchwork-Id: 13394859 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 D17E3E7D0C2 for ; Fri, 22 Sep 2023 01:02:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230031AbjIVBCO (ORCPT ); Thu, 21 Sep 2023 21:02:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229596AbjIVBCN (ORCPT ); Thu, 21 Sep 2023 21:02:13 -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 C9885191; Thu, 21 Sep 2023 18:02:07 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1c59c40b840so14732805ad.3; Thu, 21 Sep 2023 18:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695344527; x=1695949327; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5EQwThOiasL4de5Y5vJ+ZLwZXFoPo1unIHxbqTwkXC8=; b=ERMOA85BazzCj7u5gk3carKu3tcRfeXsc9XTfVxfNkvCsF7+u0cbeB+aT6QPSsp/Fz +GvQIGyfKHekxZsmk8E00aR8jcnB/ww1a7EWmJwbEyzJodHQ1IVoT5DLWTx4ScPWqVBa ocIqZTBFkdc6yqSKx9nkxBBUiR9Ci4ksFS+xQHow3jSJD8bc+6CnzXZLrF8OKEcFDeqx xTUd5x3xhxwUQyfUaE7Ch3QCBtV35jHl3LTgPfsdamXDvhm5EavBtlrpmVtgl5OiPAhr KJjZpozISXbyuXNdFIUQDFl5nWbGfjFaAI1Qb6PrmmGWqjVNQSDcZRjQ194FkMcVa+dI riRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695344527; x=1695949327; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5EQwThOiasL4de5Y5vJ+ZLwZXFoPo1unIHxbqTwkXC8=; b=AkUQltsGSGUTBbPdezGpAT8puepzB3EM5XH0rgCiM2j6iZ0zw4e+z2myIFBE0Hkuml 8As90FSs11Q2Kwbhnr31mXNLCyCSXFz7XEbp7Ulfzf8Xm6FuR9hHuCxqhPh4QkY588RH JVKlyDNdB4kbBMp3jjUj67mBVJ0Tc94IvlIvfXCoycCwjGwlQ7GeKx8y2rSW+wFNtPPl RWhcdeMZQnLBXktgn/UW/61WmJ8ECNdotUbZ4+1PMuiDGA/1zkS00hFZSED2S3g6qOeW xO8nrUMdyvDRGImH6M2ISWMswjqm61xq47qbSDBGFZqkoD33w/jbfx+cPTBPY4pybG7I WJIQ== X-Gm-Message-State: AOJu0YxEltKiwPCOc01K+esjQkL31L90b4J3+0M5+gO15RBtgoHXq4gO RInr2rGZL0u8qWe00HeqvDgorAQlfaHeBQ== X-Google-Smtp-Source: AGHT+IH5MjAHpRSKHDzuu+1w7S2b6diJbtxDrdjHHxc51XoPVd/FrrmjiDSGio4AcAs6/mz29RBfjg== X-Received: by 2002:a17:90a:bb8b:b0:268:b682:23de with SMTP id v11-20020a17090abb8b00b00268b68223demr7562891pjr.28.1695344527027; Thu, 21 Sep 2023 18:02:07 -0700 (PDT) Received: from lrumancik.svl.corp.google.com ([2620:15c:2a3:200:d5ff:b7b0:7028:8af6]) by smtp.gmail.com with ESMTPSA id u2-20020a17090282c200b001bc445e2497sm2178815plz.79.2023.09.21.18.02.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 18:02:06 -0700 (PDT) From: Leah Rumancik To: stable@vger.kernel.org Cc: linux-xfs@vger.kernel.org, amir73il@gmail.com, chandan.babu@oracle.com, "Darrick J. Wong" , Dave Chinner , Dave Chinner , Leah Rumancik Subject: [PATCH 5.15 6/6] xfs: fix xfs_inodegc_stop racing with mod_delayed_work Date: Thu, 21 Sep 2023 18:01:56 -0700 Message-ID: <20230922010156.1718782-6-leah.rumancik@gmail.com> X-Mailer: git-send-email 2.42.0.515.g380fc7ccd1-goog In-Reply-To: <20230922010156.1718782-1-leah.rumancik@gmail.com> References: <20230922010156.1718782-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 2254a7396a0ca6309854948ee1c0a33fa4268cec ] syzbot reported this warning from the faux inodegc shrinker that tries to kick off inodegc work: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 102 at kernel/workqueue.c:1445 __queue_work+0xd44/0x1120 kernel/workqueue.c:1444 RIP: 0010:__queue_work+0xd44/0x1120 kernel/workqueue.c:1444 Call Trace: __queue_delayed_work+0x1c8/0x270 kernel/workqueue.c:1672 mod_delayed_work_on+0xe1/0x220 kernel/workqueue.c:1746 xfs_inodegc_shrinker_scan fs/xfs/xfs_icache.c:2212 [inline] xfs_inodegc_shrinker_scan+0x250/0x4f0 fs/xfs/xfs_icache.c:2191 do_shrink_slab+0x428/0xaa0 mm/vmscan.c:853 shrink_slab+0x175/0x660 mm/vmscan.c:1013 shrink_one+0x502/0x810 mm/vmscan.c:5343 shrink_many mm/vmscan.c:5394 [inline] lru_gen_shrink_node mm/vmscan.c:5511 [inline] shrink_node+0x2064/0x35f0 mm/vmscan.c:6459 kswapd_shrink_node mm/vmscan.c:7262 [inline] balance_pgdat+0xa02/0x1ac0 mm/vmscan.c:7452 kswapd+0x677/0xd60 mm/vmscan.c:7712 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 This warning corresponds to this code in __queue_work: /* * For a draining wq, only works from the same workqueue are * allowed. The __WQ_DESTROYING helps to spot the issue that * queues a new work item to a wq after destroy_workqueue(wq). */ if (unlikely(wq->flags & (__WQ_DESTROYING | __WQ_DRAINING) && WARN_ON_ONCE(!is_chained_work(wq)))) return; For this to trip, we must have a thread draining the inodedgc workqueue and a second thread trying to queue inodegc work to that workqueue. This can happen if freezing or a ro remount race with reclaim poking our faux inodegc shrinker and another thread dropping an unlinked O_RDONLY file: Thread 0 Thread 1 Thread 2 xfs_inodegc_stop xfs_inodegc_shrinker_scan xfs_is_inodegc_enabled xfs_clear_inodegc_enabled xfs_inodegc_queue_all xfs_inodegc_queue xfs_is_inodegc_enabled drain_workqueue llist_empty mod_delayed_work_on(..., 0) __queue_work In other words, everything between the access to inodegc_enabled state and the decision to poke the inodegc workqueue requires some kind of coordination to avoid the WQ_DRAINING state. We could perhaps introduce a lock here, but we could also try to eliminate WQ_DRAINING from the picture. We could replace the drain_workqueue call with a loop that flushes the workqueue and queues workers as long as there is at least one inode present in the per-cpu inodegc llists. We've disabled inodegc at this point, so we know that the number of queued inodes will eventually hit zero as long as xfs_inodegc_start cannot reactivate the workers. There are four callers of xfs_inodegc_start. Three of them come from the VFS with s_umount held: filesystem thawing, failed filesystem freezing, and the rw remount transition. The fourth caller is mounting rw (no remount or freezing possible). There are three callers ofs xfs_inodegc_stop. One is unmounting (no remount or thaw possible). Two of them come from the VFS with s_umount held: fs freezing and ro remount transition. Hence, it is correct to replace the drain_workqueue call with a loop that drains the inodegc llists. Fixes: 6191cf3ad59f ("xfs: flush inodegc workqueue tasks before cancel") Signed-off-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_icache.c | 32 +++++++++++++++++++++++++++----- 1 file changed, 27 insertions(+), 5 deletions(-) diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index 02022164772d..eab98d76dbe1 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -448,18 +448,23 @@ xfs_iget_check_free_state( } /* Make all pending inactivation work start immediately. */ -static void +static bool xfs_inodegc_queue_all( struct xfs_mount *mp) { struct xfs_inodegc *gc; int cpu; + bool ret = false; for_each_online_cpu(cpu) { gc = per_cpu_ptr(mp->m_inodegc, cpu); - if (!llist_empty(&gc->list)) + if (!llist_empty(&gc->list)) { mod_delayed_work_on(cpu, mp->m_inodegc_wq, &gc->work, 0); + ret = true; + } } + + return ret; } /* @@ -1902,24 +1907,41 @@ xfs_inodegc_flush( /* * Flush all the pending work and then disable the inode inactivation background - * workers and wait for them to stop. + * workers and wait for them to stop. Caller must hold sb->s_umount to + * coordinate changes in the inodegc_enabled state. */ void xfs_inodegc_stop( struct xfs_mount *mp) { + bool rerun; + if (!xfs_clear_inodegc_enabled(mp)) return; + /* + * Drain all pending inodegc work, including inodes that could be + * queued by racing xfs_inodegc_queue or xfs_inodegc_shrinker_scan + * threads that sample the inodegc state just prior to us clearing it. + * The inodegc flag state prevents new threads from queuing more + * inodes, so we queue pending work items and flush the workqueue until + * all inodegc lists are empty. IOWs, we cannot use drain_workqueue + * here because it does not allow other unserialized mechanisms to + * reschedule inodegc work while this draining is in progress. + */ xfs_inodegc_queue_all(mp); - drain_workqueue(mp->m_inodegc_wq); + do { + flush_workqueue(mp->m_inodegc_wq); + rerun = xfs_inodegc_queue_all(mp); + } while (rerun); trace_xfs_inodegc_stop(mp, __return_address); } /* * Enable the inode inactivation background workers and schedule deferred inode - * inactivation work if there is any. + * inactivation work if there is any. Caller must hold sb->s_umount to + * coordinate changes in the inodegc_enabled state. */ void xfs_inodegc_start(