From patchwork Sun Jun 6 17:54:11 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12302111 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DFDAC47096 for ; Sun, 6 Jun 2021 17:54:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4963E6139A for ; Sun, 6 Jun 2021 17:54:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229885AbhFFR4C (ORCPT ); Sun, 6 Jun 2021 13:56:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:56726 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229738AbhFFR4B (ORCPT ); Sun, 6 Jun 2021 13:56:01 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BD1836139A; Sun, 6 Jun 2021 17:54:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623002051; bh=hHkTLLNaaovZxIWWULcwhSDsdFDSwPKH5SluN+ZB5+c=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=nnrIIKjI1jDx9Fvk+2MHFthYs8NjgDgq9dgce7k39bO9U6Jp9R1CMlzmmmM2ff0YS G8ILRWDWf9cWXp3pLAJ/Hz6Lhr6Ja6/2MHlYByqELAKkIvSDNN9vKwkGUdQQRA5ru5 6GjE+xp+GSUl/Y3XfVQb8cX3LZCmzf5hV05gvhZ6Ny5E9JaJC8f8kkZawG41p3XprE iQu0FRFd1gsJHnmInRZ0dMgan04Nu54vXZ3JFRW9B6AlmFq4uTdAUi0GHxh+9dACFT kb3j/ENAZG1xOeuMkE6fLBWxnjzvPai3+sXx8NwT1Y4smNGyTs1k0A2aeyxYMO/8jh rn+DlwpH7KVDQ== Subject: [PATCH 1/3] xfs: only reset incore inode health state flags when reclaiming an inode From: "Darrick J. Wong" To: djwong@kernel.org Cc: Brian Foster , Dave Chinner , linux-xfs@vger.kernel.org, david@fromorbit.com, bfoster@redhat.com Date: Sun, 06 Jun 2021 10:54:11 -0700 Message-ID: <162300205146.1202529.12989228054689182888.stgit@locust> In-Reply-To: <162300204472.1202529.17352653046483745148.stgit@locust> References: <162300204472.1202529.17352653046483745148.stgit@locust> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Darrick J. Wong While running some fuzz tests on inode metadata, I noticed that the filesystem health report (as provided by xfs_spaceman) failed to report the file corruption even when spaceman was run immediately after running xfs_scrub to detect the corruption. That isn't the intended behavior; one ought to be able to run scrub to detect errors in the ondisk metadata and be able to access to those reports for some time after the scrub. After running the same sequence through an instrumented kernel, I discovered the reason why -- scrub igets the file, scans it, marks it sick, and ireleases the inode. When the VFS lets go of the incore inode, it moves to RECLAIMABLE state. If spaceman igets the incore inode before it moves to RECLAIM state, iget reinitializes the VFS state, clears the sick and checked masks, and hands back the inode. At this point, the caller has the exact same incore inode, but with all the health state erased. In other words, we're erasing the incore inode's health state flags when we've decided NOT to sever the link between the incore inode and the ondisk inode. This is wrong, so we need to remove the lines that zero the fields from xfs_iget_cache_hit. As a precaution, we add the same lines into xfs_reclaim_inode just after we sever the link between incore and ondisk inode. Strictly speaking this isn't necessary because once an inode has gone through reclaim it must go through xfs_inode_alloc (which also zeroes the state) and xfs_iget is careful to check for mismatches between the inode it pulls out of the radix tree and the one it wants. Fixes: 6772c1f11206 ("xfs: track metadata health status") Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster Reviewed-by: Dave Chinner Reviewed-by: Carlos Maiolino --- fs/xfs/xfs_icache.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index 396cc54ca03f..c3f912a9231b 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -523,9 +523,6 @@ xfs_iget_cache_hit( XFS_INO_TO_AGINO(pag->pag_mount, ino), XFS_ICI_RECLAIM_TAG); inode->i_state = I_NEW; - ip->i_sick = 0; - ip->i_checked = 0; - spin_unlock(&ip->i_flags_lock); spin_unlock(&pag->pag_ici_lock); } else { @@ -979,6 +976,8 @@ xfs_reclaim_inode( spin_lock(&ip->i_flags_lock); ip->i_flags = XFS_IRECLAIM; ip->i_ino = 0; + ip->i_sick = 0; + ip->i_checked = 0; spin_unlock(&ip->i_flags_lock); xfs_iunlock(ip, XFS_ILOCK_EXCL); From patchwork Sun Jun 6 17:54:17 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12302113 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CD1EC47096 for ; Sun, 6 Jun 2021 17:54:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 22F62613DF for ; Sun, 6 Jun 2021 17:54:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229772AbhFFR4H (ORCPT ); Sun, 6 Jun 2021 13:56:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:57014 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229738AbhFFR4H (ORCPT ); Sun, 6 Jun 2021 13:56:07 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 443446139A; Sun, 6 Jun 2021 17:54:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623002057; bh=mgdpANE44ZASUDIqz3yrXfeXgzVmUTiq0/P6SQSEY0g=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=TwFjLj8J6quS6KSYENjem+SWrNibmZLTae44ufoTFYuNXlplRlQAHa1vcF3th5LgB sYsVKMBTyCtuoL//choTdfuWLtxQP3S0cBMuBTeMmEjO0ZMiZdSNgU8zEDauUXN1QJ 5CruNrtldNND9ydJWjZYtFvuqt6IDusrHcQs1KNJAMLl0HbCRkUrtCcXJ0l2nbdYlX L2+2NxruGvxP272EiwmdGOGKJxutoQLi+uLAbxEi83FpvEETtu1bo3B74rgrCQ4wJv 2lCVi/BZpt+JSok/4KGUWEHxkhQR+vtFWrzUBW2mHJQXJ3pzjXbpIocZyzAwcdcSS2 +deIYXc4XkAHw== Subject: [PATCH 2/3] xfs: drop IDONTCACHE on inodes when we mark them sick From: "Darrick J. Wong" To: djwong@kernel.org Cc: linux-xfs@vger.kernel.org, david@fromorbit.com, bfoster@redhat.com Date: Sun, 06 Jun 2021 10:54:17 -0700 Message-ID: <162300205695.1202529.8468586379242468573.stgit@locust> In-Reply-To: <162300204472.1202529.17352653046483745148.stgit@locust> References: <162300204472.1202529.17352653046483745148.stgit@locust> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Darrick J. Wong When we decide to mark an inode sick, clear the DONTCACHE flag so that the incore inode will be kept around until memory pressure forces it out of memory. This increases the chances that the sick status will be caught by someone compiling a health report later on. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Reviewed-by: Carlos Maiolino --- fs/xfs/xfs_health.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/fs/xfs/xfs_health.c b/fs/xfs/xfs_health.c index 8e0cb05a7142..806be8a93ea3 100644 --- a/fs/xfs/xfs_health.c +++ b/fs/xfs/xfs_health.c @@ -231,6 +231,15 @@ xfs_inode_mark_sick( ip->i_sick |= mask; ip->i_checked |= mask; spin_unlock(&ip->i_flags_lock); + + /* + * Keep this inode around so we don't lose the sickness report. Scrub + * grabs inodes with DONTCACHE assuming that most inode are ok, which + * is not the case here. + */ + spin_lock(&VFS_I(ip)->i_lock); + VFS_I(ip)->i_state &= ~I_DONTCACHE; + spin_unlock(&VFS_I(ip)->i_lock); } /* Mark parts of an inode healed. */ From patchwork Sun Jun 6 17:54:22 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12302115 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6934EC47096 for ; Sun, 6 Jun 2021 17:54:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4424D613EF for ; Sun, 6 Jun 2021 17:54:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229738AbhFFR4N (ORCPT ); Sun, 6 Jun 2021 13:56:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:57276 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229474AbhFFR4M (ORCPT ); Sun, 6 Jun 2021 13:56:12 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BDC0D6136D; Sun, 6 Jun 2021 17:54:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623002062; bh=jAQn9pQVvZ3HfZTkxQdFHrA4lC1fiiFN9bSODIv2Zas=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=fF7MbxrFfOyzK07uTlao6XiXTSQfAjclVaMIFCAY++2KGq4e7jJSJ8YBf2+LGQj3m I8VyBBkfQ6jj68jpbZgKwNfZMIXm8B41zR2Qs+ZRiifu/HAEqNY3irhKnrn95a4jpF QsHrT50wfE5p/zL520OF/AHd6K0nlb8Nd1ajn9gzm76two9ZdcXN8TDOqSRcOtmPZp ojI00zoiDc76wIuULfONPfnKGy9dNFlbOjNgcdTdrdxmIFGOf25LerOWKaLrhtRbLh 0HNzX+Z9Er8bias6w4/GrOgt9E5z1pNSWjoJ3iPDAAI8ADjsWZ5A7rzD6wyfa9ZASe 5mjWm2dU96j4A== Subject: [PATCH 3/3] xfs: selectively keep sick inodes in memory From: "Darrick J. Wong" To: djwong@kernel.org Cc: linux-xfs@vger.kernel.org, david@fromorbit.com, bfoster@redhat.com Date: Sun, 06 Jun 2021 10:54:22 -0700 Message-ID: <162300206247.1202529.5752085682714232410.stgit@locust> In-Reply-To: <162300204472.1202529.17352653046483745148.stgit@locust> References: <162300204472.1202529.17352653046483745148.stgit@locust> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org From: Darrick J. Wong It's important that the filesystem retain its memory of sick inodes for a little while after problems are found so that reports can be collected about what was wrong. Don't let inode reclamation free sick inodes unless we're unmounting or the fs already went down. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Reviewed-by: Carlos Maiolino --- fs/xfs/xfs_icache.c | 45 +++++++++++++++++++++++++++++++++++++++------ 1 file changed, 39 insertions(+), 6 deletions(-) diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index c3f912a9231b..53dab8959e1d 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -71,10 +71,13 @@ static int xfs_icwalk_ag(struct xfs_perag *pag, /* Stop scanning after icw_scan_limit inodes. */ #define XFS_ICWALK_FLAG_SCAN_LIMIT (1U << 28) +#define XFS_ICWALK_FLAG_RECLAIM_SICK (1U << 27) + #define XFS_ICWALK_PRIVATE_FLAGS (XFS_ICWALK_FLAG_DROP_UDQUOT | \ XFS_ICWALK_FLAG_DROP_GDQUOT | \ XFS_ICWALK_FLAG_DROP_PDQUOT | \ - XFS_ICWALK_FLAG_SCAN_LIMIT) + XFS_ICWALK_FLAG_SCAN_LIMIT | \ + XFS_ICWALK_FLAG_RECLAIM_SICK) /* * Allocate and initialise an xfs_inode. @@ -910,7 +913,8 @@ xfs_dqrele_all_inodes( */ static bool xfs_reclaim_igrab( - struct xfs_inode *ip) + struct xfs_inode *ip, + struct xfs_eofblocks *eofb) { ASSERT(rcu_read_lock_held()); @@ -921,6 +925,14 @@ xfs_reclaim_igrab( spin_unlock(&ip->i_flags_lock); return false; } + + /* Don't reclaim a sick inode unless the caller asked for it. */ + if (ip->i_sick && + (!eofb || !(eofb->eof_flags & XFS_ICWALK_FLAG_RECLAIM_SICK))) { + spin_unlock(&ip->i_flags_lock); + return false; + } + __xfs_iflags_set(ip, XFS_IRECLAIM); spin_unlock(&ip->i_flags_lock); return true; @@ -1021,13 +1033,30 @@ xfs_reclaim_inode( xfs_iflags_clear(ip, XFS_IRECLAIM); } +/* Reclaim sick inodes if we're unmounting or the fs went down. */ +static inline bool +xfs_want_reclaim_sick( + struct xfs_mount *mp) +{ + return (mp->m_flags & XFS_MOUNT_UNMOUNTING) || + (mp->m_flags & XFS_MOUNT_NORECOVERY) || + XFS_FORCED_SHUTDOWN(mp); +} + void xfs_reclaim_inodes( struct xfs_mount *mp) { + struct xfs_eofblocks eofb = { + .eof_flags = 0, + }; + + if (xfs_want_reclaim_sick(mp)) + eofb.eof_flags |= XFS_ICWALK_FLAG_RECLAIM_SICK; + while (radix_tree_tagged(&mp->m_perag_tree, XFS_ICI_RECLAIM_TAG)) { xfs_ail_push_all_sync(mp->m_ail); - xfs_icwalk(mp, XFS_ICWALK_RECLAIM, NULL); + xfs_icwalk(mp, XFS_ICWALK_RECLAIM, &eofb); } } @@ -1048,6 +1077,9 @@ xfs_reclaim_inodes_nr( .icw_scan_limit = nr_to_scan, }; + if (xfs_want_reclaim_sick(mp)) + eofb.eof_flags |= XFS_ICWALK_FLAG_RECLAIM_SICK; + /* kick background reclaimer and push the AIL */ xfs_reclaim_work_queue(mp); xfs_ail_push_all(mp->m_ail); @@ -1605,7 +1637,8 @@ xfs_blockgc_free_quota( static inline bool xfs_icwalk_igrab( enum xfs_icwalk_goal goal, - struct xfs_inode *ip) + struct xfs_inode *ip, + struct xfs_eofblocks *eofb) { switch (goal) { case XFS_ICWALK_DQRELE: @@ -1613,7 +1646,7 @@ xfs_icwalk_igrab( case XFS_ICWALK_BLOCKGC: return xfs_blockgc_igrab(ip); case XFS_ICWALK_RECLAIM: - return xfs_reclaim_igrab(ip); + return xfs_reclaim_igrab(ip, eofb); default: return false; } @@ -1702,7 +1735,7 @@ xfs_icwalk_ag( for (i = 0; i < nr_found; i++) { struct xfs_inode *ip = batch[i]; - if (done || !xfs_icwalk_igrab(goal, ip)) + if (done || !xfs_icwalk_igrab(goal, ip, eofb)) batch[i] = NULL; /*