From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: accel/amdxdna: Disable device buffer exporting Date: Wed, 27 May 2026 14:20:13 +1000 Message-ID: In-Reply-To: <20260526185058.1780869-1-lizhi.hou@amd.com> References: <20260526185058.1780869-1-lizhi.hou@amd.com> <20260526185058.1780869-1-lizhi.hou@amd.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Status: Looks good** The patch adds a minimal `.export` callback that returns `-EOPNOTSUPP` and = wires it into `amdxdna_gem_dev_obj_funcs`: ```c static struct dma_buf *amdxdna_gem_dev_obj_export(struct drm_gem_object *go= bj, int flags) { return ERR_PTR(-EOPNOTSUPP); } ``` **Observations:** 1. **Correct error code**: `-EOPNOTSUPP` is appropriate here =E2=80=94 it s= ignals that the operation is not supported, which is the right semantic for= a buffer type that should never be exported. 2. **Correct override mechanism**: Without this callback, `drm_gem_prime_ha= ndle_to_fd()` in `drm_prime.c:387-390` would fall through to `drm_gem_prime= _export()`, which would attempt the export. The `dev_obj_funcs` struct lack= s `.pin`, `.get_sg_table`, and other callbacks that the default export path= relies on, so the export would likely fail in a confusing way or produce a= non-functional dma-buf. Explicitly returning an error is much cleaner. 3. **Consistent with driver design**: The shmem object funcs (`amdxdna_gem_= shmem_funcs` at line 739) have a custom `.export =3D amdxdna_gem_prime_expo= rt`, showing the driver is intentional about which object types can be expo= rted. This patch completes that story for device objects. 4. **Unused parameter**: The `gobj` and `flags` parameters are unused, but = this is standard for stub/rejection callbacks in the kernel =E2=80=94 no `_= _maybe_unused` annotation is needed since the kernel build suppresses these= warnings for function pointer implementations. No concerns with this patch. It's a clean, minimal hardening fix. --- Generated by Claude Code Patch Reviewer