linux-kernel - Re: [PATCH] arch/x86/entry_fred: don't set up KVM IRQs if KVM is disabled

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: <87il2oar01.ffs@tglx>
Date: Sat, 17 Feb 2024 01:11:58 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Max Kellermann <max.kellermann@...os.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Xin Li <xin@...or.com>, Sean
 Christopherson <seanjc@...gle.com>, hpa@...or.com, x86@...nel.org,
 linux-kernel@...r.kernel.org, Stephen Rothwell <sfr@...b.auug.org.au>,
 kvm@...r.kernel.org
Subject: Re: [PATCH] arch/x86/entry_fred: don't set up KVM IRQs if KVM is
 disabled

On Sat, Feb 17 2024 at 00:00, Max Kellermann wrote:
> On Fri, Feb 16, 2024 at 10:45 PM Thomas Gleixner <tglx@...utronixde> wrote:
>> #ifdeffing out the vector numbers is silly to begin with because these
>> vector numbers stay assigned to KVM whether KVM is enabled or not.
>
> There could be one non-silly use of this: if the macros are not
> defined in absence of the feature, any use of it will lead to a
> compiler error, which is good, because it may reveal certain kinds of
> bugs.

I generally agree with this sentiment, but for constants like those in
the case at hand I really draw the line.

> (Though I agree that this isn't worth the code ugliness. I prefer to
> avoid the preprocessor whenever possible. I hate how much the kernel
> uses macros instead of inline functions.)

No argument about that. I'm urging people to use inlines instead of
macros where ever possible, but there are things which can only solved
by macros.

I'm well aware that I wrote some of the more ugly ones myself. Though
the end justifies the means. If the ugly macro from hell which you
verify once safes you from the horrors of copy & pasta error hell then
they are making the code better and there are plenty of options to make
them reasonably (type) safe if done right.

Thanks,

        tglx