From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout08.his.huawei.com (canpmsgout08.his.huawei.com [113.46.200.223]) (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 E154DA95E for ; Fri, 20 Mar 2026 02:22:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.223 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773973343; cv=none; b=MAT7V3yhiRBKIHMIaA08sXOTJYOJNWUx1SIH81iQ9mKolT0onEhO3ujlVPQLxC+vVyst5SK54jNsZ9ztdmTgMGpN/cYWH2PLwebaAFf3Ej1OqFaH5b8oPmjLJr3viDY56ede7XIeaf30B66FJ0tE9QxGRBRauF5IHmm0fv4lMSk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773973343; c=relaxed/simple; bh=kanHW8ZQWBLYfluCGsRoysHJNYyPuoxkasv/9GjRjio=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=owCDIpk9GWlouUM02h87SkXQkMQPxZOTHRwIagEVt7VcCS8n0arbkbf8XrA5n8vmcaFMCIrYkZYWuWvnEWMrEvCf/4GaOw0dy3PIeJ1xmEqDYW6saYqBg9ZLwquVf0rzJvowOoNyEPtpzZo7Q1kTPqpx1+SQLq+ZqS+eflOD57U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=h-partners.com; dkim=pass (1024-bit key) header.d=h-partners.com header.i=@h-partners.com header.b=XsKRJrCc; arc=none smtp.client-ip=113.46.200.223 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=h-partners.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=h-partners.com header.i=@h-partners.com header.b="XsKRJrCc" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=nRyw+N4Tgo4n6FZVIYHTgj31pSk3ff5YEMqzd3HagPk=; b=XsKRJrCckIFORoIMhPEZgkTIQ+X6E12xzzIi0PxTRJt3cVdJj/7ADOSiqncbpFmtAWOMZ4npW lGRD2VTuJGelGBMJvmlhV2ISagaSrP1H1BUObIAanSvc9+0boYwkv7HlOT7uI3nZa0Nd4n9FKRR St5TWE/EiNapH4NlFEX4DOI= Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout08.his.huawei.com (SkyGuard) with ESMTPS id 4fcR645m2hzmV66; Fri, 20 Mar 2026 10:17:16 +0800 (CST) Received: from dggemv706-chm.china.huawei.com (unknown [10.3.19.33]) by mail.maildlp.com (Postfix) with ESMTPS id 600F140561; Fri, 20 Mar 2026 10:22:18 +0800 (CST) Received: from kwepemn100013.china.huawei.com (7.202.194.116) by dggemv706-chm.china.huawei.com (10.3.19.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 20 Mar 2026 10:22:18 +0800 Received: from huawei.com (10.50.159.234) by kwepemn100013.china.huawei.com (7.202.194.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Fri, 20 Mar 2026 10:22:17 +0800 From: Long Li To: , CC: , , , , , , Subject: [PATCH v3 1/2] xfs: fix ri_total validation in xlog_recover_attri_commit_pass2 Date: Fri, 20 Mar 2026 10:11:29 +0800 Message-ID: <20260320021130.2936657-2-leo.lilong@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20260320021130.2936657-1-leo.lilong@huawei.com> References: <20260320021130.2936657-1-leo.lilong@huawei.com> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To kwepemn100013.china.huawei.com (7.202.194.116) The ri_total checks for SET/REPLACE operations are hardcoded to 3, but xfs_attri_item_size() only emits a value iovec when value_len > 0, so ri_total is 2 when value_len == 0. For PPTR_SET/PPTR_REMOVE/PPTR_REPLACE, value_len is validated by xfs_attri_validate() to be exactly sizeof(struct xfs_parent_rec) and is never zero, so their hardcoded checks remain correct. This problem may cause log recovery failures. The following script can be used to reproduce the problem: #!/bin/bash mkfs.xfs -f /dev/sda mount /dev/sda /mnt/test/ touch /mnt/test/file for i in {1..200}; do attr -s "user.attr_$i" -V "value_$i" /mnt/test/file > /dev/null done echo 1 > /sys/fs/xfs/debug/larp echo 1 > /sys/fs/xfs/sda/errortag/larp attr -s "user.zero" -V "" /mnt/test/file echo 0 > /sys/fs/xfs/sda/errortag/larp umount /mnt/test mount /dev/sda /mnt/test/ # mount failed Fix this by deriving the expected count dynamically as "2 + !!value_len" for SET/REPLACE operations. Cc: # v6.9 Fixes: ad206ae50eca ("xfs: check opcode and iovec count match in xlog_recover_attri_commit_pass2") Reviewed-by: "Darrick J. Wong" Signed-off-by: Long Li --- fs/xfs/xfs_attr_item.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_attr_item.c b/fs/xfs/xfs_attr_item.c index 354472bf45f1..83d09635b200 100644 --- a/fs/xfs/xfs_attr_item.c +++ b/fs/xfs/xfs_attr_item.c @@ -1047,8 +1047,8 @@ xlog_recover_attri_commit_pass2( break; case XFS_ATTRI_OP_FLAGS_SET: case XFS_ATTRI_OP_FLAGS_REPLACE: - /* Log item, attr name, attr value */ - if (item->ri_total != 3) { + /* Log item, attr name, optional attr value */ + if (item->ri_total != 2 + !!attri_formatp->alfi_value_len) { XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, attri_formatp, len); return -EFSCORRUPTED; -- 2.39.2