From patchwork Thu Nov 21 00:09:17 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13881515 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D4EC91FB3 for ; Thu, 21 Nov 2024 00:09:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732147758; cv=none; b=t2FferxU7LxKJeVdPu51JhLi/nsMssmvH3M8unZx0GV7zX3e1Qw+Fzc8fny9C+O90ctFfDo3/OsqGzXuBo+TDtAQMh8KmJ7nXkWHVlLyMlhtYALB8NSWkCT3qMBoNwJDJMBeg50WARypQCQ6laRx51TUn7sVWN2EsOlUMRPxYrY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732147758; c=relaxed/simple; bh=QOprdwHxtiRl2iLJMI9EclOGQokjqUq09FKeLPDixOI=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=B5T67ia5Dvioqphq7B2fwumJePh7kdkTEV7dyvOAzJmFdsjeq2yI9giIECPZg5xzQGpcoW8rO+BMYSTupA8wXhi8ZiqSF9kkZ37TNCxt5hSLsTvhUhM1BMXvRLWOb5qLtf4doxhAXdjme2l4R2GriIo1TNTjTO+qmrJ6FfCk8mw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=A3A28qV5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="A3A28qV5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74132C4CECD; Thu, 21 Nov 2024 00:09:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732147758; bh=QOprdwHxtiRl2iLJMI9EclOGQokjqUq09FKeLPDixOI=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=A3A28qV5CxOt5HbAX/K/arHcBVoztupDPgFgDQxV4jzXzAoQWjjadgDWhfwOCLv8e 8qPgzYfL8J6tkvnM7Cm/EWaUgT5xN2VFp0bv3QE0hs19ck0bEc0D/q60TmVvvfvK8N i2lH4XuusIOfK9XfWdFlSScubXbshfJytx++id+Acj9JkMkkLv7on5qYX+QaSZrRKY iL2f6MfLMg3Pki4dbSuk76YqQBIxO3SfUD12ByXKzZdENSNCK+bQFpaNdPVdrxizPn bYg/JNCi+/2+3MZVi/GcK7kXw1OZEHGMi8fKGJXq45hF59yl5qYjP63XXUvXb/xRDd WZ9xjfRZD1JNA== Date: Wed, 20 Nov 2024 16:09:17 -0800 Subject: [PATCH 1/2] xfs_repair: fix crasher in pf_queuing_worker From: "Darrick J. Wong" To: aalbersh@kernel.org, djwong@kernel.org Cc: linux-xfs@vger.kernel.org, hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <173214768846.2957531.5698670827220673337.stgit@frogsfrogsfrogs> In-Reply-To: <173214768829.2957531.4071177223892485486.stgit@frogsfrogsfrogs> References: <173214768829.2957531.4071177223892485486.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Don't walk off the end of the inode records when we're skipping inodes for prefetching. The skip loop doesn't make sense to me -- why we ignore the first N inodes but don't care what number they are makes little sense to me. But let's fix xfs/155 to crash less, eh? Cc: # v2.10.0 Fixes: 2556c98bd9e6b2 ("Perform true sequential bulk read prefetching in xfs_repair Merge of master-melb:xfs-cmds:29147a by kenmcd.") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- repair/prefetch.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/repair/prefetch.c b/repair/prefetch.c index 998797e3696bac..0772ecef9d73eb 100644 --- a/repair/prefetch.c +++ b/repair/prefetch.c @@ -764,6 +764,8 @@ pf_queuing_worker( irec = next_ino_rec(irec); num_inos += XFS_INODES_PER_CHUNK; } + if (!irec) + break; if (args->dirs_only && cur_irec->ino_isa_dir == 0) continue; From patchwork Thu Nov 21 00:09:33 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13881516 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A35FA29B0 for ; Thu, 21 Nov 2024 00:09:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732147774; cv=none; b=kUcbeEglQqdUKQgmqR5h3u2LXNrjCNv6qxnBkgEc06ZcDNt0SlQqjAkKrxSw4IW8mjejzQdyHAeD+x4BP8F4WG12IObIrZ958B1tTS0VKC/P75ycpTOIbtSISuSjUfvpOC1wUwUzkmvmnV7PUrWHG9lecAC+IfoZjjAaIyKnkvc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732147774; c=relaxed/simple; bh=ixMdGknki2mXLtQRo5rQKCiJblO627x+/Bxn+Q/+G3o=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=oMF+1OfFyN90Yxk71nCe4IH+/L6lFrxLJiv2BUXBmAm5CR4OjQNHr3TPq/wQ9bgEfcnhQ7CDcdQ+rsXViDVZW6dLhsBjHpScOvpGVROS1k8sG9g0wQwEyTZKRJnifJysoAdAEbsKavRZeUsftQrC+1JS5Er1Zn0wwLyva7FnU3Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Of5vu465; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Of5vu465" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29871C4CECD; Thu, 21 Nov 2024 00:09:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732147774; bh=ixMdGknki2mXLtQRo5rQKCiJblO627x+/Bxn+Q/+G3o=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=Of5vu465NAHdjGRjCS9oWjmIXsL1w0CQR0upNalP9nMjQZHi8ymXaOqm0M1hnVb0P AxfGLrLLwsuO1W9B0YOKiRbqVCpSknMExadXfe1rkwHTF47p36XBkfKMqb10yNmRrd cx127qOjSXqo73rU1q3gLQuT+rW2dFFkJQ/FymZvTJKfhzHYBpOnTjqFonyhar3bxn e3KM2A482Es0x3RRu7JkptsmQs/X6xR+NsXOIxb2PIPtvLV5DPx2eg2fcXfdR8oNfC fNNAcxy712FneoUj44nLSD2/5tuf9/VBUuu5SykhSp4zgojEyX9u107ld8WKlLEejP TehKIHJsn5p5A== Date: Wed, 20 Nov 2024 16:09:33 -0800 Subject: [PATCH 2/2] xfs_repair: synthesize incore inode tree records when required From: "Darrick J. Wong" To: aalbersh@kernel.org, djwong@kernel.org Cc: hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <173214768860.2957531.16129692070811504220.stgit@frogsfrogsfrogs> In-Reply-To: <173214768829.2957531.4071177223892485486.stgit@frogsfrogsfrogs> References: <173214768829.2957531.4071177223892485486.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong On a filesystem with 64k fsblock size, xfs/093 fails with the following: Phase 3 - for each AG... - scan and clear agi unlinked lists... found inodes not in the inode allocation tree found inodes not in the inode allocation tree - process known inodes and perform inode discovery... - agno = 0 xfs_repair: dino_chunks.c:1166: process_aginodes: Assertion `num_inos == igeo->ialloc_inos' failed. ./common/xfs: line 392: 361225 Aborted (core dumped) $XFS_REPAIR_PROG $SCRATCH_OPTIONS $* $SCRATCH_DEV In this situation, the inode size is 512b, which means that two inobt records map to a single fs block. However, the inobt walk didn't find the second record, so it didn't create a second incore ino_tree_node_t object. The assertion trips, and we fail to repair the filesystem. To fix this, synthesize incore inode records when we know that they must exist. Mark the inodes as in use so that they will not be purged from parent directories or moved to lost+found if the directory tree is also compromised. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- repair/dino_chunks.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/repair/dino_chunks.c b/repair/dino_chunks.c index 1953613345190d..86e29dd9ae05eb 100644 --- a/repair/dino_chunks.c +++ b/repair/dino_chunks.c @@ -1050,6 +1050,8 @@ process_aginodes( first_ino_rec = ino_rec = findfirst_inode_rec(agno); while (ino_rec != NULL) { + xfs_agino_t synth_agino; + /* * paranoia - step through inode records until we step * through a full allocation of inodes. this could @@ -1068,6 +1070,32 @@ process_aginodes( num_inos += XFS_INODES_PER_CHUNK; } + /* + * We didn't find all the inobt records for this block, so the + * incore tree is missing a few records. This implies that the + * inobt is heavily damaged, so synthesize the incore records. + * Mark all the inodes in use to minimize data loss. + */ + for (synth_agino = first_ino_rec->ino_startnum + num_inos; + num_inos < igeo->ialloc_inos; + synth_agino += XFS_INODES_PER_CHUNK, + num_inos += XFS_INODES_PER_CHUNK) { + int i; + + ino_rec = find_inode_rec(mp, agno, synth_agino); + if (ino_rec) + continue; + + ino_rec = set_inode_free_alloc(mp, agno, synth_agino); + do_warn( + _("found inobt record for inode %" PRIu64 " but not inode %" PRIu64 ", pretending that we did\n"), + XFS_AGINO_TO_INO(mp, agno, + first_ino_rec->ino_startnum), + XFS_AGINO_TO_INO(mp, agno, + synth_agino)); + for (i = 0; i < XFS_INODES_PER_CHUNK; i++) + set_inode_used(ino_rec, i); + } ASSERT(num_inos == igeo->ialloc_inos); if (pf_args) {