Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] Missing explicit return type cast in drmm_kzalloc_objs / drmm_kzalloc_obj permits silent heap buffer overflows. - [Low] Kernel-doc parameter name mismatch in drmm_kzalloc_obj triggers documentation warnings. --
commit 852017e1ea6892532ead5eeb34b599432f852a80 Author: Dmitry Baryshkov <[email protected]> drm/managed: implement managed versions of kzalloc_obj/objs() This commit implements drm_device-managed versions of the kzalloc_obj() and kzalloc_objs() macros. They provide a convenient interface for allocating objects with automatic freeing via the DRM managed API, defaulting to GFP_KERNEL. > diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h > index 72bfac002c062..d196387506c97 100644 > --- a/include/drm/drm_managed.h > +++ b/include/drm/drm_managed.h > @@ -105,6 +105,28 @@ static inline void *drmm_kcalloc(struct drm_device *dev, > return drmm_kmalloc_array(dev, n, size, flags | __GFP_ZERO); > } > > +/** > + * drmm_kzalloc_objs - &drm_device-managed kzalloc_objs() > + * @dev: DRM device > + * @p: Variable or type to allocate an array of > + * @count: How many elements in the array > + * > + * Returns: newly allocated pointer to the zeroed array of @P on success, or > + * NULL on failure. > + */ > +#define drmm_kzalloc_objs(dev, p, count) \ > + drmm_kcalloc(dev, count, sizeof(typeof(p)), GFP_KERNEL) [Severity: High] Does this macro need an explicit return type cast like the standard kzalloc_objs() macro has? The standard kzalloc_obj(P) and kzalloc_objs(P, count) macros explicitly cast their return values to (typeof(P) *). This cast provides a compile-time safety guard: if a developer mistakenly passes a pointer variable ptr instead of the dereferenced pointer *ptr (e.g., ptr = kzalloc_obj(ptr)), the macro evaluates sizeof(typeof(ptr)) (allocating 8 bytes) and returns a double pointer (typeof(ptr) *). Assigning this back to ptr triggers an "assignment from incompatible pointer type" compiler warning, catching the error immediately. Since drmm_kzalloc_objs directly returns void * from drmm_kcalloc, the exact same mistake (ptr = drmm_kzalloc_obj(dev, ptr)) compiles silently without warnings because C implicitly casts void * to any pointer type. This allocates only the 8-byte pointer size instead of the full structure size, which could lead to a silent out-of-bounds heap overwrite. Should this macro wrap the drmm_kcalloc call in an explicit ((typeof(p) *) ...) cast to maintain the API safety guarantees of the standard macros it mimics? > + > +/** > + * drmm_kzalloc_obj - &drm_device-managed kzalloc_obj() > + * @dev: DRM device > + * @p: Variable or type to allocate > + * > + * Returns: newly allocated pointer to a @p on success, or NULL on failure. > + */ > +#define drmm_kzalloc_obj(dev, P) \ > + drmm_kzalloc_objs(dev, P, 1) [Severity: Low] This isn't a bug, but does the macro parameter case mismatch the kernel-doc? In the kernel-doc comment for drmm_kzalloc_obj, the parameter is documented as @p (lowercase). However, the actual macro definition uses P (uppercase) as the parameter name. Since kernel-doc is case-sensitive, this mismatch will trigger warnings for an "Excess function parameter p" and "Function parameter P not described" during document generation. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
