From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.126.com (m16.mail.126.com [220.197.31.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 C9FAE39D6E8 for ; Mon, 1 Jun 2026 09:59:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.6 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307968; cv=none; b=utvPeaQDYquNACskB68I2nZFysNolsa4SyIEtnPLzjSU+yvfJ1wm6EoX6o1sNhQgc/zGyBp5iMwXx1nGWjjKPOUg9o0b/ojEsY41C7PtLavQqUXOImjQME0vMrxb9v3kHgIGoDzNkAcsYXUoyCUd8g38jiY7zaLDCSAk/vWyHZ8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307968; c=relaxed/simple; bh=8KsIKZGCxnxcvKdyxFF6dG8ZVnNac+y7GpKEPkE6Ne0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=nUYIKsA8aUfY/EmiWMtNkkbT5GkxFU0v4hkxgOPKMAqEWtJqBw79zLXz5Spm3EFExsV6+TWi8F2f3vcxCorerdTacX56EajXIDyVpyqQOEg7xbeaPzrEPZ31EkFrOpoz50AGGSmYmPyhAkEdbVuICTunMlFHAjEOWP7fZ6Oxjcw= 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=SQuf0+UC; arc=none smtp.client-ip=220.197.31.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="SQuf0+UC" 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=GpqjxkI6HTsNPXTHknXZXvJU5tQpuWx9d1v/8ydLUPY=; b=SQuf0+UC/7nFo/+HlOKZzqH/gWx8d2ASi+g6yJSc2qaaqNMhs2D3lo8Q0xEGyS KJ7estbu2mNLl6XsvrrXb6gI5cvKxsBxXbyDyXeWoXbv+2a1QjIZZghL8FDWf2xM vtD1tFTW73rY9CLYQseJxjUPcMKyU+iVUp0re0P8YQQcE= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-0 (Coremail) with SMTP id _____wDn106zVx1q+XTYAg--.13632S2; Mon, 01 Jun 2026 17:58:12 +0800 (CST) Message-ID: <6A1D57B9.6000504@126.com> Date: Mon, 01 Jun 2026 17:58:17 +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 CC: =?UTF-8?B?5pu+57qi546y?= , Timur Tabi , "lyude@redhat.com" , "rongqianfeng@vivo.com" , "airlied@gmail.com" , "kees@kernel.org" , "simona@ffwll.ch" , "dri-devel@lists.freedesktop.org" , Zhi Wang , "nouveau@lists.freedesktop.org" , "airlied@redhat.com" , "maarten.lankhorst@linux.intel.com" , "tzimmermann@suse.de" , "linux-kernel@vger.kernel.org" , "mripard@kernel.org" Subject: Re: =?UTF-8?B?5Zue5aSNOiBSZTogW1BBVENIIDAvNV0gUmV2ZXJ0IGNsZWFudXA=?= =?UTF-8?B?cyBmb3IgSVNfRVJSX09SX05VTEwoKSB1c2FnZQ==?= References: DIULSRTZPQ0H.39RB5RF1NTFYA@kernel.org <823rnittrvj-82932fejdy8@nsmail8.2--kylin--1> In-Reply-To: <823rnittrvj-82932fejdy8@nsmail8.2--kylin--1> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wDn106zVx1q+XTYAg--.13632S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxZw4xJw13WFWrury8Jw4rGrg_yoWrWFW7pw 13K3yqka1qkF93tFy2va1rA3WfAr4fKF48uas3ta9xZw15XF9xJF40qF1Y9a4rCr4rua1j q39FgFWrZw1DA3JanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07U5PEfUUUUU= X-CM-SenderInfo: x2kr0wpolqwiqxrzqiyswou0bp/xtbBrxTktWodV7Q1eQAA3y Hi Danilo, I apologize for the confusion with my previous patch submission. Please disregard the patches I submitted earlier. I have now regenerated a v2 patch series following your requirements to properly document return value contracts and clean up IS_ERR_OR_NULL usage. Return value analysis: - r535_gsp_msgq_peek(): Never returns NULL - r5sp_msgq_recv_one_elem(): Never returns NULL - r535_gsp_msgq_recv(): CAN return NULL (when RPC length invalid) - r535_gsp_msg_recv(): CAN return NULL (queue drained/no matching message) - r535_gsp_rpc_get(): Never returns NULL - r535_gsp_rpc_handle_reply(): CAN return NULL (NOWAIT/NOSEQ policies) - r535_gsp_rpc_send(): CAN return NULL (via handle_reply) - r535_gsp_rpc_push(): CAN return NULL (via handle_reply) I've been careful to only clean up IS_ERR_OR_NULL() for functions that actually never return NULL, while preserving the checks for functions that can return NULL (like r5_gsp_msg_recv() and r535_gsp_msg_recv()). Could you please review if this approach is correct? Thanks, Hongling 在 2026年05月29日 17:40, 曾红玲 写道: > > Hi Danilo Krummrich: > > like this? > > 1. r535_gsp_msgq_peek(): ERR_PTR on error, valid pointer on success, > never NULL > 2. r535_gsp_msgq_recv_one_elem(): ERR_PTR on error, valid pointer on > success, never NULL > 3. r535_gsp_msgq_recv(): ERR_PTR on error, valid pointer on success, > never NULL > 4. r535_gsp_msg_recv(): ERR_PTR on error, valid pointer on success, > NULL for queue drained or no payload > 5. r535_gsp_rpc_get(): ERR_PTR on error, valid pointer on success, > never NULL > 6. r535_gsp_rpc_handle_reply(): Depends on policy, can return NULL > > TKS! > > > > > *主 题：*Re: [PATCH 0/5] Revert cleanups for IS_ERR_OR_NULL() usage > *日 期：*2026年05月29日04:48 > *发件人：*Danilo Krummrich > *收件人：*Timur Tabi,Danilo Krummrich > *抄送 > 人：*lyude@redhat.com,rongqianfeng@vivo.com,airlied@gmail.com,kees@kernel.org,simona@ffwll.ch,dri- > devel@lists.freedesktop.org,Zhi > Wang,nouveau@lists.freedesktop.org,airlied@redhat.com,maarten.lankhorst@linux.intel.com,tzimmermann@suse.de,linux-kernel@vger.kernel.org,mripard@kernel.org > > On Thu May 28, 2026 at 10:23 PM CEST, Timur Tabi wrote: > On Thu, > 2026-05-28 at 21:44 +0200, Danilo Krummrich wrote: >> >> @Timur: I do > think cleaning this up is the right call in general though, and I >> > also don't think that the whole driver necessarily needs to be > consistent on >> whether IS_ERR_OR_NULL() or IS_ERR() is used -- it > depends on the context >> (although I usually prefer not to mix up > NULL and ERR semantics in the first >> place). >> >> It should however > be consistent in terms of what functions can actually return. >> >> > ret = foo(); >> if (IS_ERR_OR_NULL(ret)) >> return ret; >> >> If foo() > can never return NULL, the above is misleading, as it puts an >> > obligation on the caller to somehow handle the NULL case and come up > with an >> actual error code for it. > > Sure, I get that. My point is > that it's often not clear whether foo() actually can never return > > NULL. > > It's been a while since I've dug through the RPC call chains > in Nouveau, so my memory is a little > hazy here. I do remember > noticing that Nouveau frequently has situations where foo() call > bar1() > and bar2(), where bar1() can return NULL but bar2() can't. So > the question is not whether foo() can > return NULL, it's whether > bar1() should not return NULL, or whether bar2() should. If there are > multiple, it has to be the superset of course. >> So, I think it is > the right call to align that to what functions can actually >> return, > but while doing this, the contract should be properly documented, such > >> that subsequent changes can be properly validated. > > "Properly > documented" and "Nouveau" are not two things that go together. > Unfortunately -- but the changes submitted by Hongling can add the > documentation for the places that are touched. @Hongling, can you > consider this in a v2 please? Thanks, Danilo > > > --- > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7C7DBCD6E60 for ; Mon, 1 Jun 2026 10:05:47 +0000 (UTC) Received: from kara.freedesktop.org (unknown [131.252.210.166]) by gabe.freedesktop.org (Postfix) with ESMTPS id 496901130AB; Mon, 1 Jun 2026 10:05:47 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (1024-bit key; unprotected) header.d=126.com header.i=@126.com header.b="SQuf0+UC"; dkim-atps=neutral Received: from kara.freedesktop.org (localhost [127.0.0.1]) by kara.freedesktop.org (Postfix) with ESMTP id D55974672F; Mon, 1 Jun 2026 09:52:09 +0000 (UTC) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=lists.freedesktop.org; s=20240201; t=1780307529; b=w5e8YMu6vJ/uQiBOShvtzBQUP1DyCSbkgu+Me15eAVUZKna2eHMFdmQNgbhOg7Z7oUiKb zAFppqJR0mWp97BL5ODcWtS6PJ00bMbgrdN9tFbtm3kAZ1Pc2QqottMcKD7z1r0kjEdOgtC MMEKe3WQB4TebWSTo1ebaJmLaEarjN+hgeHQx9olDQRRTRQF2qSued/E5Y2FG/GhUbZ3xL7 v4anpTuVBcuzYdyHqNTd42qv/K+/iHrCscfk2H8I6fUwaQmwpP21ga/gypObeoHADe22/PM H0AId9tYWsRf4cYqdLakopoZrXwrx/xB/ND2KyqD9nsa0Pf4HoU+8SfyAVKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.freedesktop.org; s=20240201; t=1780307529; h=from : sender : reply-to : subject : date : message-id : to : cc : mime-version : content-type : content-transfer-encoding : content-id : content-description : resent-date : resent-from : resent-sender : resent-to : resent-cc : resent-message-id : in-reply-to : references : list-id : list-help : list-unsubscribe : list-subscribe : list-post : list-owner : list-archive; bh=GpqjxkI6HTsNPXTHknXZXvJU5tQpuWx9d1v/8ydLUPY=; b=VACZvCntgsg2q5jOS2LZHP1nEppE5GGDehpTIhwNIw8C4JhaG/d7s3w9HIXYWuIRFK3cv Fps0bl7ZQmgN8UO2adocC/LTWgGNM5U66XUaKMxuG6924rQVbff7kLdqc3T30hKZv3B5t8p /J/vTncc32dijfJXwdc+iY81SnafMq5Rtteh44P9wMV1+AMY7dxXHsoE83u249LazdGzMmW mFa0Zk3L3WyGhSoaKzdXUOZDMI4WVT4BYd+PKkAL6mSoFJHA7Pf9T3vy/Un36NawCV+ndps 5UxdREReLY9JERpnTdoFjxtP3Kx7OiKXZ/SQM5FCOyelkXpcHObVPc8ikrIQ== ARC-Authentication-Results: i=1; mail.freedesktop.org; dkim=pass header.d=126.com; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=126.com policy.dmarc=none Authentication-Results: mail.freedesktop.org; dkim=pass header.d=126.com; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=126.com policy.dmarc=none Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by kara.freedesktop.org (Postfix) with ESMTPS id D8D7641511 for ; Mon, 1 Jun 2026 09:52:06 +0000 (UTC) Received: from m16.mail.126.com (m16.mail.126.com [220.197.31.8]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5E03E10E64F; Mon, 1 Jun 2026 10:05:43 +0000 (UTC) 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=GpqjxkI6HTsNPXTHknXZXvJU5tQpuWx9d1v/8ydLUPY=; b=SQuf0+UC/7nFo/+HlOKZzqH/gWx8d2ASi+g6yJSc2qaaqNMhs2D3lo8Q0xEGyS KJ7estbu2mNLl6XsvrrXb6gI5cvKxsBxXbyDyXeWoXbv+2a1QjIZZghL8FDWf2xM vtD1tFTW73rY9CLYQseJxjUPcMKyU+iVUp0re0P8YQQcE= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-0 (Coremail) with SMTP id _____wDn106zVx1q+XTYAg--.13632S2; Mon, 01 Jun 2026 17:58:12 +0800 (CST) Message-ID: <6A1D57B9.6000504@126.com> Date: Mon, 01 Jun 2026 17:58:17 +0800 From: Hongling Zeng User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Danilo Krummrich Subject: Re: =?UTF-8?B?5Zue5aSNOiBSZTogW1BBVENIIDAvNV0gUmV2ZXJ0IGNsZWFudXA=?= =?UTF-8?B?cyBmb3IgSVNfRVJSX09SX05VTEwoKSB1c2FnZQ==?= References: DIULSRTZPQ0H.39RB5RF1NTFYA@kernel.org <823rnittrvj-82932fejdy8@nsmail8.2--kylin--1> In-Reply-To: <823rnittrvj-82932fejdy8@nsmail8.2--kylin--1> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: _____wDn106zVx1q+XTYAg--.13632S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxZw4xJw13WFWrury8Jw4rGrg_yoWrWFW7pw 13K3yqka1qkF93tFy2va1rA3WfAr4fKF48uas3ta9xZw15XF9xJF40qF1Y9a4rCr4rua1j q39FgFWrZw1DA3JanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07U5PEfUUUUU= X-Originating-IP: [112.64.161.44] X-CM-SenderInfo: x2kr0wpolqwiqxrzqiyswou0bp/xtbBrxTktWodV7Q1eQAA3y Message-ID-Hash: DZ6RFQ5N6L2WGRTRHIUNTJH6RZ2LOJAB X-Message-ID-Hash: DZ6RFQ5N6L2WGRTRHIUNTJH6RZ2LOJAB X-MailFrom: zhongling0719@126.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: =?UTF-8?B?5pu+57qi546y?= , "rongqianfeng@vivo.com" , "kees@kernel.org" , "simona@ffwll.ch" , "dri-devel@lists.freedesktop.org" , Zhi Wang , "nouveau@lists.freedesktop.org" , "airlied@redhat.com" , "maarten.lankhorst@linux.intel.com" , "linux-kernel@vger.kernel.org" , "mripard@kernel.org" X-Mailman-Version: 3.3.8 Precedence: list List-Id: Nouveau development list Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi Danilo, I apologize for the confusion with my previous patch submission. Please disregard the patches I submitted earlier. I have now regenerated a v2 patch series following your requirements to properly document return value contracts and clean up IS_ERR_OR_NULL usage. Return value analysis: - r535_gsp_msgq_peek(): Never returns NULL - r5sp_msgq_recv_one_elem(): Never returns NULL - r535_gsp_msgq_recv(): CAN return NULL (when RPC length invalid) - r535_gsp_msg_recv(): CAN return NULL (queue drained/no matching message) - r535_gsp_rpc_get(): Never returns NULL - r535_gsp_rpc_handle_reply(): CAN return NULL (NOWAIT/NOSEQ policies) - r535_gsp_rpc_send(): CAN return NULL (via handle_reply) - r535_gsp_rpc_push(): CAN return NULL (via handle_reply) I've been careful to only clean up IS_ERR_OR_NULL() for functions that actually never return NULL, while preserving the checks for functions that can return NULL (like r5_gsp_msg_recv() and r535_gsp_msg_recv()). Could you please review if this approach is correct? Thanks, Hongling 在 2026年05月29日 17:40, 曾红玲 写道: > > Hi Danilo Krummrich: > > like this? > > 1. r535_gsp_msgq_peek(): ERR_PTR on error, valid pointer on success, > never NULL > 2. r535_gsp_msgq_recv_one_elem(): ERR_PTR on error, valid pointer on > success, never NULL > 3. r535_gsp_msgq_recv(): ERR_PTR on error, valid pointer on success, > never NULL > 4. r535_gsp_msg_recv(): ERR_PTR on error, valid pointer on success, > NULL for queue drained or no payload > 5. r535_gsp_rpc_get(): ERR_PTR on error, valid pointer on success, > never NULL > 6. r535_gsp_rpc_handle_reply(): Depends on policy, can return NULL > > TKS! > > > > > *主 题：*Re: [PATCH 0/5] Revert cleanups for IS_ERR_OR_NULL() usage > *日 期：*2026年05月29日04:48 > *发件人：*Danilo Krummrich > *收件人：*Timur Tabi,Danilo Krummrich > *抄送 > 人：*lyude@redhat.com,rongqianfeng@vivo.com,airlied@gmail.com,kees@kernel.org,simona@ffwll.ch,dri- > devel@lists.freedesktop.org,Zhi > Wang,nouveau@lists.freedesktop.org,airlied@redhat.com,maarten.lankhorst@linux.intel.com,tzimmermann@suse.de,linux-kernel@vger.kernel.org,mripard@kernel.org > > On Thu May 28, 2026 at 10:23 PM CEST, Timur Tabi wrote: > On Thu, > 2026-05-28 at 21:44 +0200, Danilo Krummrich wrote: >> >> @Timur: I do > think cleaning this up is the right call in general though, and I >> > also don't think that the whole driver necessarily needs to be > consistent on >> whether IS_ERR_OR_NULL() or IS_ERR() is used -- it > depends on the context >> (although I usually prefer not to mix up > NULL and ERR semantics in the first >> place). >> >> It should however > be consistent in terms of what functions can actually return. >> >> > ret = foo(); >> if (IS_ERR_OR_NULL(ret)) >> return ret; >> >> If foo() > can never return NULL, the above is misleading, as it puts an >> > obligation on the caller to somehow handle the NULL case and come up > with an >> actual error code for it. > > Sure, I get that. My point is > that it's often not clear whether foo() actually can never return > > NULL. > > It's been a while since I've dug through the RPC call chains > in Nouveau, so my memory is a little > hazy here. I do remember > noticing that Nouveau frequently has situations where foo() call > bar1() > and bar2(), where bar1() can return NULL but bar2() can't. So > the question is not whether foo() can > return NULL, it's whether > bar1() should not return NULL, or whether bar2() should. If there are > multiple, it has to be the superset of course. >> So, I think it is > the right call to align that to what functions can actually >> return, > but while doing this, the contract should be properly documented, such > >> that subsequent changes can be properly validated. > > "Properly > documented" and "Nouveau" are not two things that go together. > Unfortunately -- but the changes submitted by Hongling can add the > documentation for the places that are touched. @Hongling, can you > consider this in a v2 please? Thanks, Danilo > > > --- >