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 X-Spam-Level: X-Spam-Status: No, score=-6.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64AA9C433DB for ; Wed, 27 Jan 2021 04:09:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 164AD206B5 for ; Wed, 27 Jan 2021 04:09:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238232AbhA0EJV (ORCPT ); Tue, 26 Jan 2021 23:09:21 -0500 Received: from mail.kernel.org ([198.145.29.99]:35104 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236632AbhA0Din (ORCPT ); Tue, 26 Jan 2021 22:38:43 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 79E792065D; Wed, 27 Jan 2021 02:14:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611713643; bh=pBjS8rajKCc4fs2v623TwRe6Bucank2I4/ZmVoafaQI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CccKoyyVkrAYSqqEAQgo/nqYUOLf5MzbSBGuWIaX+WBeEJUh/VwSDS8NXO4BsCSxS UP3YLp83difx1edvKkDPv4VsuI6ryhYVs3jLo5ziYmjEO8b0aGegmiFzFKA5hwLYx9 jg9zyxaFTMSo1y4gHnhy5YTrKgHfn8tPG4cVokSyyGlt0oVXeYO1MUomaVMKZnOFog RhzvtB3HwXEdNp5e2AL0t8kaU17HNw12Dv5Xh1VDzFD0MdoPEo9cGX7KQsXOHWnZNY Nsl72PfFm1HYYJkW9c2lj8mbfwbOe6d+hOxjIK4b1yGlJ6lR3vPf9DQonx1oaPSVYX YXuRp5WH7fE2w== Date: Wed, 27 Jan 2021 11:14:00 +0900 From: Masami Hiramatsu To: Steven Rostedt Cc: Oleg Nesterov , Masami Hiramatsu , Jianlin Lv , mingo@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] tracing: precise log info for kretprobe addr err Message-Id: <20210127111400.1b9accddc80bd2a2422b9d40@kernel.org> In-Reply-To: <20210126164038.566ef8c2@gandalf.local.home> References: <20210125160108.2147511-1-Jianlin.Lv@arm.com> <20210125181926.GA10248@redhat.com> <20210125133840.511b1496@gandalf.local.home> <20210126131536.f6e3a737a7b948799084fa7a@kernel.org> <20210126202058.GC12469@redhat.com> <20210126154302.302a3bb0@gandalf.local.home> <20210126211722.GA23645@redhat.com> <20210126164038.566ef8c2@gandalf.local.home> 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 26 Jan 2021 16:40:38 -0500 Steven Rostedt wrote: > On Tue, 26 Jan 2021 22:17:23 +0100 > Oleg Nesterov wrote: > > > On 01/26, Steven Rostedt wrote: > > > > > > On Tue, 26 Jan 2021 21:20:59 +0100 > > > Oleg Nesterov wrote: > > > > > > > > No, not wrong. Even offset != 0, if the symbol exists in the kernel, > > > > > kprobe_on_func_entry() will check it. > > > > > > > > Yes, but unless I am totally confused... if kprobe_on_func_entry() returns false, > > > > then trace_kprobe_create() should fail with BAD_RETPROBE even if offset == 0 ? > > > > > > From what I understand. kprobe_on_func_entry() can return false if you pass > > > in: "MOD:not_yet_loaded_module_func", but this is OK, because when the > > > module is loaded, and the "not_yet_loaded_module_func" exists, the > > > kretprobe will then be added. > > > > > > The strchr(symbol,":") check is to see if "MOD:" (or some other ":" command) > > > is in the name, and we don't want it to fail if it is. Which is why we > > > should have that commented. > > > > Agreed, this matches my understanding. > > > > But just in case... not sure I read this code correctly, but I think that > > module_kallsyms_lookup_name("not_yet_loaded_module_func") should work even > > without the "MOD:" prefix. > > > > IOW, kprobe_on_func_entry("not_yet_loaded_module_func") can fail, and then > > later succeed if you load the module which provides this symbol. > > > > But even if I am right, I agree with the strchr(symbol,":") check. > > I see what you are saying. If "MOD" is not loaded yet, the > kprobe_on_func_entry() should succeed. No, that makes me more confused. kprobes_on_func_entry() returns true only if it confirms the given address is on the function entry, because it is used in the register_kretprobe() too. OK, I will make a separate check which detects an error that the module is loaded but the symbol does not exist. (current code doesn't check the module is loaded or not) That makes the code clearer. Thank you, -- Masami Hiramatsu