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 DAD3A3F823C for ; Mon, 29 Jun 2026 08:37:28 +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=1782722253; cv=none; b=YaQDuJqab3t421Ifsvu0kbfVrvLm6PgFLSjLxNNfaXo3bamCbW+aorDLT6Q7VAvXRoxxyEIl1SSCDEOUse2SP6UmOofz+dNPDpDDV8WV8NYBFYEhX/buq3ya50alp6660KGbseUSMoKy1vB9jNFUY8mD6Y9LRUkAxVOE823O0SQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782722253; c=relaxed/simple; bh=Sxjdvy9V1g6u+XVgW+6g7tf+yhIZbcTTBuqwCuhDhHw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=cZdMdXY3LBgShSXNEtCw/o+STzcm0M6yhZaCZ2SzNmPSCIBbEoX0lOi/LweUlPdbGqzg/vMCI1ivGHYVmzc82JGtGcqkxX4Lcg1dP7ANqjgaWrYP3o5LW47s2FjQW6KNt+Y+Abse8Y0bm5lxiWE3BvbSSil9IlgASwhcgKENu64= 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=o6qezks8; 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="o6qezks8" 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=5JQhJVhtNqFuIOEBZ8hxWTPQkEbzMOEFkTIsOlM8mJ0=; b=o6qezks8HjLc4sgxAhwUvqx4Y5sY4eKoUcxWj/vOa7cptDXEzf7WY3URcOBsbh FzPh3nlaHMLunGHr1+ICAAEzs8HgifBtKrve3uCa6rtk0TV9wQXot+mQOT5j2GOB 0HmYHmi8rmGJVuxSUeZqJO3OhYFjAi6MEVWZKXqW9tvYs= Received: from localhost.localdomain (unknown []) by gzsmtp3 (Coremail) with SMTP id PikvCgB3KqmILkJqbhYxCA--.5715S2; Mon, 29 Jun 2026 16:36:26 +0800 (CST) Message-ID: <6A422E7E.5030402@126.com> Date: Mon, 29 Jun 2026 16:36:14 +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: lyude@redhat.com, dakr@kernel.org, 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 CC: Hongling Zeng , nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/5] nouveau/gsp: Clean up IS_ERR vs IS_ERR_OR_NULL usage References: <1782119051179226.14296.seg@mailgw.kylinos.cn> In-Reply-To: <1782119051179226.14296.seg@mailgw.kylinos.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:PikvCgB3KqmILkJqbhYxCA--.5715S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxury8CF1kXr4DKw1fKry7Awb_yoW5GrW8pa 18AFn0yr4jkrWSyFWIya18Zw1fZws3KFWxCF92gasxZw13AFWxAr4jqw1Y9a4UGw4fCa1U XrW7K3WYvr4UZwUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jUBMNUUUUU= X-CM-SenderInfo: x2kr0wpolqwiqxrzqiyswou0bp/xtbBoQrYqWpCLooHGgAA3L Hi Sorry for the noise. The v5 patch fully addresses all documentation issues and passes AI testing with no code changes. A similar fix "sunrpc: Fix error handling in rpc_sysfs_xprt_switch_add_xprt_store()" has already been accepted by the community. Please review when you have time. Thanks! 在 2026年06月22日 16:11, Hongling Zeng 写道: > This series addresses feedback from Danilo Krummrich and Timur Tabi > regarding the use of IS_ERR() vs IS_ERR_OR_NULL() in the nouveau > GSP RPC code. > > The key insight is that we should align error checking with the actual > return value contracts of each function: > - Functions that never return NULL should use IS_ERR() > - Functions that can return NULL should use IS_ERR_OR_NULL() > > This version adds documentation to clarify the return value contracts, > making it easier for maintainers to validate future changes. > > Return Value Analysis > > After thorough code analysis, the RPC functions are categorized as: > > Never return NULL (use IS_ERR):** > - r535_gsp_msgq_peek() > - r535_gsp_msgq_recv_one_elem() > - r535_gsp_rpc_get() > > CAN return NULL (use IS_ERR_OR_NULL):** > - r535_gsp_msgq_recv() - returns NULL when RPC length is invalid > - r535_gsp_msg_recv() - returns NULL when queue drained > - r535_gsp_rpc_handle_reply() - returns NULL for NOWAIT/NOSEQ policies > - r535_gsp_rpc_send() - can return NULL via handle_reply > - r535_gsp_rpc_push() - can return NULL via handle_reply > > Changes in v2 > > - Added kernel-doc comments documenting return value contracts for all > RPC functions > - Cleaned up incorrect IS_ERR_OR_NULL() usage for functions that never > return NULL > - Kept IS_ERR_OR_NULL() in places where NULL is actually possible > - Added Fixes tags to all patches > > Testing > > This fixes the NULL pointer dereference oops that occurs during > nouveau initialization on some systems. > > Patches > > Hongling Zeng (5): > nouveau/gsp/rpc: Document RPC function return value contracts > nouveau/gsp/rpc: Cleanup incorrect IS_ERR_OR_NULL in rpc.c > nouveau/gsp/rm/alloc: Cleanup IS_ERR_OR_NULL usage > nouveau/gsp/rm/bar: Cleanup IS_ERR_OR_NULL usage > nouveau/gsp: Cleanup IS_ERR_OR_NULL in nvkm_gsp_rpc_rd() > > drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 2 +- > .../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c | 2 +- > .../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/bar.c | 2 +- > .../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c | 81 ++++++++++++++++++- > 4 files changed, 81 insertions(+), 6 deletions(-)