From mboxrd@z Thu Jan 1 00:00:00 1970 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 3CC323CFF4F; Tue, 10 Mar 2026 22:09:22 +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=1773180562; cv=none; b=mwsvLCVY5tmgIWxaBNf//QDM/3Z/VaFIiSEvCQ/9K6ogT2K6wS7VcBOW8FsLLO9o/2PCyX+FV0PHZlKNHnAj0vzVvioJz9QPxtlU88hjHlaIW6jy1ZWht7N5tyqGB6Iz7Wko8NLju43abYig63AuA8uDb9r5ziS/wV/QEFmuVDw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773180562; c=relaxed/simple; bh=W80lkFXkPyxzZPzLe6vTEN0SYi+yr5xZNTGscVmS0ko=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; b=PyfdK/Me9Qp1k01OJg5UPVhyxHoGxUQudxatPJlCBUfUow3aRdj5nnFfV4XqzqSvfaHcFr44aHuJDWoTdm9djNq20etf2gQz6TdOjKbIwlKOARqa91xkj9ou0v6GiCpTVy0ScxaIFiibB7RcmNZS02Z8ExyIsSgk976/TJXUwpA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=L00YXZHP; 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="L00YXZHP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8F86C19423; Tue, 10 Mar 2026 22:09:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773180561; bh=W80lkFXkPyxzZPzLe6vTEN0SYi+yr5xZNTGscVmS0ko=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=L00YXZHPMVeEfxwGWu/AsurKr2xWM9c1K5M3MtDaIn5nfcen4jicy1Q3i8rLIm5yf WfvG20wIi1QYyAKqVzaODlOcIZAjN1oBjLxF9C/amXt1SGV5lxTwZfkpQvXdvW9gAg U5fgwzShrDb/Z15j0gztxNaymw4OC6qlveBz2cGZnyhROtlLohCqWPm8uXMsbT9F27 CbZuzIyVxmIfJ98YaFyJMcT3cZFIirNKa3bxELZvJJRpc3CFl/8aYvCTYeWpkA6BN0 oBTJJOco6wPHguHYPtf3q7EkbWZ3hux+WxUaIr/01eGtMcm8Pr8xqHRXg8MC7nxSZp RRiGt6sycGkpg== Date: Tue, 10 Mar 2026 17:09:20 -0500 From: Bjorn Helgaas To: Jeremy Linton Cc: Chengwen Feng , Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Ajit Khaparde , Wei Huang , Andy Gospodarek , Somnath Kotur , wangzhou1@hisilicon.com, wanghuiqiang@huawei.com, liuyonglong@huawei.com, linux-pci@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-perf-users@vger.kernel.org, stable@vger.kernel.org, Wathsala Vithanage Subject: Re: [PATCH v5 2/2] PCI/TPH: Fix get cpu steer-tag fail on ARM64 platform Message-ID: <20260310220920.GA826995@bhelgaas> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <657142d1-1632-4a3e-8800-ee1dd5763d78@arm.com> On Tue, Mar 10, 2026 at 10:58:49AM -0500, Jeremy Linton wrote: > On 3/9/26 10:20 PM, Chengwen Feng wrote: > > pcie_tph_get_cpu_st() is broken on ARM64: > > 1. pcie_tph_get_cpu_st() passes cpu_uid to the PCI ACPI DSM method. > > cpu_uid should be the ACPI Processor UID [1]. > > 2. In BNXT, pcie_tph_get_cpu_st() is passed a cpu_uid obtained via > > cpumask_first(irq->cpu_mask) - the logical CPU ID of a CPU core, > > generated and managed by kernel (e.g., [0,255] for a system with 256 > > logical CPU cores). > > 3. On ARM64 platforms, ACPI assigns Processor UID to cores listed in the > > MADT table, and this UID may not match the kernel's logical CPU ID. > > When this occurs, the mismatch results in the wrong CPU steer-tag. > > 4. On AMD x86 the logical CPU ID is identical to the ACPI Processor UID > > so the mismatch is not seen. > > int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type, > > - unsigned int cpu_uid, u16 *tag) > > + unsigned int cpu, u16 *tag) > > { > > #ifdef CONFIG_ACPI > > + u32 cpu_uid = acpi_get_cpu_acpi_id(cpu); >From AI review (gemini/gemini-3.1-pro-preview): Does this code need to validate that `cpu` is within bounds before using it? Before this change, the `cpu_uid` parameter was passed opaquely to the ACPI firmware via `tph_invoke_dsm()`, which would gracefully handle invalid values. Now, `cpu` is treated as a logical CPU index and passed to `acpi_get_cpu_acpi_id(cpu)`. On architectures like arm64 and riscv, `acpi_get_cpu_acpi_id()` uses `cpu` directly as an array index (`&cpu_madt_gicc[cpu]` and `&cpu_madt_rintc[cpu]`). On x86, it uses `per_cpu(x86_cpu_to_acpiid, cpu)`. If a caller passes an out-of-bounds `cpu` index (for example, if an IRQ affinity mask is empty and `cpumask_first()` returns `nr_cpu_ids`, or if userspace passes an arbitrary ID via `mlx5_st_alloc_index()`), this will result in an out-of-bounds memory read. Consider adding a bounds check: if (cpu >= nr_cpu_ids) return -EINVAL; I agree that this is an issue, and I think implementations of acpi_get_cpu_acpi_id() should validate their inputs. I don't know if there's a value that can never be a valid ACPI CPU UID and could be used as an error value from acpi_get_cpu_acpi_id(). I do see a few mentions of a ~0 value meaning "all processors" (ACPI r6.6, sec 5.2.12.13).