Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <000000000000c25ce105a8a8fcd9@google.com> <20200622094923.GP576888@hirez.programming.kicks-ass.net>
 <20200623124413.08b2bd65@canb.auug.org.au> <20200623093230.GD4781@hirez.programming.kicks-ass.net>
In-Reply-To: <20200623093230.GD4781@hirez.programming.kicks-ass.net>
From:   Marco Elver <elver@google.com>
Date:   Tue, 23 Jun 2020 12:09:06 +0200
Message-ID: <CANpmjNOeN=m5i-kEn-no5d3zUdAKv=gLidEENtgQCo5umNTSjw@mail.gmail.com>
Subject: Re: linux-next build error (9)
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Stephen Rothwell <sfr@canb.auug.org.au>,
        syzbot <syzbot+dbf8cf3717c8ef4a90a0@syzkaller.appspotmail.com>,
        Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Jim Mattson <jmattson@google.com>, joro@8bytes.org,
        kvm@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        sean.j.christopherson@intel.com,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
        Thomas Gleixner <tglx@linutronix.de>, vkuznets@redhat.com,
        wanpengli@tencent.com, "the arch/x86 maintainers" <x86@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 23 Jun 2020 at 11:32, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, Jun 23, 2020 at 12:44:13PM +1000, Stephen Rothwell wrote:
> > Hi Peter,
> >
> > On Mon, 22 Jun 2020 11:49:23 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
>
> > > Hurmph, I though that was cured in GCC >= 8. Marco?
> >
> > So what causes this? Because we got a couple of these in our s390 builds last night as well.
>
> This is KASAN's __no_sanitize_address function attribute. Some GCC
> versions are utterly wrecked when that function attribute is combined
> with inlining. It wants to have matching attributes for the function
> being inlined and function it is inlined into -- hence the function
> attribute mismatch.
>
> > kernel/locking/lockdep.c:805:1: error: inlining failed in call to always_inline 'look_up_lock_class': function attribute mismatch
> > include/linux/debug_locks.h:15:28: error: inlining failed in call to always_inline '__debug_locks_off': function attribute mismatch
> >
> > s390-linux-gcc (GCC) 8.1.0 / GNU ld (GNU Binutils) 2.30
>
> *groan*... So supposedly it was supposed to work on GCC-8 and later, see
> commit 7b861a53e46b6. But now it turns out there's some later versions
> that fail too.
>
> I suppose the next quest is finding a s390 compiler version that works
> and then bumping the version test in the aforementioned commit.

 I'm trying to figure out by inspecting GCC changelogs which version
and which arch is actually good.

Thanks,
-- Marco