Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp6263697rwl; Wed, 22 Mar 2023 08:25:50 -0700 (PDT) X-Google-Smtp-Source: AK7set8av7218bK4F7NXpUmJ+/JcaINqeoNtDSxO1ADU+DEANz4gCAvsxLCV7fUhB9fQ5hjYHfwr X-Received: by 2002:a62:1a52:0:b0:625:975f:525d with SMTP id a79-20020a621a52000000b00625975f525dmr3478408pfa.28.1679498749628; Wed, 22 Mar 2023 08:25:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679498749; cv=none; d=google.com; s=arc-20160816; b=cSBW9W84i+3qkwpPw/KknwuXW/ckwb9WhB3vdYPrhH9xCFG0SsaOajuk4FfRVWuxSP p8sKcjNcHvtFbWJHxTo0COVCySZpemGhjQQTdO9kgI47RYontzXV7x13nDaYHGagYBa1 +cNiVh0c+aObmxHAQoca11rjpOP8A6fDDX+LMriG1Ima1qzvqS1zaLvtHUuiWrfp53TC 5S6vMI3klGY53REfrZ2lNOhgGMKC+ZZHxsxdX2Jy12pQ/mBlN5AqNR8yus+I36dHUhyC IeOWhLAbvx74ofKkHWk6N8K9YRhKQiFjnwsrC2Vu+QR8Tx5dEreRPNAlUvou0PHFNVTh sApQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Oo95ksNo438JOehySiTYm2xvtjpxki70aoJy1x654ic=; b=SA5g+IKS0h41TqBaepO1UztTva2wFepmhVPdrY+o7qTdHE1OvGEMLUCANKfncaSdTn tp1SjlfdysOQIyo+S7xf+Evzf8B4ZnARsV7knLx+n6LoI7nFMzdDJ53h8onPwetXOvsV +tKlVzxDDakR9+CYdiYvYuNXA4CqmZyFrjjd8iTYvGn8h9JoF076zQE4+ir+xPyFdDrq G5C7fXtHccNn/GQIUcSLGjmrgyTwiYSulqHbE/+KVhvzuID2viGMZeG4Uoc5aHDsXwYa TYL6LU8SNWGPdUGTRj/DujTiTGUkdDJ+bTv6IFlGdQTnGaCh2HoiwG5soFxwAGtSrAwK OQdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=AmZ2yrsZ; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z1-20020a655a41000000b004da377c33bbsi16896521pgs.85.2023.03.22.08.25.37; Wed, 22 Mar 2023 08:25:49 -0700 (PDT) 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=@infradead.org header.s=casper.20170209 header.b=AmZ2yrsZ; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230397AbjCVPPw (ORCPT + 99 others); Wed, 22 Mar 2023 11:15:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229589AbjCVPPv (ORCPT ); Wed, 22 Mar 2023 11:15:51 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 938995FA7E for ; Wed, 22 Mar 2023 08:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Oo95ksNo438JOehySiTYm2xvtjpxki70aoJy1x654ic=; b=AmZ2yrsZzD4hIqyo5kv7jGnakK Xp5HymcULYHKiPmU0NelZiXniuv5bFpGR4XawrJ9sicQHGWK8yJCFBqUzgBSY/VQtud4N1DN87+KC c7pFK8A2II1Hy5hc2crVFOA5N7MCOp5rAIYa90s0SQ7AY8EXjL0hhDQc/gXoq9tiv/K9baikGBPuv tdWmywNXyOa5NgV+l9hSZzN+DLj+qPo6+FCxVGRHhNucOHc+/gY86qQAlEH8bmbuJkIW+4qve6g/o iIO3PraeOxVCPa+EqiGS2TzqFHBGsT2QddsWck3WlnOr5TUuy1ZDh5l3SATp28cz6IY8w6zsEqqEg VX7N1KXA==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1pf0Bb-0036gM-8p; Wed, 22 Mar 2023 15:15:35 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 6D005300379; Wed, 22 Mar 2023 16:15:32 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 33289201FFA49; Wed, 22 Mar 2023 16:15:32 +0100 (CET) Date: Wed, 22 Mar 2023 16:15:32 +0100 From: Peter Zijlstra To: Josh Poimboeuf 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: <20230322151532.GG2357380@hirez.programming.kicks-ass.net> References: <8aab02492c2bf512c7ffe458e41acc1b930ed2dc.1679456900.git.jpoimboe@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8aab02492c2bf512c7ffe458e41acc1b930ed2dc.1679456900.git.jpoimboe@kernel.org> X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE, URIBL_BLOCKED autolearn=unavailable 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 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. > 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.