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 D4BCA294A10 for ; Sun, 3 May 2026 17:54:52 +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=1777830892; cv=none; b=qPDtzKSo4l1xxpTcW/+mc2uamQOEuSwZIgbNDUijlcBjQ6ydssI9PYYl6awqKmPqM/0Khcup2H3yfGJqDC/20sHGKxWdBHqgK6a6LOUax4K6GMLa22h9j/ymeDf4ql1xO7+Nc+8xwnpMC5qYktFmwKHNESq29XvlFou/E6l1sE8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777830892; c=relaxed/simple; bh=3k8JMYK28+0JD33iVGypb27iCbTz09pFMZylp5apRAQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jvlS28K5yq2E+dQL0dmIDtTdnLgWqkoleIjoRFb1ysybfWmiTmghUanpvbRRi7RKLW8hOvPZrSbchuM4jIcneGhfjc0DP+mKIoMLJEoVBHlCi8A7TAQ6mlVNEOU5CU1fRFD3F6yKsfY916d8EXldPi9tnnpmEVpFDRxTks/T+vs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R0r7NfWS; 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="R0r7NfWS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B362EC2BCB9; Sun, 3 May 2026 17:54:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777830892; bh=3k8JMYK28+0JD33iVGypb27iCbTz09pFMZylp5apRAQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R0r7NfWSu9uHBJHrqiGKOIpX6YUZLKJDcnux/jrzNdRjjvDWI1FQV78CJkkbqApBT zwW6hWyG5mVqYeXKzTCEJs+kIXEKsA17TYEn+mUxkgAsSVLAWTwCeGLoxCnhvGObVu 6XCeljE/aSIFsSbjE4lYkF0ilDRhMc953I/459JxZxcHMXa8SuFwDf7bXQQ1lzTOIN VkmolR1cSwp6ANB5YO5G0NZ4HdDvPyPzao/1M3iz8sWEbNKehguJHh8IIfGW/JIuPW uHACu53fCPoLhwsTC/0Ci+inusR1+Y3KmPk0bu+pzHH/mGGeZ0bW81/QQJ4lfFb8JR LbpeZoICOu1sQ== Date: Sun, 3 May 2026 18:54:48 +0100 From: Conor Dooley To: Mohamed Ayman Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Andrew Jones , Conor Dooley , Anup Patel , "open list:RISC-V ARCHITECTURE" , open list Subject: Re: [PATCH] riscv: cpuinfo: Fix NULL dereference and inconsistent error code Message-ID: <20260503-duller-canyon-a2be827f9488@spud> References: <20260502160301.453029-1-mohamedaymanworkspace@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HdbG1zHGMyyrTmib" Content-Disposition: inline In-Reply-To: <20260502160301.453029-1-mohamedaymanworkspace@gmail.com> --HdbG1zHGMyyrTmib Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, On Sat, May 02, 2026 at 07:02:57PM +0300, Mohamed Ayman wrote: > Fix a potential NULL pointer dereference in c_show() by ensuring > the device tree node returned by of_get_cpu_node() is checked before use. >=20 > Also replace a non-standard return value (-1) in > riscv_of_parent_hartid() with -ENODEV to follow Linux kernel > conventions for "not found" error returns. >=20 > Both issues improve robustness and consistency with existing RISC-V CPU i= nfo handling code. These two things should be two different patches, since they're completely unrelated. Additionally, the patch is missing a signoff. > --- > arch/riscv/kernel/cpu.c | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) >=20 > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > index 3dbc8cc557dd..e0bc7526861f 100644 > --- a/arch/riscv/kernel/cpu.c > +++ b/arch/riscv/kernel/cpu.c > @@ -135,7 +135,7 @@ int riscv_of_parent_hartid(struct device_node *node, = unsigned long *hartid) > } > } > =20 > - return -1; > + return -ENODEV; > } > =20 > unsigned long __init riscv_get_marchid(void) > @@ -348,12 +348,13 @@ static int c_show(struct seq_file *m, void *v) > =20 > if (acpi_disabled) { > node =3D of_get_cpu_node(cpu_id, NULL); > + if (node) { Is it actually possible for this to fail? Cheers, Conor. > + if (!of_property_read_string(node, "compatible", &compat) && > + strcmp(compat, "riscv")) > + seq_printf(m, "uarch\t\t: %s\n", compat); > =20 > - if (!of_property_read_string(node, "compatible", &compat) && > - strcmp(compat, "riscv")) > - seq_printf(m, "uarch\t\t: %s\n", compat); > - > - of_node_put(node); > + of_node_put(node); > + } > } > =20 > seq_printf(m, "mvendorid\t: 0x%lx\n", ci->mvendorid); > --=20 > 2.34.1 >=20 --HdbG1zHGMyyrTmib Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCafeL4wAKCRB4tDGHoIJi 0q5cAQDTI7ENUP1UJlKNOMSogtBE5TBGSI6ZdmTCUe7nZCdiNgEAkmRgQm4DkhT0 EvJPYDae4KB2l3m2VmeLnaaclZ96Hw8= =Gl6a -----END PGP SIGNATURE----- --HdbG1zHGMyyrTmib--