Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1453317ybh; Thu, 23 Jul 2020 09:13:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxzHPcXm8F8p6e3kpQaamdwEY5XhRs6xKz7e6GWI6j4vRjHiR94a37VKpOZTov2zWW+A034 X-Received: by 2002:a17:906:ae56:: with SMTP id lf22mr5011431ejb.59.1595520792097; Thu, 23 Jul 2020 09:13:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595520792; cv=none; d=google.com; s=arc-20160816; b=wWlhWkc0Rasv8WfHFzpjBB/qJSKTvudfKvrXj2qiE4rQxyFcv9BmE1dq5W66PDQqfd sQapox3vLufaS6r+nlXm1NnRRZOiWSUoLKiu479HdXieptkPp6s4MqzuN1EJG+DtccVS 4SbJuM3L3BowJ7ADTqMAl1FfAGV8ya+8An+aZ8VcXJMdVM/8l6033JaPLRSJT+mJxz1P CmZjgc1nEF8VTBOoLXOT5SqTpPx0utNy25cXmIpBVdtva6Dzs87jSbJDScLSh9DndGVE D7ZgybkgTA3KLD3WiJAKdB5VwsDci6IlQac/7uyIdkge6MAAnUJcsbdVFB6mKffdzpgB QSKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=EMfLtOU2Fw+nEp8tMmNXvR62EUoLOoddttHGrIEzSgM=; b=KKPPVvIj37eoU15wkO+v9pFykPr6GJe5fX9kTbJi1mKEKbsxe6Ez/g06f+L+3RORm4 r0Zuz7gMTJIBS7T8AcPn0IyGIN2PRVWN+79PZ6EMLyb1jttSwCkhuyBv2cV9rhAw8kJJ 5Zw0PdWJ+Rj/iN+bGaPaEoOLUXA+uMRPF3j+ee7tISppgEBgizRs3SxKk+3FMVKJNxiY Je6b6phu1nqCEznYou1WTgl+vyDKLj01pW/dWCABez5vDnEG0A1YnyXQAFrVjWlfUy6r xWpATplF4duEWDCq/QWW2aRIx4Wa55I44xAiMkkz5zLj118EmB5v3X/CUzUre14YX+Of 1/7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="KTAu2n/t"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v15si2380809edl.205.2020.07.23.09.12.48; Thu, 23 Jul 2020 09:13:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="KTAu2n/t"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1727052AbgGWQLt (ORCPT + 99 others); Thu, 23 Jul 2020 12:11:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:38966 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726621AbgGWQLt (ORCPT ); Thu, 23 Jul 2020 12:11:49 -0400 Received: from devnote2 (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3E0EC20714; Thu, 23 Jul 2020 16:11:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595520708; bh=UwNbjNnkRhPtN3M1FcHhf18EPEdkbGS8hia36IkGCMU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KTAu2n/tep3Ope7nKjpIkD+hDh2cBrQhD+vCOEIs3a+CvHULRCInnNBPVRtiJjVFz y2b0cdYj8JDxlEzZaYRf3gdCEFZ2VHlj9ynUF6u0mFAZJRGgFPQzDsuL1mPD6bhOB6 bQrPjm1rSyM1gVdo1QEcqD83BrODAPLuHymSTkTU= Date: Fri, 24 Jul 2020 01:11:43 +0900 From: Masami Hiramatsu To: Guo Ren Cc: Palmer Dabbelt , Paul Walmsley , Oleg Nesterov , linux-riscv , Linux Kernel Mailing List , Anup Patel , linux-csky@vger.kernel.org, Greentime Hu , Zong Li , Patrick =?UTF-8?B?U3TDpGhsaW4=?= , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Guo Ren , Pekka Enberg Subject: Re: [PATCH v3 6/7] riscv: Add KPROBES_ON_FTRACE supported Message-Id: <20200724011143.a2dd2e231411e46edde2e8c4@kernel.org> In-Reply-To: References: <1594683562-68149-1-git-send-email-guoren@kernel.org> <1594683562-68149-7-git-send-email-guoren@kernel.org> <20200714203757.512ce7fb5fa61a88b1dbb2f3@kernel.org> <20200721222701.3074315f6a9f6c42c5963f40@kernel.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 22 Jul 2020 21:31:20 +0800 Guo Ren wrote: > Hi Masami, > > Current riscv ftrace_caller utilize fp(s0) - 8 in stack to get ra of > function, eg: > foo: > 2bb0: 7119 addi sp,sp,-128 > 2bb2: f8a2 sd s0,112(sp) > 2bb4: fc86 sd ra,120(sp) > ... > 2bc4: 0100 addi s0,sp,128 > ... > 0000000000002bca <.LVL828>: > 2bca: 00000097 auipc ra,0x0 > 2bce: 000080e7 jalr ra # 2bca <.LVL828> //_mcount > > So just put two nops before prologue of function isn't enough, because > riscv don't like arm64 which could use x9-x18 reserved regs to pass > ra(x30). > | mov x9, x30 > | bl > If the benefit is just making a kprobe on function symbol address to > prevent disassembling, I'll delay this feature. I recommend that. This feature has to involve ftrace and gcc, so it is better to split it from this series. > > > I also have a look at HAVE_FENTRY & HAVE_NOP_MCOUNT. Seems it just > avoid using scripts/recordmcount.pl script and directly generate nops > for _mcount. Right. > It's different from -fpatchable-function-entry=2 which generating nops > before function prologue in arm64, isn't it? Yes, fentry is for x86, but -fpatchable-function-entry=2 is making a placeholder with nop at the entry of the functions for direct patching. Thank you, > > On Tue, Jul 21, 2020 at 9:27 PM Masami Hiramatsu wrote: > > > > On Wed, 15 Jul 2020 00:24:54 +0800 > > Guo Ren wrote: > > > > > Thx Masami, > > > > > > On Tue, Jul 14, 2020 at 7:38 PM Masami Hiramatsu wrote: > > > > > > > > On Mon, 13 Jul 2020 23:39:21 +0000 > > > > guoren@kernel.org wrote: > > > > > > > > > From: Guo Ren > > > > > > > > > > This patch adds support for kprobes on ftrace call sites to avoids > > > > > much of the overhead with regular kprobes. Try it with simple > > > > > steps: > > > > > > > > > > 1. Get _do_fork ftrace call site. > > > > > Dump of assembler code for function _do_fork: > > > > > 0xffffffe00020af64 <+0>: addi sp,sp,-128 > > > > > 0xffffffe00020af66 <+2>: sd s0,112(sp) > > > > > 0xffffffe00020af68 <+4>: sd ra,120(sp) > > > > > 0xffffffe00020af6a <+6>: addi s0,sp,128 > > > > > 0xffffffe00020af6c <+8>: sd s1,104(sp) > > > > > 0xffffffe00020af6e <+10>: sd s2,96(sp) > > > > > 0xffffffe00020af70 <+12>: sd s3,88(sp) > > > > > 0xffffffe00020af72 <+14>: sd s4,80(sp) > > > > > 0xffffffe00020af74 <+16>: sd s5,72(sp) > > > > > 0xffffffe00020af76 <+18>: sd s6,64(sp) > > > > > 0xffffffe00020af78 <+20>: sd s7,56(sp) > > > > > 0xffffffe00020af7a <+22>: mv s4,a0 > > > > > 0xffffffe00020af7c <+24>: mv a0,ra > > > > > 0xffffffe00020af7e <+26>: nop <<<<<<<< here! > > > > > 0xffffffe00020af82 <+30>: nop > > > > > 0xffffffe00020af86 <+34>: ld s3,0(s4) > > > > > > > > > > 2. Set _do_fork+26 as the kprobe. > > > > > echo 'p:myprobe _do_fork+26 dfd=%a0 filename=%a1 flags=%a2 mode=+4($stack)' > /sys/kernel/debug/tracing/kprobe_events > > > > > echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable > > > > > cat /sys/kernel/debug/tracing/trace > > > > > tracer: nop > > > > > > > > > > entries-in-buffer/entries-written: 3/3 #P:1 > > > > > > > > > > _-----=> irqs-off > > > > > / _----=> need-resched > > > > > | / _---=> hardirq/softirq > > > > > || / _--=> preempt-depth > > > > > ||| / delay > > > > > TASK-PID CPU# |||| TIMESTAMP FUNCTION > > > > > | | | |||| | | > > > > > sh-87 [000] .... 551.557031: myprobe: (_do_fork+0x1a/0x2e6) dfd=0xffffffe00020af7e filename=0xffffffe00020b34e flags=0xffffffe00101e7c0 mode=0x20af86ffffffe0 > > > > > > > > > > cat /sys/kernel/debug/kprobes/list > > > > > ffffffe00020af7e k _do_fork+0x1a [FTRACE] > > > > > ^^^^^^ > > > > > > > > Hmm, this seems fentry is not supported on RISC-V yet. But anyway, > > > > it will be useful for users (if they can find the offset). > > > > > > Seems only x86 & ⬆️90 use fentry,can you elaborate more about fentry's > > > benefit and how the user could set kprobe on ftrace call site without > > > disassemble? > > > > On x86, the fentry replaces the mcount with just one call instruction, without > > saving any arguments. This means all probes which are puts on the address of > > target symbol, are automatically using ftrace. IOW, all probes on _do_fork+0 > > will use ftrace. We don't need any disassembling. > > > > I think if RISC-V already support "-fpatchable-function-entry=2" option on > > GCC, you can easily enable it as same as arm64. See https://lkml.org/lkml/2019/6/18/648 > > > > Thank you, > > > > -- > > Masami Hiramatsu > > > > -- > Best Regards > Guo Ren > > ML: https://lore.kernel.org/linux-csky/ -- Masami Hiramatsu