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 9CAC53B5835 for ; Sun, 3 May 2026 12:26:10 +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=1777811170; cv=none; b=RkCzUKC77t8kdYhhMqCpSRaPJyre/ZUyaN5o0BhXR+rxBkOuCiDapzhbQeIiw3Q+12MYso7d5dfZZfXAxtopjx6LLjRhm1OX4DMMBXu8GrqBrPLUkOeivVejAs1u0Hk4BJlDP7RagoubCdT1Rzyz04J6l11Plt2gxvCvOIUiamo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777811170; c=relaxed/simple; bh=wIKZJm+44gbevXVFKTtgRVSh6IKiCNKWi89emtsttCM=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=BHZIlYecipDqclTrvh34Dlb17bdJBru0yzlEySvTVLvNCGE4LJVJyWlfPQefVCQYBuTR5aWQKinWXZPuxjJ2qT1cv3A9ToJ9ZvIY4u06jKicGKs/wFmcW5ndqBP9ALBEdcvZ2JPBcOc21tIopNJ/jkQydZLN1XJ4rEIK3aHA6J0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NX8VB4/q; 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="NX8VB4/q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5908BC2BCB8; Sun, 3 May 2026 12:26:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777811170; bh=wIKZJm+44gbevXVFKTtgRVSh6IKiCNKWi89emtsttCM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=NX8VB4/qC3hcyaprRzJbBB8X9QJWmublJVTOGcxgzp33JEbTGhzkql/0XvsAFD9OY nnSs+epqaS5u1YfLZ+2pR5ZIA5miSZ8VpP3os67SIqx+7AiU7JBn5pYAyvMTUNC8gG NcQFUubOy+LSbE8DlouYET+lY1r8MKpDh20WGH6QniJ4zpWsW9sKUKorpqMldFcIX5 05g/KnBk/8/a4Wddz4xeBPKiPc5p5XNDiXT54212XGwhEorT24ZNJcVRMEiFgt5Xqm zzq4Zel67W7Fhk90Xhq13FbaiSqFDlcWRFR7ZeMthTPp5YXbmbPesESjdcNV1FfSk4 3zwLB4igEB5xw== Message-ID: <928b68db-4cf4-454c-aa88-3104e689a642@kernel.org> Date: Sun, 3 May 2026 22:26:06 +1000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] riscv: cpuinfo: Fix NULL dereference and inconsistent error code To: Mohamed Ayman , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Andrew Jones , Anup Patel , Conor Dooley , "open list:RISC-V ARCHITECTURE" , open list References: <20260502161802.515547-1-mohamedaymanworkspace@gmail.com> Content-Language: en-US From: Michael Ellerman In-Reply-To: <20260502161802.515547-1-mohamedaymanworkspace@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/5/2026 02:17, 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. Where is the NULL pointer deref? of_property_read_string() can cope with a NULL np, it just returns an error. of_node_put() also handles a NULL np. > 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. That should be a separate patch. It does look like a good change. At least some of the callers of riscv_of_parent_hartid() pass the return value up to their callers, so -1 could be misinterpreted somewhere as EPERM. cheers