On Sun, Dec 16, 2018 at 12:29 PM Nadav Amit <namit@xxxxxxxxxx> wrote:
>
> > 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&data=02%7C01%7Cnamit%40vmware.com%7Ce893ce88065e4c59236308d663019424%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636805255787607178&sdata=miiUndmPfGNKvrzD5mttC1%2Bn6rNaoIFebjZOAkBr24Y%3D&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.
OK.
> The distcc issue has already been resolved both in distcc
Precisely, the fix-up was submitted,
but not pulled yet as of writing.
https://github.com/distcc/distcc/pull/313
> and in the patches
> I’ve sent: https://lkml.org/lkml/2018/11/15/467 .
I was scared by this ugly fix-up, so I rejected it.
> 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?
https://www.spinics.net/lists/linux-kbuild/msg20037.html
We can fix it under circumstances "we can do anything"
although I am scared by endless Makefile hacks.
> Please regard my comments regarding v1.
I will try my best, although I felt some of your requests were too much.
I am not an x86 developer.
I posted this so people can play with 'asm inline'
https://lore.kernel.org/patchwork/patch/1024590/
You can confirm vmlinux size is increased,
and some symbols disappears.
> I must admit that I’m very surprised
> that you don’t like the patches since you ack’d the original patch-set
I think ack and "I like it" are different.
There are situations where we had to accept something reluctantly.
Without my ack, your patch series would not have been
merged via x86 tree.
There was no other solution at that time.
Also, I could not predict potential problems, which turned out later.
So I let it go.
It would have been better if
the following discussion had stared earlier.
https://lkml.org/lkml/2018/10/7/92
Now, we got a much cleaner solution.
I believe we should replace the workarounds with it.
> (and
> actually assisted me in changing the Makefile).
You were clearly breaking the build system.
So, I provided a less ugly solution.
Again, the in-kernel hack was the only solution at that time,
but the situation has changed then.
--
Best Regards
Masahiro Yamada
