linux-kernel - Re: [Intel-gfx] [PATCH] drm/i915: Zero initialize this_cpu in busywait

lists.openwall.net		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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <155203363088.27405.11887329278848171622@skylake-alporthouse-com>
Date:   Fri, 08 Mar 2019 08:27:10 +0000
From:   Chris Wilson <chris@...is-wilson.co.uk>
To:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>
Cc:     intel-gfx@...ts.freedesktop.org,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        clang-built-linux@...glegroups.com,
        Nathan Chancellor <natechancellor@...il.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Zero initialize this_cpu in busywait_stop

Quoting Nathan Chancellor (2019-03-08 01:20:24)
> When building with -Wsometimes-uninitialized, Clang warns:
> 
> drivers/gpu/drm/i915/i915_request.c:1032:6: warning: variable 'this_cpu'
> is used uninitialized whenever '&&' condition is false
> [-Wsometimes-uninitialized]
> 
> time_after expands to use two typecheck with logical ANDs between them.
> typecheck evaluates to 1 but Clang clearly gets confused with the logic
> that as semantic analysis happens early in the pipeline. Fix this by
> just zero initializing this_cpu as it will always be properly
> initialized before the comparison below.
> 
> Link: https://github.com/ClangBuiltLinux/linux/issues/415
> Signed-off-by: Nathan Chancellor <natechancellor@...il.com>
> ---
> 
> Alternatively, this can be solved by having the return value of
> local_clock_us(&this_cpu) be a local variable but this seems less
> controversial.

I'll just wait for clang to be fixed, as this severely undermines any
respect I have for its semantic analysis.
-Chris