linux-kernel - Re: [PATCH v2] x86, kbuild: revert macrofying inline assembly code

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: <9691ECB6-D659-4E88-B8AF-4947B9431AF1@vmware.com>
Date:   Sun, 16 Dec 2018 03:28:23 +0000
From:   Nadav Amit <namit@...are.com>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
CC:     X86 ML <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        Richard Biener <rguenther@...e.de>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        "linux-sparse@...r.kernel.org" <linux-sparse@...r.kernel.org>,
        Alok Kataria <akataria@...are.com>,
        Juergen Gross <jgross@...e.com>,
        "linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH v2] x86, kbuild: revert macrofying inline assembly code

> On Dec 15, 2018, at 6:50 PM, Masahiro Yamada <yamada.masahiro@...ionext.com> wrote:
> 
> Revert the following 9 commits:
> 
> [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to
>    work around GCC inlining bugs")
> 
>    This was partially reverted because it made good cleanups
>    irrespective of the inlining issue; the error message is still
>    unneeded, and the conversion to STATIC_BRANCH_{NOP,JUMP} should
>    be kept.
> 
> [2] d5a581d84ae6 ("x86/cpufeature: Macrofy inline assembly code to
>    work around GCC inlining bugs")
> 
> [3] 0474d5d9d2f7 ("x86/extable: Macrofy inline assembly code to work
>    around GCC inlining bugs")
> 
> [4] 494b5168f2de ("x86/paravirt: Work around GCC inlining bugs when
>    compiling paravirt ops")
> 
> [5] f81f8ad56fd1 ("x86/bug: Macrofy the BUG table section handling,
>    to work around GCC inlining bugs")
> 
> [6] 77f48ec28e4c ("x86/alternatives: Macrofy lock prefixes to work
>   around GCC inlining bugs")
> 
> [7] 9e1725b41059 ("x86/refcount: Work around GCC inlining bug")
> 
>    Resolved conflicts in arch/x86/include/asm/refcount.h caused by
>    288e4521f0f6 ("x86/asm: 'Simplify' GEN_*_RMWcc() macros").
> 
> [8] c06c4d809051 ("x86/objtool: Use asm macros to work around GCC
>    inlining bugs")
> 
> [9] 77b0bf55bc67 ("kbuild/Makefile: Prepare for using macros in inline
>    assembly code to work around asm() related GCC inlining bugs")
> 
> A few days after those commits applied, discussion started to solve
> the issue more elegantly with the help of compiler:
> 
>  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F10%2F7%2F92&amp;data=02%7C01%7Cnamit%40vmware.com%7Ce893ce88065e4c59236308d663019424%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636805255787607178&amp;sdata=miiUndmPfGNKvrzD5mttC1%2Bn6rNaoIFebjZOAkBr24Y%3D&amp;reserved=0
> 
> The new syntax "asm inline" was implemented by Segher Boessenkool, and
> now queued up for GCC 9. (People were positive even for back-porting it
> to older compilers).
> 
> Since the in-kernel workarounds merged, some issues have been reported:
> breakage of building with distcc/icecc, breakage of distro packages for
> module building. (More fundamentally, we cannot build external modules
> after 'make clean'.)
> 
> I do not want to mess up the build system any more.
> 
> Given that this issue will be solved in a cleaner way sooner or later,
> let's revert the in-kernel workarounds, and wait for GCC 9.
> 
> Reported-by: Logan Gunthorpe <logang@...tatee.com> # distcc
> Reported-by: Sedat Dilek <sedat.dilek@...il.com> # deb/rpm package

It is customary to cc those who report an issue.

The distcc issue has already been resolved both in distcc and in the patches
I’ve sent: https://lkml.org/lkml/2018/11/15/467 . So I cannot understand why
it is mentioned as a motivation.

It sounds that the external modules can easily be resolved. Can you please
provide a link for the bug report?

Please regard my comments regarding v1. I must admit that I’m very surprised
that you don’t like the patches since you ack’d the original patch-set (and
actually assisted me in changing the Makefile).