* Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
> Some of the error paths in this function return don't initialize the
> error code. Return -ENODEV.
>
> Fixes: d6389d3ccc13 ("perf/x86/amd/uncore: Refactor uncore management")
> Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> ---
> arch/x86/events/amd/uncore.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
> index 9b444ce24108..a389828f378c 100644
> --- a/arch/x86/events/amd/uncore.c
> +++ b/arch/x86/events/amd/uncore.c
> @@ -1009,7 +1009,8 @@ static struct amd_uncore uncores[UNCORE_TYPE_MAX] = {
> static int __init amd_uncore_init(void)
> {
> struct amd_uncore *uncore;
> - int ret, i;
> + int ret = -ENODEV;
> + int i;
>
> if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
> boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
Ugh, why on Earth didn't GCC warn about this? The bad pattern is pretty
simple & obvious once pointed out ... compilers should have no trouble
realizing that 'ret' is returned uninitialized in some of these control
paths. Yet not a peep from the compiler ...
Thanks for the fix!
Ingo
