From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB9BA1862A; Sun, 13 Apr 2025 19:43:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744573395; cv=none; b=kjzHsBqsg+mF2ceeKBtQG6xJND3XuZM4m4CyCVPlFTirAFHj4wVcBovOGhgtQRewOJlDoQxSbWSUWeVY5eAa63VtC75+Fp6AvnyFtIS3MOH+Ht0erwdXD1+vUxyjfFS/eFEKjdaWDdqlICCnz3f51oZ3ucquyFv30erv+mmtmAw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744573395; c=relaxed/simple; bh=oEqBz1Ey1X/q0WGJonnMdNetp5YCj0ml3zi7CP04Qqg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VzjAYEjhqWQbz5HypcTwgbEZO1+NVEUrFAYSphCy8vQMAxhnXKtivVnrdo25Gy9ZFNRBJZwBSMRGe1+GbZ4GxO4vATkaD+0rhuX23eCHH366wqu3C2wePwGelB5gufR1VZ/XAInrZ/A5A/VHJBVtpWzfO4JWBmmSzhJ5g+C69/A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=shydVDea; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="shydVDea" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6CBEC4CEDD; Sun, 13 Apr 2025 19:43:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744573394; bh=oEqBz1Ey1X/q0WGJonnMdNetp5YCj0ml3zi7CP04Qqg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=shydVDeaFK8H13Clx2kwH3TURm4XlXWO23IOtUF47I2rv8GNKRgDCTuCuXpnzmmsf /yvlUdNmL5W90yTzkR5ARQNK6QOmY8CNGMVBhBkdNYL4rNHfJAdq4BfhGXhJ4MxXiJ ZFwmbNtYi/tKif2KXhS+xmW3EqVibEL5tvtypO5Dn9tTqV1I/AMhyl9xr3MxMT+4Sx G55Y85BWIWrIh3th2wScx4HMcsL6XlHVgT4va2XR5P3B4KKBDvcrhYW//ZAceEQ6ox m27jgf55dV+x8Jk5kxZcquV/n7rNww6SjLNq9wbp3pueWDGvaBG5e+5aU/roTOJo+E iRF/DedZDaXFQ== Date: Sun, 13 Apr 2025 21:43:09 +0200 From: Ingo Molnar To: Uros Bizjak Cc: Thomas Gleixner , Linus Torvalds , Borislav Petkov , Andrew Morton , linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org, Paul Menzel , x86@kernel.org Subject: Re: [tip: core/urgent] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined Message-ID: References: <174428272631.31282.1484467383146370221.tip-bot2@tip-bot2> <20250411210815.GAZ_mEv8riLWzvERYY@renoirsky.local> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: * Uros Bizjak wrote: > On Sun, Apr 13, 2025 at 9:20 PM Ingo Molnar wrote: > > > > > > * Uros Bizjak wrote: > > > > > > > If this commit is removed, [...] > > > > > > > > I did not remove commit ac053946f5c4, it's already upstream. Nor > > > > did I advocate for it to be reverted - I'd like it to be fixed. So > > > > you are barking up the wrong tree. > > > > > > If the intention is to pass my proposed workaround via Andrew's tree, > > > then I'm happy to bark up the wrong tree, but from the referred > > > message trail, I didn't get the clear decision about the patch, and > > > neither am sure which patch "brown paper bag bug" refers to. > > > > It's up to akpm (he merged your original patch that regressed), but I > > think scripts/genksyms/ should be fixed instead of worked around - > > which is why I zapped the workaround. > > As said earlier, I have tried to fix genksyms, but the simple fix was > not enough. The correct fix would be somehow more involved, and I > have zero experience in genksyms source. I'm afraid I don't know this > source well enough to offer a fix in the foreseeable future, so I > resorted to the workaround (which at the end of the day is as > effective as the real fix). I disagree that hacks/workarounds are as effective as the real fix. In the Linux kernel the usual principle is that developers who introduce unanticipated in-tree regressions are expected to fix them for real and not just work them around. Not following that principle may have reputational costs going forward (or not), but it's your time and your call really. Thanks, Ingo