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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Dec 15, 2018, at 6:50 PM, Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> 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@xxxxxxxxxxxx> # distcc
> Reported-by: Sedat Dilek <sedat.dilek@xxxxxxxxx> # 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).





[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux