linux-kernel - Re: [PATCH] x86/mce/therm_throt: Fix the access of uninitialized therm

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: <20200106070759.GB12238@zn.tnic>
Date:   Mon, 6 Jan 2020 08:07:59 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Chuansheng Liu <chuansheng.liu@...el.com>
Cc:     linux-kernel@...r.kernel.org, tony.luck@...el.com,
        tglx@...utronix.de, mingo@...hat.com, hpa@...or.com
Subject: Re: [PATCH] x86/mce/therm_throt: Fix the access of uninitialized
 therm_work

On Mon, Jan 06, 2020 at 06:41:55AM +0000, Chuansheng Liu wrote:
> In ICL platform, it is easy to hit bootup failure with panic
> in thermal interrupt handler during early bootup stage.
> 
> Such issue makes my platform almost can not boot up with
> latest kernel code.
> 
> The call stack is like:
> kernel BUG at kernel/timer/timer.c:1152!
> 
> Call Trace:
> __queue_delayed_work
> queue_delayed_work_on
> therm_throt_process
> intel_thermal_interrupt
> ...
> 
> When one CPU is up, the irq is enabled prior to CPU UP
> notification which will then initialize therm_worker.

You mean the unmasking of the thermal vector at the end of
intel_init_thermal()?

If so, why don't you move that to the end of the notifier and unmask it
only after all the necessary work like setting up the workqueues etc, is
done, and save yourself adding yet another silly bool?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette