Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp6529048rwl; Wed, 22 Mar 2023 11:46:55 -0700 (PDT) X-Google-Smtp-Source: AK7set8uMPJNj83SNsBpHYf7WgUqYtCUIqeKJU8z0r8L02X4oOHTNmEBwlezFC3XMiUjf8hJ40Df X-Received: by 2002:a17:90a:1a50:b0:23a:f4b4:630 with SMTP id 16-20020a17090a1a5000b0023af4b40630mr4702468pjl.23.1679510815298; Wed, 22 Mar 2023 11:46:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679510815; cv=none; d=google.com; s=arc-20160816; b=0NV86uaV0l2YIoU6MV1AHBR8o375AN8hczwmT57/+F/+vrdfcL3CB1Ns1QnUkGbFq5 Mu7gEXNC7EPj82jP+jWjSuhcDyWc3zbYt2fBBME3V21chqkixRw3/M31MmEF19hdVOvz XA3txH3fIZLHF8k1eJc+wvITvd8gsyuhFG/l7LMoFkIFFe9k8pIqU2xxNksCZSNA28WB LhgJMiPFj6BcwcQR0s8EiVV22Uwj5L1NNnWoDGxes9MDihjMr47Nj8OeFjV6YEO6SpXE s6+kMFxADWYv0hkB8ePgVLLQmt5DU0KonJhOC1F3VDrd0Se/hp0ludnz0PvtUqBXhNC8 DR0w== 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=Owe11C9BqEB/iz6W9ls3XMwqRmBbjNWRM4fDGkYFCtk=; b=ttCydx/j2kBK3ogaW6jRQe7VpEwmnnSL1vvrv0HSQ8sWeJKy1LgtAqNXFbgd2Qov+6 V5blrkVvHXy1fJlkc9r+wMi1JtfamBpSbCy+1eNp55vseBPzw+xK6QcOeQgkOHEm57Bz CMZzKEjdi79CBEzrMWl9Rt96EYsNDXz/wvxiHJNRYope+bJP/InsrCHrZ3l4AqLYRceU gvGtAlMWEtysV5uDF5kAhUbESXkGh4fvTtu6boW3oChar0S88J0DLieCgHkV12iOz9hH c3ahlGWIQ737SsS/NLrsp8mmV51TQ+Biz91eEXSYaj5Io2RXFJL2dhHHvj1LaxoIAW1X hwrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=a9XS7Qx3; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ls14-20020a17090b350e00b00230c82c6284si17765261pjb.19.2023.03.22.11.46.43; Wed, 22 Mar 2023 11:46:55 -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=@kernel.org header.s=k20201202 header.b=a9XS7Qx3; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230124AbjCVSqM (ORCPT + 99 others); Wed, 22 Mar 2023 14:46:12 -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> X-Spam-Status: No, score=-5.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS 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 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