On Thu, 6 Jun 2019 at 10:58, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > On Thu, 6 Jun 2019 at 09:08, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, Jun 06, 2019 at 08:55:29AM +0200, Ard Biesheuvel wrote: > > > On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > > > > > > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > > > > <ard.biesheuvel@xxxxxxxxxx> wrote: > > > > > For the record, this is an example of why I think backporting those > > > > > clang enablement patches is a bad idea. > > > > > > > > There's always a risk involved with backports of any kind; more CI > > > > coverage can help us mitigate some of these risks in an automated > > > > fashion before we get user reports like this. I meet with the > > > > KernelCI folks weekly, so I'll double check on the coverage of the > > > > stable tree's branches. The 0day folks are also very responsive and > > > > I've spoken with them a few times, so I'll try to get to the bottom of > > > > why this wasn't reported by either of those. > > > > > > > > Also, these patches help keep Android, CrOS, and Google internal > > > > production kernels closer to their upstream sources. > > > > > > > > > We can't actually build those > > > > > kernels with clang, can we? So what is the point? </grumpy> > > > > > > > > Here's last night's build: > > > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 > > > > > > > > > > If you are saying that plain upstream 4.9-stable defconfig can be > > > built with Clang, then I am pleasantly surprised. > > > > I know some specific configs can, there's no rule that I know of that > > 'defconfig' support is required. But then again, it might also work, > > try it and see :) > > > > Well, it is the rule that the arm64 maintainers use. > > > > > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels > > > > built with Clang. I think this number will grow at least one order of > > > > magnitude imminently. > > > > > > > > > > I know that (since you keep reminding me :-)), but obviously, Google > > > does not care about changes that regress GCC support. > > > > What are you talking about? Bugs happen all the time, what specifically > > did "Google" do to break gcc support? If you are referring to this > > patch, and it is a regression, of course I will revert it. But note > > that gcc and 4.9 works just fine for all of the other users right now, > > remember we do do a lot of testing of these releases. > > > > Don't get me wrong: I am not blaming Google for this. But having > strict Documented/ stable-rules, violating them by backporting patches > that are clearly not bug fixes, and *then* saying 'bugs happen all the > time' makes no sense to me at all. BTW I hit the same issue immediately building 4.9.180 defconfig + CONFIG_RANDOMIZE_BASE=y, using my distro GCC (6.3.0), so I'd say the testing coverage is not sufficient.
