From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/xe/drm_ras: Make counter allocation drm managed Date: Sat, 16 May 2026 10:24:56 +1000 Message-ID: In-Reply-To: <20260514202839.1888688-3-raag.jadav@intel.com> References: <20260514202839.1888688-1-raag.jadav@intel.com> <20260514202839.1888688-3-raag.jadav@intel.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 **Verdict: Correct fix, minor observation.** Switching from `kcalloc` to `drmm_kcalloc` ensures the counter array is fre= ed automatically during drm device release, which eliminates the problem wh= ere `cleanup_node_param()` wasn't called if counter allocation itself faile= d in a subsequent iteration =E2=80=94 the previous iteration's counter woul= d be leaked. ```c counter =3D drmm_kcalloc(&xe->drm, DRM_XE_RAS_ERR_COMP_MAX, sizeof(*counter= ), GFP_KERNEL); ``` The corresponding removal of `kfree(ras->info[severity])` from `cleanup_nod= e_param()` is correct since drmm now owns the lifetime: ```c - kfree(ras->info[severity]); - ras->info[severity] =3D NULL; ``` **Minor observation**: When `allocate_and_copy_counters()` fails, `ras->inf= o[severity]` is left holding an `ERR_PTR` value (set in `assign_node_params= ()` line 120-121). While this isn't a functional bug since the init path re= turns an error and nothing will dereference it, it would be cleaner to set = `ras->info[severity] =3D NULL` after the `IS_ERR` check in `assign_node_par= ams()`. Not a blocking issue. --- --- Generated by Claude Code Patch Reviewer