From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752097AbdI2Hvg (ORCPT ); Fri, 29 Sep 2017 03:51:36 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:50712 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750907AbdI2Hve (ORCPT ); Fri, 29 Sep 2017 03:51:34 -0400 X-Google-Smtp-Source: AOwi7QDNXDEZJbvohEIl+rfNrw6bfNsZrjlrwSJKtxCPUOMtDTdfftavoCG54KrfM7VTNgCAcYdxdA== Date: Fri, 29 Sep 2017 09:51:30 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Josh Poimboeuf , the arch/x86 maintainers , kernel test robot , Andrey Ryabinin , Matthias Kaehlcke , Alexander Potapenko , Andy Lutomirski , Arnd Bergmann , Dmitriy Vyukov , Miguel Bernal Marin , Peter Zijlstra , Thomas Gleixner , LKML , LKP Subject: Re: [PATCH] x86/asm: Fix inline asm call constraints for GCC 4.4 Message-ID: <20170929075130.unemx3lbusjd6f6q@gmail.com> References: <20170928074758.GS17200@yexl-desktop> <20170928164422.sl4z4sfbkyscbxrk@treble> <20170928170121.qpyyfjijuwdkfx7g@treble> <20170928191032.5fhnyrark5ebov4c@treble> <20170928215826.6sdpmwtkiydiytim@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Linus Torvalds wrote: > On Thu, Sep 28, 2017 at 2:58 PM, Josh Poimboeuf wrote: > > > > Reported-by: kernel test robot > > Fixes: f5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang") > > Signed-off-by: Josh Poimboeuf > > Side note: it's not like I personally need the credit, but in general > I really want people to pick up on who debugged the code and pointed > to the solution. That's often more of the work than the fix itself. > > The kernel test robot report looked to be ignored as a "gcc-4.4 is too > old to worry about" thing. [...] No, and sorry if my first reply grumbling about how old GCC 4.4 is sounded that way! We have to live with compiler bugs no matter how old the compiler is, the release cycles are decoupled to such a degree and external tooling propagates with such high latencies that that's the only sane thing to do. We also officially support GCC 3.2 and later compilers. Had this regression not been resolved within a week or so I was fully ready to queue up a revert commit, no questions asked. Plus it's not just that it's a regression, but adding support for a different compiler is about the _worst_ possible reason to break working compilers ... > [...] People who then step up and analyze the problem are rare as it is. They > need to be credited in the commit logs. > > We don't have any fixed format for that, but it's pretty free-form. So > we have tags like > > Root-caused-by: > Diagnosed-by: > Analyzed-by: > Debugged-by: > Bisected-by: > Fix-suggested-by: > > etc for giving credit to people who figured out some part of a bug > (and, having grepped for this, we also a _shitload_ of miss-spellings > of various things ;) Yeah, I sometimes add such tags, but not routinely. I'll lower the threshold for adding such tags, to create further incentives for people to help debug crashes. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1100093571543862474==" MIME-Version: 1.0 From: Ingo Molnar To: lkp@lists.01.org Subject: Re: [PATCH] x86/asm: Fix inline asm call constraints for GCC 4.4 Date: Fri, 29 Sep 2017 09:51:30 +0200 Message-ID: <20170929075130.unemx3lbusjd6f6q@gmail.com> In-Reply-To: List-Id: --===============1100093571543862474== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable * Linus Torvalds wrote: > On Thu, Sep 28, 2017 at 2:58 PM, Josh Poimboeuf w= rote: > > > > Reported-by: kernel test robot > > Fixes: f5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clan= g") > > Signed-off-by: Josh Poimboeuf > = > Side note: it's not like I personally need the credit, but in general > I really want people to pick up on who debugged the code and pointed > to the solution. That's often more of the work than the fix itself. > = > The kernel test robot report looked to be ignored as a "gcc-4.4 is too > old to worry about" thing. [...] No, and sorry if my first reply grumbling about how old GCC 4.4 is sounded = that = way! We have to live with compiler bugs no matter how old the compiler is, = the = release cycles are decoupled to such a degree and external tooling propagat= es with = such high latencies that that's the only sane thing to do. We also officially support GCC 3.2 and later compilers. Had this regression= not = been resolved within a week or so I was fully ready to queue up a revert co= mmit, = no questions asked. Plus it's not just that it's a regression, but adding support for a differe= nt = compiler is about the _worst_ possible reason to break working compilers ... > [...] People who then step up and analyze the problem are rare as it is. = They = > need to be credited in the commit logs. > = > We don't have any fixed format for that, but it's pretty free-form. So > we have tags like > = > Root-caused-by: > Diagnosed-by: > Analyzed-by: > Debugged-by: > Bisected-by: > Fix-suggested-by: > = > etc for giving credit to people who figured out some part of a bug > (and, having grepped for this, we also a _shitload_ of miss-spellings > of various things ;) Yeah, I sometimes add such tags, but not routinely. I'll lower the threshol= d for = adding such tags, to create further incentives for people to help debug cra= shes. Thanks, Ingo --===============1100093571543862474==--