linux-kernel - Re: [PATCH v5 04/22] x86/virt/tdx: Prevent ACPI CPU hotplug and ACPI memory hotplug

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]

Date:   Thu, 30 Jun 2022 08:44:13 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Kai Huang <kai.huang@...el.com>, Chao Gao <chao.gao@...el.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        seanjc@...gle.com, pbonzini@...hat.com, len.brown@...el.com,
        tony.luck@...el.com, rafael.j.wysocki@...el.com,
        reinette.chatre@...el.com, dan.j.williams@...el.com,
        peterz@...radead.org, ak@...ux.intel.com,
        kirill.shutemov@...ux.intel.com,
        sathyanarayanan.kuppuswamy@...ux.intel.com,
        isaku.yamahata@...el.com, thomas.lendacky@....com,
        Tianyu.Lan@...rosoft.com
Subject: Re: [PATCH v5 04/22] x86/virt/tdx: Prevent ACPI CPU hotplug and ACPI
 memory hotplug

On 6/29/22 16:02, Kai Huang wrote:
> On Wed, 2022-06-29 at 07:22 -0700, Dave Hansen wrote:
>> On 6/24/22 04:21, Kai Huang wrote:
>> What does that #ifdef get us?  I suspect you're back to trying to
>> silence compiler warnings with #ifdefs.  The compiler *knows* that it's
>> only used in this file.  It's also used all of once.  If you make it
>> 'static inline', you'll likely get the same code generation, no
>> warnings, and don't need an #ifdef.
> 
> The purpose is not to avoid warning, but to make intel_cc_platform_has(enum
> cc_attr attr) simple that when neither TDX host and TDX guest code is turned on,
> it can be simple:
> 
> 	static bool  intel_cc_platform_has(enum cc_attr attr)
> 	{
> 		return false;
> 	}
> 
> So I don't need to depend on how internal functions are implemented in the
> header files and I don't need to guess how does compiler generate code.

I hate to break it to you, but you actually need to know how the
compiler works for you to be able to write good code.  Ignoring all the
great stuff that the compiler does for you makes your code worse.

> And also because I personally believe it doesn't hurt readability. 

Are you saying that you're ignoring long-established kernel coding style
conventions because of your personal beliefs?  That seem, um, like an
approach that's unlikely to help your code get accepted.

>> The other option is to totally lean on the compiler to figure things
>> out.  Compile this program, then disassemble it and see what main() does.
>>
>> static void func(void)
>> {
>> 	printf("I am func()\n");
>> }
>>
>> void main(int argc, char **argv)
>> {
>> 	if (0)
>> 		func();
>> }
>>
>> Then, do:
>>
>> -	if (0)
>> +	if (argc)
>>
>> and run it again.  What changed in the disassembly?
> 
> You mean compile it again?  I have to confess I never tried and don't know. 
> I'll try when I got some spare time.  Thanks for the info.

Yes, compile it again and run it again.

But, seriously, it's a quick exercise.  I can help make you some spare
time if you wish.  Just let me know.