From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.126.com (m16.mail.126.com [117.135.210.6]) (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 35F2F2C15AC for ; Wed, 27 May 2026 01:57:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.6 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779847056; cv=none; b=XgaStctprMpVO+Icv2AEJyOc5f4sjxnC1s4igGcgKNl58oieuG80Fz8SvzLA5mPezdUaroZX74X1PjTG1xZADRuKULTNWLDlvWPCCVu8b76djSFKb8WHivjvTEO87Zl4wLCqK4pbjZbzl47AS/VLZsYr7vm9yh7IOzDvlrerD5E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779847056; c=relaxed/simple; bh=JkD+TzylLtXwKXQp29w5Pfw0U8/qqBYOiPhbokwaLSM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=ctYDdJzMRmtiyscdaS9/NYS1OnfrvlSqDMhzVjcRwpAqE1feF+KcVlc0GNrjJxcpd29DD4DjhguK3r7l72v4me3lISWIpfybc9rF3EqlOrFmotAiHoL/Zu21HC7G7z2QBy7p2yZd8kIFKSTbRVrqMy1qyJKPfhPYRMMQvBvVBm0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com; spf=pass smtp.mailfrom=126.com; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b=f0HJJt3d; arc=none smtp.client-ip=117.135.210.6 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=126.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b="f0HJJt3d" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; bh=DRewvKHciVqU5Ur9lYxZwRFH8ppi1XJT7zMqz7YMBqM=; b=f0HJJt3dRyCyor0k//LxRNSYqgvbW6y809cBfnZneVWcy1CfqQ5id2M27vo7Ly 60Rt8YIlw3wnh0LS8YWxvVWbTR1e3pJMBHJAk9niZoPFJWrKInJaio8j24jROcNV dlejU61ZIxsHex6UsnAJ8JguMfXy/hkf1M/ALRt+6pGe0= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-3 (Coremail) with SMTP id _____wCXTMNJTxZq_66AAQ--.59386S2; Wed, 27 May 2026 09:56:25 +0800 (CST) Message-ID: <6A164F51.7010203@126.com> Date: Wed, 27 May 2026 09:56:33 +0800 From: Hongling Zeng User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: Danilo Krummrich , Hongling Zeng CC: lyude@redhat.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, airlied@redhat.com, ttabi@nvidia.com, bskeggs@nvidia.com, dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] nouveau/gsp: fix NULL pointer dereference in r535 nvenc/ofs alloc References: <20260526014721.13299-1-zenghongling@kylinos.cn> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wCXTMNJTxZq_66AAQ--.59386S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7Cr4Utw47KF1xWr1rCFy5XFb_yoW8Aw15pa y7ur1Yyr1qyrWxKasrW3WrZw1ru34fWFyrur1rWa1DZF90yFyxZrW2qr47Za4jka1rGa10 qrWfAa40vr1UAaUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jjksgUUUUU= X-CM-SenderInfo: x2kr0wpolqwiqxrzqiyswou0bp/xtbBoAoG1moWT0qxrgAA3c Hi Danilo, Thank you for the feedback. You're right. After tracing through the call chain: nvkm_gsp_rm_alloc_get() └─> r535_gsp_rpc_rm_alloc_get() └─> r535_gsp_rpc_get() └─> r535_gsp_cmdq_get() └─> kvzalloc() r535_gsp_cmdq_get() returns ERR_PTR(-ENOMEM) on allocation failure, not NULL. So NULL is never actually returned. I found a similar issue in sunrpc where IS_ERR_OR_NULL() is actively harmful - PTR_ERR(NULL) would return 0 (EOF), masking real errors. This confirms the pattern you identified. Should I submit a patch to clean up the IS_ERR_OR_NULL() checks in: - nvkm_gsp_rm_alloc_get() / nvkm_gsp_rm_alloc() - nvkm_gsp_rpc_rd() - All the callers Or would you prefer to handle this differently? Regards, Hongling 在 2026年05月26日 21:16, Danilo Krummrich 写道: > On Tue May 26, 2026 at 3:47 AM CEST, Hongling Zeng wrote: >> nvkm_gsp_rm_alloc_get() can return NULL as well as error pointers. >> The current code only checks for error pointers with IS_ERR(), which >> would lead to a NULL pointer dereference if NULL is returned. >> >> Fix by using IS_ERR_OR_NULL() instead of IS_ERR(), matching the >> pattern used in nvkm_gsp_rm_alloc(). > There was a similar patch [1] a while ago for another callsite. I replied: > > Are we sure that this can ever return NULL in the first place? I know > that nvkm_gsp_rm_alloc_get() internally checks for IS_ERR_OR_NULL(), but > I couldn't find anything within the callchain that would actually return > NULL. > > That said, I think IS_ERR_OR_NULL() checks are misleading. > > Is there a real case where NULL can be returned? If not, let's remove the > IS_ERR_OR_NULL() throughout the whole chain instead. > > [1] https://lore.kernel.org/lkml/20260418071412.86022-1-sunliming@linux.dev/