[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o7gm9av1.fsf@intel.com>
Date: Wed, 25 Oct 2023 14:53:38 +0300
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Andi Shyti <andi.shyti@...nel.org>
Cc: Arnd Bergmann <arnd@...nel.org>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Badal Nilawar <badal.nilawar@...el.com>,
Ashutosh Dixit <ashutosh.dixit@...el.com>,
Arnd Bergmann <arnd@...db.de>,
Matt Roper <matthew.d.roper@...el.com>,
Vinay Belgaumkar <vinay.belgaumkar@...el.com>,
intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org,
Andi Shyti <andi.shyti@...ux.intel.com>
Subject: Re: [PATCH] drm/i915/mtl: avoid stringop-overflow warning
On Tue, 24 Oct 2023, Andi Shyti <andi.shyti@...nel.org> wrote:
> Hi Jani,
>
>> > static void rc6_res_reg_init(struct intel_rc6 *rc6)
>> > {
>> > - memset(rc6->res_reg, INVALID_MMIO_REG.reg, sizeof(rc6->res_reg));
>>
>> That's just bollocks. memset() is byte granularity, while
>> INVALID_MMIO_REG.reg is u32. If the value was anything other than 0,
>> this would break.
>
> Actually it's:
>
> void *memset(void *s, int c, size_t count)
And? It still sets each byte in s to (the lowest 8 bits of) c.
>
>> And you're not supposed to look at the guts of i915_reg_t to begin with,
>> that's why it's a typedef. Basically any code that accesses the members
>> of i915_reg_t outside of its implementation are doing it wrong.
>>
>> Reviewed-by: Jani Nikula <jani.nikula@...el.com>
>
> in any case, I agree with your argument, but why can't we simply
> do:
>
> memset(rc6->res_reg, 0, sizeof(rc6->res_reg));
>
> ?
We can simply do a lot of things in C, but IMO that's semantically
wrong. i915_reg_t is supposed to be an opaque type. We're not supposed
to know what it contains, and what values are valid or invalid for it.
That's one of the reasons we have i915_reg_t in the first place (type
safety being the primary one).
Basically you should be able to do
-#define INVALID_MMIO_REG _MMIO(0)
+#define INVALID_MMIO_REG _MMIO(0xdeadbeef)
and expect everything to still work.
BR,
Jani.
>
> The patch looks to me like it's being more complex that it
> should.
>
> Andi
--
Jani Nikula, Intel
Powered by blists - more mailing lists