linux-kernel - Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform

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: <f8388f18-5e90-5d0f-d681-0b17f8307dd4@csgroup.eu>
Date:   Wed, 15 Sep 2021 19:18:34 +0200
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Borislav Petkov <bp@...en8.de>,
        Michael Ellerman <mpe@...erman.id.au>
Cc:     Sathyanarayanan Kuppuswamy 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        linux-efi@...r.kernel.org, Brijesh Singh <brijesh.singh@....com>,
        kvm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        platform-driver-x86@...r.kernel.org,
        Paul Mackerras <paulus@...ba.org>, linux-s390@...r.kernel.org,
        Andi Kleen <ak@...ux.intel.com>,
        Joerg Roedel <joro@...tes.org>, x86@...nel.org,
        amd-gfx@...ts.freedesktop.org,
        Christoph Hellwig <hch@...radead.org>,
        linux-graphics-maintainer@...are.com,
        Tom Lendacky <thomas.lendacky@....com>,
        Tianyu Lan <Tianyu.Lan@...rosoft.com>,
        kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
        iommu@...ts.linux-foundation.org, linux-fsdevel@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of
 cc_platform_has()

Le 15/09/2021 à 12:08, Borislav Petkov a écrit :
> On Wed, Sep 15, 2021 at 10:28:59AM +1000, Michael Ellerman wrote:
>> I don't love it, a new C file and an out-of-line call to then call back
>> to a static inline that for most configuration will return false ... but
>> whatever :)
> 
> Yeah, hch thinks it'll cause a big mess otherwise:
> 
> https://lore.kernel.org/lkml/YSScWvpXeVXw%2Fed5@infradead.org/

Could you please provide more explicit explanation why inlining such an 
helper is considered as bad practice and messy ?

Because as demonstrated in my previous response some days ago, taking 
that outline ends up with an unneccessary ugly generated code and we 
don't benefit front GCC's capability to fold in and opt out unreachable 
code.

As pointed by Michael in most cases the function will just return false 
so behind the performance concern, there is also the code size and code 
coverage topic that is to be taken into account. And even when the 
function doesn't return false, the only thing it does folds into a 
single powerpc instruction so there is really no point in making a 
dedicated out-of-line fonction for that and suffer the cost and the size 
of a function call and to justify the addition of a dedicated C file.

> 
> I guess less ifdeffery is nice too.

I can't see your point here. Inlining the function wouldn't add any 
ifdeffery as far as I can see.

So, would you mind reconsidering your approach and allow architectures 
to provide inline implementation by just not enforcing a generic 
prototype ? Or otherwise provide more details and exemple of why the 
cons are more important versus the pros ?

Thanks
Christophe