Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1668611rwb; Sat, 19 Nov 2022 01:01:59 -0800 (PST) X-Google-Smtp-Source: AA0mqf6VF7dMUxDwkzATGUhCGuwzIehfVbbnKvL3JxSUNl2nalWNklFc6V0YyIVpNyTMHQzVU9EB X-Received: by 2002:a17:906:5583:b0:78d:b3ef:656c with SMTP id y3-20020a170906558300b0078db3ef656cmr8201070ejp.627.1668848519582; Sat, 19 Nov 2022 01:01:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668848519; cv=none; d=google.com; s=arc-20160816; b=ig7mAVmBxyP9O+wQ4FuU0o274XuyIh2tX57nQ7VD5zsc9KhY3GEj3KEEISxi9i9R7o wClDifnvuCObfBWkfdwClHOF+cRkObJTblF4V63n7KKVV1kyyDFCAJv8WWayNtL0liBR ySnp5A7CF1y4lYgdXaQSR7LoYpjGoefL28EmxHfI5FoUSbJDU62cGdOr3YtThomqSMU1 MQlC32/nv0T02FW95A8Cqhs5FDMDApAzUx/0OBtXP5jHkyngGF4OzPMBZr7BURRykMzF nRI0K8Y3auo9EKuUp6NS+jgW7D9/Tc7g4wspuHwWILqrU0TAr4VNgcHZ5/7nht0mQ+PO H3Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=X7W84tVgmtzXWiGK1DtDy7dpFwth4iJrGxPevoDqGpw=; b=xknGMXSrfydIimMzY9iOVBXU5FxJqPRLdmABQPXLpSOiqm18JySs3H18W+KjzCz3Ty YPe5LZnWeOht3jwWbxf6kDkT4zJNv2FFGZasVXN+ltYN6VIDClRs4vzPQcazzO3SqlNB 9k6ANOnDIUH00IOSwqXvSFhCGzDSIZSR4c+SNNX58k9Yrx79LUptRpeKcC6soifNLjkb EFl293cRndGUsSmadAplJOtFTfgLuafYJ7hiy3WYYYD0qHZLCUDFu5K2046s1inOt0zD lVgsWhKSAObx4E42DBcFc1j32DNCk5A13nXc391MJMlUoZcojiBP56Z4QagsKSPma5up vBOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=Xx1f4uRy; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=cqWvKFwb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q28-20020a056402249c00b00463f8aad371si4872655eda.239.2022.11.19.01.01.34; Sat, 19 Nov 2022 01:01:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=Xx1f4uRy; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=cqWvKFwb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233351AbiKSIu6 (ORCPT + 90 others); Sat, 19 Nov 2022 03:50:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56046 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229470AbiKSIu4 (ORCPT ); Sat, 19 Nov 2022 03:50:56 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C07B31F82 for ; Sat, 19 Nov 2022 00:50:55 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1668847852; 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: in-reply-to:in-reply-to:references:references; bh=X7W84tVgmtzXWiGK1DtDy7dpFwth4iJrGxPevoDqGpw=; b=Xx1f4uRy1Ki7vMWW3NWJH4pM3kSMr4FxHTLvMJ5sHj3wnaty076HOrkgf2+PHzvhqQt7zY /36ypbmp20ebfx3Y/AaadCtsdM7Ev2HRtF3NT13y7A9W5xTjdueYgRXK7CwBigW3hmRQYx 0G2EKIgiusw+4cPmG2jjHtUqDM1MO6LwzXpxgRCH+RVKdDspR9nAxRF0mSqpO2+S68iczJ odwtw54V1+UXef0lNzlEirDNmPaRKUv8QExFZ8RUjtrGRi3ctq3cbn0RTuI408+sEiL2Xe +R8kDns/dVMkgovAZbmRYFig6KC3O+KoEE4Yz7GyfJIdXyq0fF8M/11gjtVgaA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1668847852; 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: in-reply-to:in-reply-to:references:references; bh=X7W84tVgmtzXWiGK1DtDy7dpFwth4iJrGxPevoDqGpw=; b=cqWvKFwb09ATPLFiGF7iHH3p1Wb3mGtd6lzQGEYsGNvJCawcuN8d9mDjdLAFWnhY721AZb 5JoXprhyllrb4YCw== To: Andi Kleen , Peter Zijlstra Cc: "Jiri Slaby (SUSE)" , linux-kernel@vger.kernel.org, Andy Lutomirski , Martin Liska , Jiri Slaby Subject: Re: [PATCH 18/46] entry, lto: Mark raw_irqentry_exit_cond_resched() as __visible In-Reply-To: <8d055277-1f55-fc93-87cb-7a8f0d8d2839@linux.intel.com> References: <20221114114344.18650-1-jirislaby@kernel.org> <20221114114344.18650-19-jirislaby@kernel.org> <87a64qo4th.ffs@tglx> <289e03d2-be50-4249-343a-75dae302b0e5@linux.intel.com> <8735ahkq55.ffs@tglx> <8d055277-1f55-fc93-87cb-7a8f0d8d2839@linux.intel.com> Date: Sat, 19 Nov 2022 09:50:52 +0100 Message-ID: <87v8nbiaz7.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 18 2022 at 16:50, Andi Kleen wrote: >> Sure, they can play around with it but that does not require to merge >> all this nonsensical ballast for a half thought out compiler. > > You are referring to __visible? > > TBH I don't understand the problem. In general __visible is useful > documentation, so you know something is used from assembler or other > strange contexts. Doing such things explicitly marked instead of > implicitly hidden and they just happen to work by accident > seems cleaner to me. Seems cleaner is really not a technical argument. Visible is completely useless. Either a symbol is global and therefore reachable from any point in the final "executable" or it's not. Whether that reference is in assembly or from a pointer, static key or whatever does not matter at all. There is no such thing as a 'strange context'. Nothing works here by accident. A global symbol is a global symbol whether it's defined or referenced from C or from ASM or from any other programming language does not matter at all. > I can also see the __visible markings being useful for other purposes, > e.g. static analysis tools or dynamic instrumentation like the various > sanitizers. Everything that is referenced outside the normal code that > the compiler sees may need some special handling. All you have is 'may need' and 'I can see'. Where is the actual use case? >> If they want to do that they can apply the pile of patches as provided >> and play around. > > It's very difficult to maintain out of tree, while in tree it's much > simpler. Sure. Lots of things are simpler to maintain in tree, but that's not an argument for merging anything. > I think Linux should support its primary compiler well and not give up > due to relatively small obstacles. It's not an obstacle. It's a fundamental broken model. clang has proven that it can be done proper, so there is no reason to proliferate the inferior. While you might consider gcc to be the primary compiler, that might have been true a decade ago. A lot of people prefer clang as their primary compiler simply because its saner and the maintainers behind it are working with us and not trying to inflict their half baken crap on us to spare themself the work to do it right. Thanks, tglx