Received: by 2002:ab2:6857:0:b0:1ef:ffd0:ce49 with SMTP id l23csp710539lqp; Thu, 21 Mar 2024 13:08:24 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWtb1w9R6L7EATQejc/j7ox5vCb4Trp4K/awDqLHoHGzN0NFgpBxvPqi2U3nuHxZw5ICQspu9O+V8zbux3ZM053OnmYDNFGE4HGg60SUQ== X-Google-Smtp-Source: AGHT+IGt07BUT07JaT0UluiAnZX+iCKDQ/bKLyig8LBgHhHEFvxz/EUF7NFTOL0BBtfzR2Ae6N0M X-Received: by 2002:a17:902:684e:b0:1dd:a03d:8d54 with SMTP id f14-20020a170902684e00b001dda03d8d54mr5713pln.24.1711051704485; Thu, 21 Mar 2024 13:08:24 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711051704; cv=pass; d=google.com; s=arc-20160816; b=fZb6ZRdtfsrFZAsjDlpEM90EHYxdQutop7HX6anZF/fXt/pc0oD14oCOQtkhnFP33g B1kULCypMHddoYv9cgmz6MpM/bShchqBjdjA7/MvVARVl+ms1qdUq3RvkOPW0H8jxd6B FydGDhutAU8/Qpw0q8o87t9udUPLmmQJtublmd1kDUY8MpgndX5LA+rEcqi16N/GrThF iX1qGX2LJZ2MNOb5adOymZLxb5FibaY9W8JW0dX55ZCUJGLZ/7Wcqvj5AoOqWRsHEjFP S1PlfbuYpV2kJgAG34ZIfTu30/VFu5RaTYXvt9u6YxiHbc95wwHvHN1MLwy7SAzHnUA2 EhBw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date; bh=1bPGaFJdg8AFrXyi2gPfNwzRXpHp3P+FGdhTMvQS3lo=; fh=FJ0cdsJlcuc9VGG6gEz1OWgFJV8JMrU7mFuaK8OYBwQ=; b=HOhXMngQ517jXpOY2ShvO6NyjIjTAgGA7mjT/WJX7ME/vDv6CRdPLw5pHRTrZiYxM8 D3m9SfSZFO8FULGuwchqE3L6ohY9CNdXriaALo9EIztTreawm6Zv4pF71NJTwX0Rmihc 4Mfm0y2+rF7a/NhB9dirj05sokeXkF2rS8wf9yLYlhV8Jo6l9gIUkXJCNQigDexbFgZd 0+0TFtyV+2SFWxo+wK62WhS02FuckRNkQWjRqn8LjsoOHm1w1yS8KIMc8bHr19fCdorh VD3v9OSi/dOjkRuutxWyb6TV9EW0wYfj4ly88NvkdYU8czBf4nMCEYCwiU0nBPGBQsbZ fxOw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-110624-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-110624-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id m4-20020a170902db0400b001e02cd75dfcsi368386plx.464.2024.03.21.13.08.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Mar 2024 13:08:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-110624-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-110624-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-110624-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 25582286244 for ; Thu, 21 Mar 2024 20:00:27 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2047113443A; Thu, 21 Mar 2024 20:00:22 +0000 (UTC) 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 9301F13442D; Thu, 21 Mar 2024 20:00:21 +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=1711051221; cv=none; b=q42QORF/wlBoIDnmXFS61tWX/j4eMzGra9ChkqmvAPvBaWKWwBD0elS9efmqoUPCAaN2wjJ50vA/7ehYWRqLK95AcEQr9JWwhT94HqlQx7JaTd71X++vJwI56HP/UM8GWM6mTIihh8p4ZEoz+6jfcxyOkPpuuwJ9DOofLfX4e+4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711051221; c=relaxed/simple; bh=CtdoVQnUUB1yzk4xQkmuGvVDOzJhQ5TBfb/YgqcA5hk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VElpFQL2kbp6IJFTEPVw3ggQoYhVY+Hl4jfJy4MVtaXPu+rYqOZNnrtHw4zp8wXUNXCoslDjdH+BREjdnpLPngNkKJtLACcGWjXUDTudDu7jK3l2SUxQfhmef/oUySABPjjsySobgxXUJzgv7ohSnJDc9JIiIQIiwEV0D5hX4vA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1219CC433C7; Thu, 21 Mar 2024 20:00:18 +0000 (UTC) Date: Thu, 21 Mar 2024 16:02:46 -0400 From: Steven Rostedt To: Mark Rutland Cc: "Bj\"orn T\"opel" , Puranjay Mohan , Paul Walmsley , Palmer Dabbelt , Albert Ou , Masami Hiramatsu , Sami Tolvanen , Guo Ren , Ley Foon Tan , Deepak Gupta , Sia Jee Heng , "Bj\"orn T\"opel" , Song Shuai , Cl'ement L'eger , Al Viro , Jisheng Zhang , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Subject: Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS Message-ID: <20240321160246.2e28cf9d@gandalf.local.home> In-Reply-To: References: <20240306165904.108141-1-puranjay12@gmail.com> <87ttlhdeqb.fsf@all.your.base.are.belong.to.us> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 12 Mar 2024 13:42:28 +0000 Mark Rutland wrote: > There are ways around that, but they're complicated and/or expensive, e.g. > > * Use a sequence of multiple patches, starting with replacing the JALR with an > exception-generating instruction with a fixup handler, which is sort-of what > x86 does with UD2. This may require multiple passes with > synchronize_rcu_tasks() to make sure all threads have seen the latest > instructions, and that cannot be done under stop_machine(), so if you need > stop_machine() for CMODx reasons, you may need to use that several times with > intervening calls to synchronize_rcu_tasks(). Just for clarification. x86 doesn't use UD2 for updating the call sites. It uses the breakpoint (0xcc) operation. This is because x86 instructions are not a fixed size and can cross cache boundaries, making updates to text sections dangerous as another CPU may get half the old instruction and half the new one! Thus, when we have: 0f 1f 44 00 00 nop and want to convert it to: e8 e7 57 07 00 call ftrace_caller We have to first add a breakpoint: cc 17 44 00 00 Send an IPI to all CPUs so that they see the breakpoint (IPI is equivalent to a memory barrier). We have a ftrace breakpoint handler that will look at the function that the breakpoint happened on. If it was a nop, it will just skip over the rest of the instruction, and return from the break point handler just after the "cc 17 44 00 00". If it's supposed to be a function, it will push the return to after the instruction onto the stack, and return from the break point handler to ftrace_caller. (Although things changed a little since this update is now handled by text_poke_bp_batch()). Then it changes the rest of the instruction: cc e7 57 07 00 Sends out another IPI to all CPUs and removes the break point with the new instruction op. e8 e7 57 07 00 and now all the callers of this function will call the ftrace_caller. -- Steve