lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 25 Oct 2023 14:53:38 +0300
From:   Jani Nikula <>
To:     Andi Shyti <>
Cc:     Arnd Bergmann <>,
        Joonas Lahtinen <>,
        Rodrigo Vivi <>,
        Tvrtko Ursulin <>,
        David Airlie <>,
        Daniel Vetter <>,
        Badal Nilawar <>,
        Ashutosh Dixit <>,
        Arnd Bergmann <>,
        Matt Roper <>,
        Vinay Belgaumkar <>,,,,
        Andi Shyti <>
Subject: Re: [PATCH] drm/i915/mtl: avoid stringop-overflow warning

On Tue, 24 Oct 2023, Andi Shyti <> 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 <>
> 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(0xdeadbeef)

and expect everything to still work.


> The patch looks to me like it's being more complex that it
> should.
> Andi

Jani Nikula, Intel

Powered by blists - more mailing lists