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 90F59C001DF for ; Mon, 24 Jul 2023 18:30:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230074AbjGXSag (ORCPT ); Mon, 24 Jul 2023 14:30:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230013AbjGXSa1 (ORCPT ); Mon, 24 Jul 2023 14:30:27 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5CDDF10F4 for ; Mon, 24 Jul 2023 11:30:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DB56F6137C for ; Mon, 24 Jul 2023 18:30:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7ACAFC433CA; Mon, 24 Jul 2023 18:30:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690223424; bh=3OLBTMSOJRIwQEOVOkXhMXAkKS9fIT/wK5Tbk1j9iKc=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=tGePP/KJI1UFlPXqU57Xltzypihz8jeqTQdwaxFF3MzEJeerl8IA6+0Mad2lKzn2n kN1rGG09/F6cbJejkHLgQezYjUB14cJKUuRYmOdZLWQQmr+CCSOR3id1BNZl6Xjlus 3ff7X1R0Hffnj+1v9l9uu/OTeiUaSSrKwyzg0SCtgA0rA9qIk1B2/mFTD8VwfDWzDL 4N1/7bcoBlYHIZE8IARGR3xBf8c7agG7Pny6lF9vF/7aHVe+vWO5iUsS08sRLxQEUM +qOkjlVxSXy4yA1QxESRJsniki0NY2a925ddjSkACtmVDTA2DCYyEVRYREHNv2mQbb ZKueaOaqEAy3w== Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 4CDF227C0054; Mon, 24 Jul 2023 14:30:22 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Mon, 24 Jul 2023 14:30:22 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrheekgdduvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusehkvghrnhgvlhdrohhrgheqnecuggftrf grthhtvghrnheptedtvdehheduhfejuedukeekfefgfedtgeekveeujefhvdfgleeuffeh ueettdegnecuffhomhgrihhnpehgohgusgholhhtrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghrnhguodhmvghsmhhtphgruhht hhhpvghrshhonhgrlhhithihqdduvdekhedujedtvdegqddvkeejtddtvdeigedqrghrnh gupeepkhgvrhhnvghlrdhorhhgsegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i36794607:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 227CCB60089; Mon, 24 Jul 2023 14:30:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-531-gfdfa13a06d-fm-20230703.001-gfdfa13a0 Mime-Version: 1.0 Message-Id: <39444a4e-70da-4d17-a40a-b51e05236d23@app.fastmail.com> In-Reply-To: <679d8d63-ce92-4294-8620-e98c82365b2c@app.fastmail.com> References: <20230722074753.568696-1-arnd@kernel.org> <679d8d63-ce92-4294-8620-e98c82365b2c@app.fastmail.com> Date: Mon, 24 Jul 2023 20:29:59 +0200 From: "Arnd Bergmann" To: "Arnd Bergmann" , "Alexei Starovoitov" Cc: "Yafang Shao" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Hou Tao" , "Martin KaFai Lau" , "Song Liu" , "Yonghong Song" , "John Fastabend" , "KP Singh" , "Stanislav Fomichev" , "Hao Luo" , "Jiri Olsa" , "Kumar Kartikeya Dwivedi" , bpf , LKML Subject: Re: [PATCH] bpf: force inc_active()/dec_active() to be inline functions Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 24, 2023, at 20:13, Arnd Bergmann wrote: >>> One difference between gcc and clang is that gcc tries to >>> be smart about warnings by using information from inlining >>> to produce better warnings, while clang never uses information >>> across function boundaries for generated warnings, so it won't >>> find this one, but also would ignore an unconditional use >>> of the uninitialized variable. >>> >>> >> If we have to change the kernel, what about the change below? >>> > >>> > To workaround the compiler bug we can simply init flag=0 to silence >>> > the warn, but even that is silly. Passing flag=0 into irqrestore is buggy. >>> >>> Maybe inc_active() could return the flags instead of modifying >>> the stack variable? that would also result in slightly better >>> code when it's not inlined. >> >> Which gcc are we talking about here that is so buggy? > > I think I only tried versions 8 through 13 for this one, but > can check others as well. I have a minimized test case at https://godbolt.org/z/hK4ev17fv that shows the problem happening with all versions of gcc (4.1 through 14.0) if I force the dec_active() function to be inline and force inc_active() to be non-inline. With clang, I only see the warning if I turn dec_active() into a macro instead of an inline function. This is the expected behavior in clang. Arnd