| Message ID | a313aae6ec654180b050f2cab12e8400@huawei.com |
|---|---|
| State | New |
| Headers | show
Return-Path: <linux-pci+bounces-65107-incoming=patchwork.ozlabs.org@vger.kernel.org> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=huawei.com header.i=@huawei.com header.a=rsa-sha256 header.s=dkim header.b=Blc8LzTz; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org; envelope-from=linux-pci+bounces-65107-incoming=patchwork.ozlabs.org@vger.kernel.org; receiver=patchwork.ozlabs.org) Received: from tor.lore.kernel.org (tor.lore.kernel.org [IPv6:2600:3c04:e001:36c::12fc:5321]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4hZZhV2SSNz1xwZ for <incoming@patchwork.ozlabs.org>; Wed, 02 Sep 2026 17:52:42 +1000 (AEST) Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 112922D882 for <incoming@patchwork.ozlabs.org>; Wed, 2 Sep 2026 07:45:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 69D6E374E5A; Wed, 2 Sep 2026 07:45:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Blc8LzTz" X-Original-To: linux-pci@vger.kernel.org Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (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 185A4370ACC for <linux-pci@vger.kernel.org>; Wed, 2 Sep 2026 07:45:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788335121; cv=none; b=WHM+WzKU37iXgpozRLbZ+xtj4V4c3AUt/1hQ1qY2j4nmYCwxAmgqXlnRo+67umI/efbdJc9W7kRFhbnmLYQFobYMRm8DiHWgURMYJ/kQS37xR8E2fEYyGlcs3QFqs+2b++3XD27NcmdUBMIz6BTu2KMNzi9vrGmD77xNM37urxU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788335121; c=relaxed/simple; bh=3h5MAMMmUk0EY1Z9CD8jEa83DLvliV5XaTunLPPiVfQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Mdhj6TlSN2GZ7T1W5Lc+e+YHkfzdkEtFsEdyuQizVgb0iXhDlh0jekHu7J1tLMnH1CIx4BVA//RWwmVzzILFnc3RiviTbPkcGX3C3wGR2qpOOZd8UF75J8/VfOst1J6jRsrApeMUfWxQ1bVu6sEoAJLEE34TplzKZCliFl3q6Ps= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Blc8LzTz; arc=none smtp.client-ip=113.46.200.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=3h5MAMMmUk0EY1Z9CD8jEa83DLvliV5XaTunLPPiVfQ=; b=Blc8LzTzW/qn9hsp1vAhqSIfMmgZhTfm+vH/oK2ZUfmcOCL7zehbEdqbDPH5qH+u9foU6pzew lLm78avDPrBQzzvm0ItUJv1bL5dIJK9gtUe/Wet6Z6ZAns+2PrVX9eHkMn3It2fzklwN6oTgFNG rVtnjS4nuDfUkvH3+kaXfuM= Received: from mail.maildlp.com (unknown [172.19.162.92]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4hZZHM0sc3z1K96b; Wed, 2 Sep 2026 15:34:23 +0800 (CST) Received: from kwepemk300009.china.huawei.com (unknown [7.202.195.222]) by mail.maildlp.com (Postfix) with ESMTPS id 3B7C44058A; Wed, 2 Sep 2026 15:45:13 +0800 (CST) Received: from kwepemk200005.china.huawei.com (7.202.194.71) by kwepemk300009.china.huawei.com (7.202.195.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Wed, 2 Sep 2026 15:45:12 +0800 Received: from kwepemk200005.china.huawei.com ([7.202.194.71]) by kwepemk200005.china.huawei.com ([7.202.194.71]) with mapi id 15.02.2562.045; Wed, 2 Sep 2026 15:45:12 +0800 From: Kangfenglong <kangfenglong@huawei.com> To: "kbusch@kernel.org" <kbusch@kernel.org> CC: "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>, "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, liuyonglong <liuyonglong@huawei.com>, "Wangyu (Eric)" <seven.wangyu@huawei.com> Subject: [PATCH v3] nvme-pci: fix CMB mapping when CMBSZ Size field is zero Thread-Topic: [PATCH v3] nvme-pci: fix CMB mapping when CMBSZ Size field is zero Thread-Index: AQHdAfCi0dQZ95AJYEyV6RZtGnUzlLa60/nA Date: Wed, 2 Sep 2026 07:45:12 +0000 Message-ID: <a313aae6ec654180b050f2cab12e8400@huawei.com> References: <20260622024129.40800-1-kangfenglong@huawei.com> In-Reply-To: <20260622024129.40800-1-kangfenglong@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: <linux-pci.vger.kernel.org> List-Subscribe: <mailto:linux-pci+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-pci+unsubscribe@vger.kernel.org> MIME-Version: 1.0 |
| Series |
[v3] nvme-pci: fix CMB mapping when CMBSZ Size field is zero
|
expand
|
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 8438c904ec49..ee2d782f4957 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -2448,6 +2448,9 @@ static u64 nvme_cmb_size_unit(struct nvme_dev *dev) { u8 szu = (dev->cmbsz >> NVME_CMBSZ_SZU_SHIFT) & NVME_CMBSZ_SZU_MASK; + if (szu > 6) + return 0; + return 1ULL << (12 + 4 * szu); } @@ -2458,7 +2461,7 @@ static u32 nvme_cmb_size(struct nvme_dev *dev)
Friendly ping. It has been over two months since this patch was submitted. I would highly appreciate it if someone could take a quick look or provide some feedback. Please let me know if any modifications are needed. Thanks! -----邮件原件----- 发件人: Kangfenglong <kangfenglong@huawei.com> 发送时间: 2026年6月22日 10:41 收件人: kbusch@kernel.org 抄送: linux-nvme@lists.infradead.org; linux-pci@vger.kernel.org; liuyonglong <liuyonglong@huawei.com>; Wangyu (Eric) <seven.wangyu@huawei.com>; Kangfenglong <kangfenglong@huawei.com> 主题: [PATCH v3] nvme-pci: fix CMB mapping when CMBSZ Size field is zero The controller memory buffer size is defined by the SZ field in the CMBSZ register (bits 31:12). According to the NVMe specification, a value of zero in the SZ field indicates that no CMB is present. Commit f65efd6dfe4e ("nvme-pci: clean up CMB initialization") replaced the check for a zero SZ field with a check for a zero CMBSZ register value, under the assumption that a zero register implies no CMB. However, a CMBSZ register can be non-zero while the SZ field is zero, for example when Size Units (SZU) is set to a non-zero value but the actual size is zero (e.g. CMBSZ = 0x100: SZU = 1, SZ = 0). When this happens, nvme_map_cmb() proceeds to compute a size of zero, passes the alignment checks (zero is always aligned), and calls pci_p2pdma_add_resource() with size=0. The P2PDMA subsystem then defaults size to the entire remaining BAR, which may not be properly aligned for memory hotplug, triggering: WARNING: CPU: 0 PID: 10 at mm/memory_hotplug.c:396 __add_pages Misaligned __add_pages start: 0x494a0000 end: 0x494a000f Fix this by: 1. Restoring the check for a zero SZ field, which explicitly verifies that the controller actually has a CMB before proceeding. 2. Adding a boundary check in nvme_cmb_size_unit() to reject SZU values greater than 6. The SZU field is 4 bits, but values 7-15 are reserved by the NVMe specification and produce a shift count >= 40 in the left-shift operation (1ULL << (12 + 4 * szu) when szu >= 7), which exceeds the maximum 64 GB unit size defined by the spec. 3. Checking the return value of nvme_cmb_size_unit() for zero before proceeding, and using check_mul_overflow() for the size calculation to detect integer overflow that could wrap to a non-zero value and bypass the SZ check. Fixes: f65efd6dfe4e ("nvme-pci: clean up CMB initialization") Signed-off-by: kangfenglong <kangfenglong@huawei.com> --- drivers/nvme/host/pci.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) static void nvme_map_cmb(struct nvme_dev *dev) { - u64 size, offset; + u64 size, unit_size, offset; resource_size_t bar_size; struct pci_dev *pdev = to_pci_dev(dev->dev); int bar; @@ -2472,9 +2475,15 @@ static void nvme_map_cmb(struct nvme_dev *dev) dev->cmbsz = readl(dev->bar + NVME_REG_CMBSZ); if (!dev->cmbsz) return; + if (!nvme_cmb_size(dev)) + return; dev->cmbloc = readl(dev->bar + NVME_REG_CMBLOC); - size = nvme_cmb_size_unit(dev) * nvme_cmb_size(dev); + unit_size = nvme_cmb_size_unit(dev); + if (!unit_size) + return; + if (check_mul_overflow(unit_size, nvme_cmb_size(dev), &size)) + return; offset = nvme_cmb_size_unit(dev) * NVME_CMB_OFST(dev->cmbloc); bar = NVME_CMB_BIR(dev->cmbloc); bar_size = pci_resource_len(pdev, bar); -- 2.12.0.windows.1