Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp29112905rwd; Wed, 5 Jul 2023 07:22:32 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5C6Xkj0tzhIGus0xg0mMXJy+iAMkgPagpAjeqGqNodt3vyVrh3Qmswy+Cv1RhtUGUyxjlB X-Received: by 2002:a05:6830:1401:b0:6b8:7f0f:178e with SMTP id v1-20020a056830140100b006b87f0f178emr16831513otp.25.1688566951848; Wed, 05 Jul 2023 07:22:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688566951; cv=none; d=google.com; s=arc-20160816; b=ogUyRWBl841J/4Sm6gKSX2Plb/WJFCIcVl510W966YtJ++/DfCyTwrE/8+qDG9YrJg eoG4ZXN/TPosR4neiB4lKi5cwNGN7JzE/JUbcw3Onx8XBs6pCj5sy5XSzReIHdAxJXdM phHyKF/FHaJ3kZgbT9QfXmAdtYvhMCJpaIhdItdDlwMnHBnFGfkITm+LWhLtyHedLcPd oOUBJ3LQ5mdpuXjMSln1ugqowhadFgB6f/hJYuC7YlYSQmMiJp0N2tktbesBA5eKdN9/ FGqJj+t0I51KRI20atx7Q5Mktgrp8Fd9ejw5Gc5NkcuDTpAdIfWAq2pku2GcpeWo3ywJ KVUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=eVc8iKYrMXfjfbA9+JVbcFGJzCNb0srp0yOJi6I3Ooo=; fh=lidvpITdK5Igp075HLN1uabAv/y9HvK2CFNVdo2H5ck=; b=pYUC9qCwPRy2KTMIo+839N7dNWvnM1Z12mU2a75Hm3hSDmVu3tUkf38zWmKPMpDxD+ Retil9pU5KNzkwcUGOgbYncJEBrQOMYRt/wEOuFJU3SF8AjOk/gm1OBwA2x/WFV/vCFb nMd2vhsJTx3f+O2NEpC4C/+/W1nG6ofBmXP3Ds0uXNp904u0RyF3F7ClGvnVzwSfbIrK I/O5PoI9gcmX/6sWffTcTwk5MYUNaWy/gHSvHVQsy0LrgGF7lM3yKFnw0kvLRKQRiwsK dDovzYjDgczk82Nubtzl4oKMmCRLR4vvZPt6X5vqilu9D4rw8H35nXFkoO9YiWrgJD33 U8Ig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=fYyYlYX+; 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 m129-20020a632687000000b005537e4e7d59si23409466pgm.84.2023.07.05.07.22.18; Wed, 05 Jul 2023 07:22:31 -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=fYyYlYX+; 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 S232362AbjGEOU5 (ORCPT + 99 others); Wed, 5 Jul 2023 10:20:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231147AbjGEOUq (ORCPT ); Wed, 5 Jul 2023 10:20:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05881CF; Wed, 5 Jul 2023 07:20:46 -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 95042615A6; Wed, 5 Jul 2023 14:20:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 752BBC433C7; Wed, 5 Jul 2023 14:20:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688566845; bh=z/CWJ9bb+yjQolWWLOC4JS5f8lXSCPfPpbPQ2Xusczw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fYyYlYX+ZurP+YqyF3nn8q/OALGRjoa/2YbS0Ya0oyx2qNLvupJ9zrJhwsGH4xwD6 xavynTTYB/Ye4ptn8ajOPB7CItdKdx+gQF145LaxWDuceF+ezFun8iC+anudzrRLNx B5WGYNJZ4s/WOo9NcwmDk7vkLOIYmgtkwkGCvDtcQUnG++/fKMlA+E1egMWPjoSet1 Ig31CopoGO+b/KNyBlRe9VJ0WM0hFB2OJ8F519nXFHtwIUcepNTexkcxwH7XqvOWFy Nk14jAxvu1YYbdDFQ3P+pKu3lDzNpWAp9DY+0WUtmbO4gTyp3Bf6Cnbs/dXJxTvBxR 26lkyE2SfbJ2w== Date: Wed, 5 Jul 2023 23:20:38 +0900 From: Masami Hiramatsu (Google) To: Peter Zijlstra Cc: Petr Pavlu , tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mhiramat@kernel.org, samitolvanen@google.com, x86@kernel.org, linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] x86/retpoline,kprobes: Avoid treating rethunk as an indirect jump Message-Id: <20230705232038.3a6d03e18f7bafb14cdfed42@kernel.org> In-Reply-To: <20230705085857.GG462772@hirez.programming.kicks-ass.net> References: <20230705081547.25130-1-petr.pavlu@suse.com> <20230705081547.25130-3-petr.pavlu@suse.com> <20230705085857.GG462772@hirez.programming.kicks-ass.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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, 5 Jul 2023 10:58:57 +0200 Peter Zijlstra wrote: > On Wed, Jul 05, 2023 at 10:15:47AM +0200, Petr Pavlu wrote: > > Functions can_optimize() and insn_is_indirect_jump() consider jumps to > > the range [__indirect_thunk_start, __indirect_thunk_end] as indirect > > jumps and prevent use of optprobes in functions containing them. > > Why ?!? I mean, doing an opt-probe of an indirect jump/call instruction > itself doesn't really make sense and I can see why you'd want to not do > that. But why disallow an opt-probe if there's one in the function as a > whole, but not the probe target? Here we need to clarify the reason why functions which have indirect jumps are not allowed to use opt-probe. Since optprobe can replace multiple instructions with a jump, if any jmp (is used for jump inside same function) jumps to the second and subsequent instructions replaced by optprobe's jump, that target instruction can not be optimized. The problem of indirect jump (which jumps to the same function) is that we don't know which addresses will be the target of the indirect jump. So, for safety, I disallow optprobe for such function. In that case, normal kprobe is used because it replaces only one instruction. If I understand correctly, all indirect jump will be replaced with JMP_NOSPEC. If you read the insn_jump_into_range, I onlu jecks the jump code, not call. So the functions only have indirect call still allow optprobe. Thank you, -- Masami Hiramatsu (Google)