From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 525BD378D64 for ; Fri, 17 Jul 2026 19:24:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784316268; cv=none; b=Dnw8mSFJ0o7uIgQ0kIwbqIVlE6jVnBh1q6XyWTLLQji6wPm7gKJBSui9S2ldKc4yYlehlynZ0+GQxs3B6gNjsLpxpMraaHhoGsZinnvLHRiEDEkHQfLSTJxesPhykDfMoI5t7kU7yJOMzcianUxMkrjOQnVkhh2SF0mM55RlLe0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784316268; c=relaxed/simple; bh=i/WgzP6lZuuyNEtMaJY/UWvIQ5UI8hty7FfFBAOERBQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=qH4KEOODvXaZR1pI9TRTlxlEGoebmLNNHgVB0N3gAJ52wlVtxxK33tDoaYvN6y82HsA5RA5BFOV+GXlAnRV1N3xSstFnO2jAUKb9ChuKkWwpFJAN/TF4mKhYUhOdzSoPdbmMdvfMkWhfECNtHXdVxLYsYg1Cqy9g8ZwF46NMjOE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hLk0U/2Z; arc=none smtp.client-ip=209.85.216.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hLk0U/2Z" Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-38d489b6b71so8117783a91.0 for ; Fri, 17 Jul 2026 12:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784316267; x=1784921067; 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:content-type; bh=VBBh4eIvoYVVWqSs1HTvVBO2wVeUL8KYjFpGqJiymeQ=; b=hLk0U/2ZIOqtbfgfA4YhQKqPWIY7gcw0WgPQH92qfamRDYwg4c2390WffYrYfd7Brb Vz37MlvCVHTeTsjs6hE5bFGhQqW0uGt51dMBLQ28enfVrJU/agE8gB4Ok8XxBnNHYhb4 N0Hn5dX6cnxySiAs6NjEx4d7wD0gYCySGfzO/lA1mq8XqOmVvw4+hlXHkn5WyacBaVC1 UfE6enmZZcOjyR+zK16pd116/Iitb1PUleyhBM+hMc1ffB+40k2aTqIeaP5q8o2RL77n GP74VoiCnJYaMJrfdUfXu01EYdhAtdscvXgeR2Zgje8OkVRMzwwRg2S5cqHO15HdKdaj A2JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784316267; x=1784921067; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=VBBh4eIvoYVVWqSs1HTvVBO2wVeUL8KYjFpGqJiymeQ=; b=kImMmaYg5HHJXqBmP4NHnP4fIkYP4vSPFFp+U/0YuzQCSTKFZIxBtj1VS6Y36X82xW KwSxq9lpskKvqQ0m271DDW32Py/lwrv0+47tKsNpim93iUILU6fHMDyCpz9BFz29FiBS 1MUNQfYcaYg2bgNQmBw0eovoONoapxbHg44aN3eW19VDZ+wTrOCjWDtTwc7+8HvqQWES br1E82ob9slQYFTgOWFkWbIVesjNNCwcDA+fENl7xV1yzDn7t9Ur60MwhNwQPAledO3T M+t1VAMA+fO7YQbpZBFhaNpWSGp942vtKAjDlnoij098UXxxfFnpNAvGUvqj4TlnOe8f 73Ow== X-Forwarded-Encrypted: i=1; AHgh+RrYazbbtMWSclkorvZxtI8OH+mxLIdGHnHUxP43JlGtGhzL6X3kHhDDmeBqvgCnq+vtbYYAsHb8ImOcZ44=@vger.kernel.org X-Gm-Message-State: AOJu0Yzm4df9E42DolASbzt5iJIE+WK6nkL0BJfSAxjC+CC1/tW0A1eI Vtss8iliGL+9aW/l0lPXRfJ/A3XtnBUuKHTv3SS3dmRUEqBW98R1ji+4 X-Gm-Gg: AfdE7ckQZg9aNr8Wcd9re1usk4WcF9O0WuxpxNHvsINbEUVJqgBuj3eu4C2BhtiEA7f dTwXmAoljTNCwj7lo5iTk8llh8w51vnMALYF3FChWhbpBIwzrPSG1nd5Jph1+2v/2kQUIeusQ4j AcPkBg38pWlSFFtdjP7/nS1eOfM4WQkco9LSV3GE6htFFXDjE6/qJzIFgBu3o1ELCCBCtRtmvFS H2BYzZtymGk6LtoEHr7afOw71KWw2wKrIlTukrrGFgR8zsoLsSkX+HoS4oUnB9CfB6lX4EUOW7h ugHd5Wi+weoDb6bY02QLPKZCkOCuZ2x3YXHc/+Eg1lejS+invaEbz+hfqh5Sq9KyP6fz8bNumkv wvqB1abO5/KPbb1z5ZdQohgthmqAlo2CfmfGUTrZWeaexvs956K8dFxS8nyGt0HIwvIzSfwmqLy EoH2wRwOPPsL0qnyma+lPXR5d5p9zcWn1kNgvjnB71b9quKeA= X-Received: by 2002:a17:90b:2703:b0:37f:9cdf:f0ab with SMTP id 98e67ed59e1d1-38e4b53898fmr3984171a91.26.1784316266648; Fri, 17 Jul 2026 12:24:26 -0700 (PDT) Received: from fx.tailc0aff1.ts.net ([206.206.192.132]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3142a1dde81sm18648783eec.21.2026.07.17.12.24.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2026 12:24:25 -0700 (PDT) From: Weiming Shi To: Carlos Maiolino , "Darrick J . Wong" Cc: linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org, xmei5@asu.edu, Weiming Shi Subject: [PATCH v2 0/2] xfs: add a log item verifier pass to recovery Date: Fri, 17 Jul 2026 12:24:06 -0700 Message-ID: <20260717192408.109168-1-bestswngs@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit v1 added the missing region and structure checks piecemeal in the pass2 inode decode. As Dave pointed out, that mixes validation into the decode and replay code and is hard to audit. v2 reworks it into a verifier pass run in the pass1 scan. Patch 1 handles the generic part: an item not logging all the regions its format declared is a log format property, not an inode concern, so xlog_recover_commit_trans() rejects any such item for all item types. This alone fixes the reported mount-time NULL deref. Patch 2 adds a ->verify() method to xlog_recover_item_ops, called in pass1 for every item, with xlog_recover_inode_verify() as the first user, and removes the log dinode checks it subsumes from the pass2 inode decode. The checks that need the on-disk inode buffer (its magic, the LSN/di_flushiter replay-ordering decisions, di_mode/di_format consistency, and the final xfs_dinode_verify()) cannot move to pass1 and stay in pass2. Scope: only the inode item is converted, and only its self-contained log dinode structure. The btree-root fork record count is not yet bounded (clamping xfs_bmbt_to_bmdr() and the rt converters is a separate fix), and the other item types can grow their own verify() the same way. Reproduced and regression-tested on a crafted dirty-log image under QEMU: the crafted item is rejected in pass1 with the mount refused (EFSCORRUPTED) instead of crashing (20/20 runs, no oops), and log recovery of a filesystem populated with a range of inode types (regular files, directories, symlinks, hardlinks, xattrs, device nodes, and a btree-format data fork) is unaffected. v2: - Moved the "all declared regions logged" check into xlog_recover_commit_trans() as a generic check for all item types. - Reworked the inode validation into a pass1 ->verify() hook on xlog_recover_item_ops, and removed the now-redundant log dinode checks (magic, forkoff) from xlog_recover_inode_commit_pass2(). Weiming Shi (2): xfs: reject log items with missing regions during recovery xfs: verify recovered inode log items in pass1 fs/xfs/libxfs/xfs_log_recover.h | 3 ++ fs/xfs/xfs_inode_item_recover.c | 87 +++++++++++++++++++++++++++------ fs/xfs/xfs_log_recover.c | 16 ++++++ 3 files changed, 90 insertions(+), 16 deletions(-) -- 2.43.0