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 491BCC83F12 for ; Tue, 29 Aug 2023 18:55:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238540AbjH2SzJ (ORCPT ); Tue, 29 Aug 2023 14:55:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238602AbjH2Sy7 (ORCPT ); Tue, 29 Aug 2023 14:54:59 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2667719A for ; Tue, 29 Aug 2023 11:54:56 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-99bf8e5ab39so626037066b.2 for ; Tue, 29 Aug 2023 11:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693335294; x=1693940094; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=7rkeLzlKLJm6uIQxs6qrmHZPlBWb8A/YK44W7thpWJg=; b=Q6SSiEaCrCkveJreuDnQ2goaa7FhBqB8eCiRKCGytyRoe1AQaSX/9r06XagFo7RffS yobhr3xSrN3Cv32B4w0M9rzuiZ70qTqmC+fM3sGRMETsTMPLEUfwcqkuKAU6NHAGk7OU R3wJuKLczA9Wz2ZVEwLcymk7BJQIKugtPaeIgEmTKbfMdoGq06run9f/+B7RxpVLPp/t NxtsWVAh294H/o+XsBFU3dfZSm1mErvi4VKIPWuB6DpyLHi9evttCzrW5OUdvojTb0Jf sP3mBl3F4b+aUQGn+sqb8grhjMfQdhkAJSYDtvf1MAyYoxPT9pt5HPMwF5UdPCa9fMqf 1A9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693335294; x=1693940094; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7rkeLzlKLJm6uIQxs6qrmHZPlBWb8A/YK44W7thpWJg=; b=gpK8y9tjHpiWwnwspCcnl7+3ckZO0uaR76sOduAKpE6uOZ3ogiABBF5uArgPlERL4Q YgIimiCCqVkg3wjuuR98UZWQ/Ybb5G4QMF+9oMeZkMPLNJC0ynS3BVRnv7CkCHBe2hp3 jheE9JEd5uW/jxc/jL4t78Qo4d1JFnVYVkAJ56bFqpmWGh8+9fO7sj2EkYOoBuempAyf nlvoWI7kcrQNEYvJJ41iFtmqaqcFQj/9FFUlRQDs9RcTEadcKuDMuz03Lso7cNlOtp+c E/cqaUcXmhuZnMJ5jMgfRq3nj4D08cwBRXnBeG0DbIUP5eRS+sGQFUCtR5ZZbrdF6FP2 MxoQ== X-Gm-Message-State: AOJu0YzhEaiGQ6eBoZsKR41x+UrcnJqyU+x7eOssvoM7RDugEptcbVnr 8qnbMcD1MDm+cQ00EgDEO7mX2e8vAkQ= X-Google-Smtp-Source: AGHT+IFcqzFt/WzR0tUdIWAOMjVgkWSBdToB/3XihxPZP5cmyTOr+ZsfKHhhDnE69wepr3vSv8v/Hg== X-Received: by 2002:a17:906:cc52:b0:9a2:139:f466 with SMTP id mm18-20020a170906cc5200b009a20139f466mr12104379ejb.13.1693335294289; Tue, 29 Aug 2023 11:54:54 -0700 (PDT) Received: from nam-dell (ip-217-105-46-58.ip.prioritytelecom.net. [217.105.46.58]) by smtp.gmail.com with ESMTPSA id kb12-20020a1709070f8c00b0099297782aa9sm6195916ejc.49.2023.08.29.11.54.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Aug 2023 11:54:53 -0700 (PDT) Date: Tue, 29 Aug 2023 20:54:52 +0200 From: Nam Cao To: =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, guoren@kernel.org Subject: Re: [PATCH] riscv: provide riscv-specific is_trap_insn() Message-ID: References: <20230827205641.46836-1-namcaov@gmail.com> <874jkjl4e1.fsf@all.your.base.are.belong.to.us> <87edjmz864.fsf@all.your.base.are.belong.to.us> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87edjmz864.fsf@all.your.base.are.belong.to.us> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 29, 2023 at 08:14:59AM +0200, Björn Töpel wrote: > Nam Cao writes: > > > On Mon, Aug 28, 2023 at 03:31:15PM +0200, Nam Cao wrote: > >> On Mon, Aug 28, 2023 at 02:48:06PM +0200, Björn Töpel wrote: > >> > Nam Cao writes: > >> > > >> > > uprobes expects is_trap_insn() to return true for any trap instructions, > >> > > not just the one used for installing uprobe. The current default > >> > > implementation only returns true for 16-bit c.ebreak if C extension is > >> > > enabled. This can confuse uprobes if a 32-bit ebreak generates a trap > >> > > exception from userspace: uprobes asks is_trap_insn() who says there is no > >> > > trap, so uprobes assume a probe was there before but has been removed, and > >> > > return to the trap instruction. This cause an infinite loop of entering > >> > > and exiting trap handler. > >> > > > >> > > Instead of using the default implementation, implement this function > >> > > speficially for riscv which checks for both ebreak and c.ebreak. > >> > > >> > I took this for a spin, and it indeed fixes this new hang! Nice! > >> > >> Great! Thanks for testing it. > >> > >> > However, when I tried setting an uprobe on the ebreak instruction > >> > (offset 0x118) from your example [1], the probe does not show up in the > >> > trace buffer. > >> > > >> > Any ideas? > >> > >> >From my understanding, both uprobes and kprobes refuse to install break points > >> into existing trap instructions. Otherwise, we may conflict with something else > >> that is also using trap instructions. > > > > I just realize you probably ask this because uprobe can still be installed before > > applying the patch. But I think that is another bug that my patch also > > accidentally fix: uprobes should not install breakpoint into ebreak instructions, > > but it incorrectly does so because it does not even know about the existence of > > 32-bit ebreak. > > FWIW, I can still install the uprobe at an ebreak with you patch. It's > not hit, but succeeds to install. It seems uprobes install failures are completely silent (see uprobe_mmap() in kernel/events/uprobes.c). So I think although uprobes install seems fine, it actually is not. Best regards, Nam