From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 72F562459DD for ; Thu, 28 May 2026 20:48:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780001304; cv=none; b=W7mJw7ghQeTJXR4MvRdu3O1vx9gsP4cawUF89RiUXWqiOQpb/t+fHxcyz5yPiX8SxB7oXgUML2tYgDVIiSf/afGOpRFiTdrb1TTPIRoYeiDjyd44EvyoSfrUAqcxzsNLaTd9ECZO6f0/GAP1BAmhlcIx5mUqJBnaWDmOxz0sKFg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780001304; c=relaxed/simple; bh=QZxTXxJePH7Nt0MYvQ0GAAi97JFaU4wkCEhNR1QcZkY=; h=Mime-Version:Content-Type:Date:Message-Id:From:Subject:Cc:To: References:In-Reply-To; b=ZjhiaU7Qo+l7NY0hqlHzjfHIBACkyeUZGXBKQBsThSDfpN4SdWZ7DyIyro73K+SKxuQj1wMBVz+BdqqlNrjpbH5cfAPPN+IxUIS8dq0IuROeDM+F7dtVB1/zzxr2jrVFQH5JyaJtv37u9hUnXmcPOe9NrENv1tHt09bI+DFSAMo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jOyHkSwV; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jOyHkSwV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4330F1F000E9; Thu, 28 May 2026 20:48:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780001303; bh=FpQud1RDgcM36CY4JFAfny+s7huVK65jhoq2kaa9jkQ=; h=Date:From:Subject:Cc:To:References:In-Reply-To; b=jOyHkSwVCO70aJ4Ov/94NwYVAy9n5PAM8hPSejYwgQIExxEYZNmEbWq7U0TWFEOdd K32gMY1WhKQA+DvPEHgopFQc3JP2M0ykroQ8dB0Wj86HuT08+iBhBvGvOy6koG2EiL DAlnC/FvXx6253dt5qhslZ/cqwceHP6v9WSIOucB4rLfmQRgw2v3HNmZ3+Sel8rOKu 4umK7DtSkJPOLDgbPSa2qf1l2CLC/senmm3oCzL/LnF3rc+Ia/ky6LhbxeiBBKDOiq XDkoqqzaDzTE9xot3M3lN5ra9OrYN06Od/8WTxSA2lvsltKIzq50/WZUHYTy14vgHf FBmncuzlJWGBA== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 28 May 2026 22:48:18 +0200 Message-Id: From: "Danilo Krummrich" Subject: Re: [PATCH 0/5] Revert cleanups for IS_ERR_OR_NULL() usage Cc: "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" , "zenghongling@kylinos.cn" , "tzimmermann@suse.de" , "linux-kernel@vger.kernel.org" , "mripard@kernel.org" To: "Timur Tabi" , "Hongling Zeng" References: <20260528192847.4077458-1-lyude@redhat.com> <4f4b7a4a89a253e515b009ccfa7ddfd21853b64d.camel@nvidia.com> In-Reply-To: <4f4b7a4a89a253e515b009ccfa7ddfd21853b64d.camel@nvidia.com> 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: >>=20 >> @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 consisten= t on >> whether IS_ERR_OR_NULL() or IS_ERR() is used -- it depends on the contex= t >> (although I usually prefer not to mix up NULL and ERR semantics in the f= irst >> place). >>=20 >> It should however be consistent in terms of what functions can actually = return. >>=20 >> ret =3D foo(); >> if (IS_ERR_OR_NULL(ret)) >> return ret; >>=20 >> 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 wit= h an >> actual error code for it. > > Sure, I get that. My point is that it's often not clear whether foo() ac= tually can never return > NULL. =20 > > 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 questi= on 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 act= ually >> 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 document= ation for the places that are touched. @Hongling, can you consider this in a v2 please? Thanks, Danilo