From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: nouveau/gsp: Clean up IS_ERR vs IS_ERR_OR_NULL usage Date: Thu, 04 Jun 2026 14:22:53 +1000 Message-ID: In-Reply-To: <20260601095403.228220-1-zenghongling@kylinos.cn> References: <20260601095403.228220-1-zenghongling@kylinos.cn> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Overall Series Review Subject: nouveau/gsp: Clean up IS_ERR vs IS_ERR_OR_NULL usage Author: Hongling Zeng Patches: 6 Reviewed: 2026-06-04T14:22:53.821924 --- This is a 5-patch series cleaning up `IS_ERR()` vs `IS_ERR_OR_NULL()` usage in the nouveau GSP RPC code, targeting alignment between error checks and actual function return-value contracts. **The functional changes (patches 2-5) are already applied on drm-next**, which is why the patches don't apply cleanly. These may have been applied from an earlier version or independently. Only patch 1 (documentation) would be additive, but it contains a significant misplacement bug. **The cover letter claims "Added Fixes tags to all patches"** in the v2 changelog, but none of the patches actually carry any `Fixes:` tags. The return-value analysis in the cover letter is largely correct. One concern: the cover letter correctly identifies `r535_gsp_msgq_recv()` as able to return NULL (via the `WARN_ON(rpc->length > max_rpc_size)` path at rpc.c:299-300), but the series doesn't address the existing `IS_ERR()` check of its return value in `r535_gsp_msg_recv()` (rpc.c:465-466 on drm-next). If that NULL path ever fires, the subsequent `rpc->rpc_result` access would be a NULL pointer dereference. This is a pre-existing latent issue, not introduced by this series, but it's worth noting given the series explicitly analyzed this function's return contract. --- Generated by Claude Code Patch Reviewer