[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7f1ad610-5a37-4f74-8eee-5f37556d9576@ursulin.net>
Date: Mon, 28 Apr 2025 13:09:46 +0100
From: Tvrtko Ursulin <tursulin@...ulin.net>
To: Kees Cook <kees@...nel.org>, Jani Nikula <jani.nikula@...ux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>, David Airlie <airlied@...il.com>,
Simona Vetter <simona@...ll.ch>, Matt Roper <matthew.d.roper@...el.com>,
Gustavo Sousa <gustavo.sousa@...el.com>,
Andi Shyti <andi.shyti@...ux.intel.com>,
Lucas De Marchi <lucas.demarchi@...el.com>, intel-gfx@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, Gnattu OC <gnattuoc@...com>,
Nitin Gote <nitin.r.gote@...el.com>, Ranu Maurya <ranu.maurya@...el.com>,
Ville Syrjälä <ville.syrjala@...ux.intel.com>,
Angus Chen <angus.chen@...el.com>,
Juha-Pekka Heikkila <juhapekka.heikkila@...il.com>,
Yu Jiaoliang <yujiaoliang@...o.com>,
Dnyaneshwar Bhadane <dnyaneshwar.bhadane@...el.com>,
linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] drm/i915/gt: Remove const from struct i915_wa list
allocation
On 26/04/2025 07:13, Kees Cook wrote:
> In preparation for making the kmalloc family of allocators type aware,
> we need to make sure that the returned type from the allocation matches
> the type of the variable being assigned. (Before, the allocator would
> always return "void *", which can be implicitly cast to any pointer type.)
>
> The assigned type is "struct i915_wa *". The returned type, while
> technically matching, will be const qualified. As there is no general
> way to remove const qualifiers, adjust the allocation type to match
> the assignment.
>
> Signed-off-by: Kees Cook <kees@...nel.org>
> ---
> Cc: Jani Nikula <jani.nikula@...ux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@...el.com>
> Cc: Tvrtko Ursulin <tursulin@...ulin.net>
> Cc: David Airlie <airlied@...il.com>
> Cc: Simona Vetter <simona@...ll.ch>
> Cc: Matt Roper <matthew.d.roper@...el.com>
> Cc: Gustavo Sousa <gustavo.sousa@...el.com>
> Cc: Andi Shyti <andi.shyti@...ux.intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@...el.com>
> Cc: <intel-gfx@...ts.freedesktop.org>
> Cc: <dri-devel@...ts.freedesktop.org>
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 116683ebe074..b37e400f74e5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -156,7 +156,7 @@ static void _wa_add(struct i915_wa_list *wal, const struct i915_wa *wa)
> if (IS_ALIGNED(wal->count, grow)) { /* Either uninitialized or full. */
> struct i915_wa *list;
>
> - list = kmalloc_array(ALIGN(wal->count + 1, grow), sizeof(*wa),
> + list = kmalloc_array(ALIGN(wal->count + 1, grow), sizeof(*list),
Will the sizeof stay, and if so, how will kmalloc be able to distinguish
the type? Or we expect one more churn on the same line?
Regards,
Tvrtko
> GFP_KERNEL);
> if (!list) {
> drm_err(&i915->drm, "No space for workaround init!\n");
Powered by blists - more mailing lists