linux-kernel - Re: [EXTERNAL] [PATCH] x86: Fix build regression with CONFIG_KEXEC

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: <16E951B7-155C-4E84-BFC3-CAA9EC765960@infradead.org>
Date: Mon, 09 Dec 2024 21:52:57 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Borislav Petkov <bp@...en8.de>
CC: Damien Le Moal <dlemoal@...nel.org>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Ingo Molnar <mingo@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
 x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [EXTERNAL] [PATCH] x86: Fix build regression with CONFIG_KEXEC_JUMP enabled

On 9 December 2024 17:18:18 GMT, Borislav Petkov <bp@...en8.de> wrote:
>On Mon, Dec 09, 2024 at 05:07:06PM +0000, David Woodhouse wrote:
>> I suspect it would be less ugly overall if we #ifdef out the whole of
>> the preserve_context code path when CONFIG_KEXEC_JUMP isn't enabled,
>> rather than only the various parts of it that actually cause compile
>> failures, leaving a very confusing set of nonsense dead code actually
>> being compiled in.
>
>$ git grep CONFIG_KEXEC_JUMP *.[chS] | wc -l
>10
>
>That's mostly C code. You want to push the ifdeffery into the asm?

Already had to. The question is whether I'm content to follow the existing precedent and put the ifdef around just the two lines of code which don't compile otherwise, or whether I want to clean it up and elide the whole of the unreachable code paths.