From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F9C0CCA47C for ; Fri, 15 Jul 2022 14:04:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235123AbiGOOET (ORCPT ); Fri, 15 Jul 2022 10:04:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235384AbiGOOED (ORCPT ); Fri, 15 Jul 2022 10:04:03 -0400 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4AB3A1085; Fri, 15 Jul 2022 07:03:58 -0700 (PDT) Received: from zn.tnic (p200300ea972976d6329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9729:76d6:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 4D6FE1EC0230; Fri, 15 Jul 2022 16:03:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1657893833; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=QbGEmJveh3meLgmCPkkX0DKI0iC+qcLBcQMOHTKMAeA=; b=LB2MDoPtY6niEMtL5F7KecDtH4G0UZgkeTflXgMMlmXzw5ldpKCVemI9gqTPo5AbSxg4EW neTaQrJ9rtBNWQfLpqiya0QbagUNun22n4H4xbVnGw/H+WnaqfWZRgp/+bLcfLXcAu155u ALgPcfTW5UMjfnkyTyX7SUoHin+yrs0= Date: Fri, 15 Jul 2022 16:03:47 +0200 From: Borislav Petkov To: Linus Torvalds Cc: Guenter Roeck , Peter Zijlstra , Thadeu Lima de Souza Cascardo , Naresh Kamboju , Greg Kroah-Hartman , kvm list , Linux Kernel Mailing List , stable , Andrew Morton , Shuah Khan , patches@kernelci.org, lkft-triage@lists.linaro.org, Pavel Machek , Jon Hunter , Florian Fainelli , Sudip Mukherjee , Slade Watkins , Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Dave Hansen , X86 ML , "H. Peter Anvin" , Alex =?utf-8?Q?Benn=C3=A9e?= , Anders Roxell Subject: Re: [PATCH 5.15 00/78] 5.15.55-rc1 review Message-ID: References: <20220712183238.844813653@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 14, 2022 at 01:39:25PM -0700, Linus Torvalds wrote: > On Thu, Jul 14, 2022 at 10:02 AM Borislav Petkov wrote: > > > > On Thu, Jul 14, 2022 at 09:51:40AM -0700, Linus Torvalds wrote: > > > Oh, absolutely. Doing an -rc7 is normal. > > > > Good. I'm gathering all the fallout fixes and will send them to you on > > Sunday, if nothing unexpected happens. > > Btw, I assume that includes the clang fix for the > x86_spec_ctrl_current section attribute. Yap. Here's the current lineup: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/urgent > That's kind of personally embarrassing that it slipped through: I do > all my normal test builds that I actually *boot* with clang. > > But since I kept all of the embargoed stuff outside my normal trees, > it also meant that the test builds I did didn't have my "this is my > clang tree" stuff in it. > > And so I - like apparently everybody else - only did those builds with gcc. > > And gcc for some reason doesn't care about this whole "you redeclared > that variable with a different attribute" thing. ... so why does clang care? Or, why doesn't gcc care? I guess I need to talk to gcc folks again. > In the 'x86_spec_ctrl_current' case, that nonsensical code _worked_ > (with gcc), because despite the declaration being for a regular > variable, the actual definition was in the proper segment. I'm guessing this is the reason why gcc doesn't fail - it probably looks at the declaration but doesn't care too much about it. And it is the definition that matters. While clang goes, uh, ah, declaration and definition mismatch, I better warn. > But that 'myvariable' thing above does end up being another example of > how we are clearly missing some type checkng in this area. > > I'm not sure if there's any way to get that section mismatch at > compile-time at all. Well, apparently, clang can: arch/x86/kernel/cpu/bugs.c:58:21: error: section attribute is specified on redeclared variable [-Werror,-Wsection] so there's a -Wsection warning which gcc could implement too. > For the static declarations, we could just make DECLARE_PER_CPU() add > some prefix/postfix to the name (and obviously then do it at use time > too). > > We have that '__pcpu_scope_##name' thing to make sure of globally > unique naming due to the whole weak type thing. I wonder if we could > do something similar to verify that "yes, this has been declared as a > percpu variable" at use time? But how? We need to save the info how a var has been declared and then use that info at access time. Yeah, lemme bother compiler guys a bit... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette