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 45294C76195 for ; Wed, 22 Mar 2023 18:46:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230356AbjCVSqN (ORCPT ); Wed, 22 Mar 2023 14:46:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34714 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231195AbjCVSqD (ORCPT ); Wed, 22 Mar 2023 14:46:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4563064B31 for ; Wed, 22 Mar 2023 11:45:51 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C3B0462278 for ; Wed, 22 Mar 2023 18:45:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9170CC433D2; Wed, 22 Mar 2023 18:45:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679510721; bh=khs4WyDC4bsNM7Qsr87hszfKJX33A8kySjsYmIbzpXM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=a9XS7Qx3zeZfbNZaT5WGwlM40Nj0P9NYG6/733ExbmB/MS4s+3NqHG3zxQNtSGZWM SVIzSNUx1JY3TMrTnuSPZ1HUsba2yl/4lCBN2ePGX66NBzG4DMBWHJM4ZnzIqY1Y4/ 4BPx1C10Anj5BXuhobKb0xRuZ7ZU0Y7Be2x1bhILDULUtkVZnglz9Cw4VGIf0KCIj5 2b5dAIqg+pf0T3t/RLLZFqR8m0YJDp8EG1m+gifKIGsz2XZtdQLSf4pl2bzY1W+6Ti TLeqB5nzueurRfctBX+aaWRmGu87yJuzUBLe+r1m94t1XQOTKmD1O4cwME69FDo72B ZAkG5Epf0lldQ== Date: Wed, 22 Mar 2023 11:45:18 -0700 From: Josh Poimboeuf To: Peter Zijlstra Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Mark Rutland , Jason Baron , Steven Rostedt , Ard Biesheuvel , Christophe Leroy , Paolo Bonzini , Sean Christopherson , Sami Tolvanen , Nick Desaulniers , Will McVicker , Kees Cook , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 11/11] static_call: Remove DEFINE_STATIC_CALL_RET0() Message-ID: <20230322184518.wjgfp7dyxvg5la5p@treble> References: <8aab02492c2bf512c7ffe458e41acc1b930ed2dc.1679456900.git.jpoimboe@kernel.org> <20230322151532.GG2357380@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230322151532.GG2357380@hirez.programming.kicks-ass.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 22, 2023 at 04:15:32PM +0100, Peter Zijlstra wrote: > On Tue, Mar 21, 2023 at 09:00:17PM -0700, Josh Poimboeuf wrote: > > NULL and RET0 static calls are both slightly different ways of nopping a > > static call. A not-insignificant amount of code and complexity is spent > > maintaining them separately. It's also somewhat tricky for the user who > > has to try to remember to use the correct one for the given function > > type. > > Well, I have very little sympathy for that argument. The return type > should be a big frigging clue. > > > Simplify things all around by just combining them, such that NULL static > > calls always return 0. > > > > While it doesn't necessarily make sense for void-return functions to > > return 0, it's pretty much harmless. The return value register is > > already callee-clobbered, and an extra "xor %eax, %eax" shouldn't affect > > performance (knock on wood). > > Urgh.. OTOH I do like the lines removes. So this patch is more of an RFC than the others. I'm not fully convinced myself, but I very much liked the removed lines and simpler interface. > > This "do nothing return 0" default should work for the vast majority of > > NULL cases. Otherwise it can be easily overridden with a user-specified > > function which panics or returns 0xdeadbeef or does whatever one wants. > > > > This simplifies the static call code and also tends to help simplify > > users' code as well. > > Can we at least keep the DEFINE_STATIC_CALL_RET0() and > __static_call_return0 as aliases? It reads really daft to use _NULL or > __static_call_nop for non-void functions. I disagree, to me NULL means "nop the function (including any return value)". Nice and easy. Keeping those other ret0 defines around would negate some of the cool deletions. -- Josh