| Message ID | 166653477373.988423.13256491425983587550.stgit@mhiramat.roam.corp.google.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp16947wru;
Sun, 23 Oct 2022 07:34:11 -0700 (PDT)
X-Google-Smtp-Source:
AMsMyM6wVexM5j+PKV7OiirTZer41b1qUIi995LHJV4xhszRrHtHipNIdJECZNegnRUya9aPzbPZ
X-Received: by 2002:a63:db49:0:b0:439:246e:8091 with SMTP id
x9-20020a63db49000000b00439246e8091mr24654926pgi.295.1666535650686;
Sun, 23 Oct 2022 07:34:10 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1666535650; cv=none;
d=google.com; s=arc-20160816;
b=UGMSlRcTS3IVRoum51vWhmqGodYnsgMImDmx3XNfQzc+irAGCwWUWD3xEjWziIvbth
sEo6D7EWu73CahAHRcpJ5+iYQa3QLh2U+Gm1pXeBXy+Sv4FUcnmQoTWctx6c/3vasC8B
wQwbBEt4vzGaFvnmS0kQ7pS1od1df00ONX41e9sR9jbKYhkd4fkGsJ5dVwncjkxr3YRu
AME29CF7oE9IXrYFNlP42it2x7R+zIxMooN3L71HtGjBklSBVEu5IwmZv4Utd3W6XA6I
KYQnwQlGHp/eQRXjfUfOfSfNNygZVIr8Sj3ufv2HsnbU43yL08MifGJB9bMhr8YYOCfC
K1hA==
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
:user-agent:message-id:date:subject:cc:to:from:dkim-signature;
bh=31anFStx/7TYEqrk2V08TE1gQhyqfEfCBbom4jJWg0M=;
b=c7oaDk+ZOIcfiDDE4Hyr8Rgz6vyXfU9QGEM0WRjNDpecAWtgPB3cmyE7jz/LvNctAi
IxJkSTkD/wPANGkToyBaaekx0JnUFymHsfQZScEfjwUogFRRfP7EaUs75nsm+MVvo0ps
EUkxw6D4zpfOWAJzD4d/1HzOIN5ami99VMytAaupWSlDZRkoAfn1SrSVY1uFvNqHdLAf
sJVZSFJE+nYxuSj/dHlq+jgziyPTn7ANMeqGGXrGe8yMrOp/i5AUdAl10+Li5ssooq3T
ycjSHFFsW0LRAnp9nAzY7BAGzmV6brtpKzegtK+OmMriZk5yPWz0D2ZkFiBOw2dB+BLG
cI5w==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Y0L8rl4P;
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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20])
by mx.google.com with ESMTP id
z6-20020a630a46000000b0046a79b71854si32198923pgk.334.2022.10.23.07.33.56;
Sun, 23 Oct 2022 07:34:10 -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=Y0L8rl4P;
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 S229588AbiJWOTu (ORCPT <rfc822;pwkd43@gmail.com> + 99 others);
Sun, 23 Oct 2022 10:19:50 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36272 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S229987AbiJWOTq (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Sun, 23 Oct 2022 10:19:46 -0400
Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C35A205EE;
Sun, 23 Oct 2022 07:19:39 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ams.source.kernel.org (Postfix) with ESMTPS id 459B7B80BA4;
Sun, 23 Oct 2022 14:19:38 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D382C433D6;
Sun, 23 Oct 2022 14:19:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1666534777;
bh=BnCoxBwqfVc8mFv8C62qIS6ajfq0d32muTzGWdCbdAI=;
h=From:To:Cc:Subject:Date:From;
b=Y0L8rl4P597U5ntLRnqmjYUc1GxXaTJjP0slOO9rCSXIEeo6MM60IHlVlADpFBubO
AEjoaDrSL9R4//f7gEV/V4hqYIQ4yhIo06nUKzW1rX8xUsuJ2znO1WvrvZZCcI38fU
9YcLW144r6XxEiNdMEI7FloRu28GmFB/iRBWbfXHGEtsfMkb+WD3GZB5Mm+Kidlp/8
SOeMQI0XWZJXPbcnWqBacQhamrGQThrbUY5IQBdIvuBQHJ0lTzyALvv4w6Rgf/Bb7S
v2MZv7PAFofFAjNM81A0knT/lg7VequCzByU1ZJRFQBajhqjcmShNlIfQXLAYL39RL
7S9Ug7CNVlHKA==
From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Jiri Olsa <jolsa@kernel.org>
Subject: [PATCH] tracing/fprobe: Fix to check whether fprobe is registered
correctly
Date: Sun, 23 Oct 2022 23:19:33 +0900
Message-Id:
<166653477373.988423.13256491425983587550.stgit@mhiramat.roam.corp.google.com>
X-Mailer: git-send-email 2.38.0.135.g90850a2211-goog
User-Agent: StGit/0.19
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
SPF_HELO_NONE,SPF_PASS 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?=
X-GMAIL-THRID: =?utf-8?q?1747489286538805920?=
X-GMAIL-MSGID: =?utf-8?q?1747489286538805920?=
|
| Series |
tracing/fprobe: Fix to check whether fprobe is registered correctly
|
|
Commit Message
Masami Hiramatsu (Google)
Oct. 23, 2022, 2:19 p.m. UTC
From: Masami Hiramatsu (Google) <mhiramat@kernel.org> Since commit ab51e15d535e ("fprobe: Introduce FPROBE_FL_KPROBE_SHARED flag for fprobe") introduced fprobe_kprobe_handler() for fprobe::f_op::func, unregister_fprobe() fails to unregister the registered if user specifies FPROBE_FL_KPROBE_SHARED flag. To check it correctly, it should confirm the fprobe::f_op::func is either fprobe_handler() or fprobe_kprobe_handler(). Fixes: ab51e15d535e ("fprobe: Introduce FPROBE_FL_KPROBE_SHARED flag for fprobe") Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> --- kernel/trace/fprobe.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On Sun, Oct 23, 2022 at 11:19:33PM +0900, Masami Hiramatsu (Google) wrote: > From: Masami Hiramatsu (Google) <mhiramat@kernel.org> > > Since commit ab51e15d535e ("fprobe: Introduce FPROBE_FL_KPROBE_SHARED flag > for fprobe") introduced fprobe_kprobe_handler() for fprobe::f_op::func, > unregister_fprobe() fails to unregister the registered if user specifies > FPROBE_FL_KPROBE_SHARED flag. > To check it correctly, it should confirm the fprobe::f_op::func is either > fprobe_handler() or fprobe_kprobe_handler(). > > Fixes: ab51e15d535e ("fprobe: Introduce FPROBE_FL_KPROBE_SHARED flag for fprobe") > Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> jirka > --- > kernel/trace/fprobe.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c > index aac63ca9c3d1..9000d8ea6274 100644 > --- a/kernel/trace/fprobe.c > +++ b/kernel/trace/fprobe.c > @@ -301,7 +301,8 @@ int unregister_fprobe(struct fprobe *fp) > { > int ret; > > - if (!fp || fp->ops.func != fprobe_handler) > + if (!fp || (fp->ops.func != fprobe_handler && > + fp->ops.func != fprobe_kprobe_handler)) > return -EINVAL; > > /* >
On Sun, 23 Oct 2022 23:19:33 +0900 "Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote: > From: Masami Hiramatsu (Google) <mhiramat@kernel.org> > > Since commit ab51e15d535e ("fprobe: Introduce FPROBE_FL_KPROBE_SHARED flag > for fprobe") introduced fprobe_kprobe_handler() for fprobe::f_op::func, > unregister_fprobe() fails to unregister the registered if user specifies > FPROBE_FL_KPROBE_SHARED flag. > To check it correctly, it should confirm the fprobe::f_op::func is either > fprobe_handler() or fprobe_kprobe_handler(). > > Fixes: ab51e15d535e ("fprobe: Introduce FPROBE_FL_KPROBE_SHARED flag for fprobe") > Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> > --- > kernel/trace/fprobe.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c > index aac63ca9c3d1..9000d8ea6274 100644 > --- a/kernel/trace/fprobe.c > +++ b/kernel/trace/fprobe.c > @@ -301,7 +301,8 @@ int unregister_fprobe(struct fprobe *fp) > { > int ret; > > - if (!fp || fp->ops.func != fprobe_handler) > + if (!fp || (fp->ops.func != fprobe_handler && > + fp->ops.func != fprobe_kprobe_handler)) > return -EINVAL; > > /* Should we make this more paranoid? if (!fp || (fprobe_shared_with_kprobes(fp) && fp->ops.func != fprobe_kprobe_handler) || (!fprobe_shared_with_kprobes(fp) && fp->ops.func != fprobe_handler)) Or is that over-kill? -- Steve
On Mon, 24 Oct 2022 10:22:30 -0400 Steven Rostedt <rostedt@goodmis.org> wrote: > On Sun, 23 Oct 2022 23:19:33 +0900 > "Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote: > > > From: Masami Hiramatsu (Google) <mhiramat@kernel.org> > > > > Since commit ab51e15d535e ("fprobe: Introduce FPROBE_FL_KPROBE_SHARED flag > > for fprobe") introduced fprobe_kprobe_handler() for fprobe::f_op::func, > > unregister_fprobe() fails to unregister the registered if user specifies > > FPROBE_FL_KPROBE_SHARED flag. > > To check it correctly, it should confirm the fprobe::f_op::func is either > > fprobe_handler() or fprobe_kprobe_handler(). > > > > Fixes: ab51e15d535e ("fprobe: Introduce FPROBE_FL_KPROBE_SHARED flag for fprobe") > > Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> > > --- > > kernel/trace/fprobe.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c > > index aac63ca9c3d1..9000d8ea6274 100644 > > --- a/kernel/trace/fprobe.c > > +++ b/kernel/trace/fprobe.c > > @@ -301,7 +301,8 @@ int unregister_fprobe(struct fprobe *fp) > > { > > int ret; > > > > - if (!fp || fp->ops.func != fprobe_handler) > > + if (!fp || (fp->ops.func != fprobe_handler && > > + fp->ops.func != fprobe_kprobe_handler)) > > return -EINVAL; > > > > /* > > Should we make this more paranoid? > > if (!fp || > (fprobe_shared_with_kprobes(fp) && fp->ops.func != fprobe_kprobe_handler) || > (!fprobe_shared_with_kprobes(fp) && fp->ops.func != fprobe_handler)) > > Or is that over-kill? Yeah, I think it is over-kill since this is just for a safety check, like checking NULL in free(). Or, are there any way to check the ftrace_ops is registered? Thank you, > > -- Steve
On Sun, 23 Oct 2022 23:19:33 +0900 "Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote: > From: Masami Hiramatsu (Google) <mhiramat@kernel.org> > > Since commit ab51e15d535e ("fprobe: Introduce FPROBE_FL_KPROBE_SHARED flag > for fprobe") introduced fprobe_kprobe_handler() for fprobe::f_op::func, > unregister_fprobe() fails to unregister the registered if user specifies > FPROBE_FL_KPROBE_SHARED flag. > To check it correctly, it should confirm the fprobe::f_op::func is either > fprobe_handler() or fprobe_kprobe_handler(). > > Fixes: ab51e15d535e ("fprobe: Introduce FPROBE_FL_KPROBE_SHARED flag for fprobe") > Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> > --- > kernel/trace/fprobe.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c > index aac63ca9c3d1..9000d8ea6274 100644 > --- a/kernel/trace/fprobe.c > +++ b/kernel/trace/fprobe.c > @@ -301,7 +301,8 @@ int unregister_fprobe(struct fprobe *fp) > { > int ret; > > - if (!fp || fp->ops.func != fprobe_handler) > + if (!fp || (fp->ops.func != fprobe_handler && > + fp->ops.func != fprobe_kprobe_handler)) Oops, ops.func can be changed by ftrace itself. Hmm, maybe I should check fp->ops.saved_func instead. Thank you, > return -EINVAL; > > /* >
diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c index aac63ca9c3d1..9000d8ea6274 100644 --- a/kernel/trace/fprobe.c +++ b/kernel/trace/fprobe.c @@ -301,7 +301,8 @@ int unregister_fprobe(struct fprobe *fp) { int ret; - if (!fp || fp->ops.func != fprobe_handler) + if (!fp || (fp->ops.func != fprobe_handler && + fp->ops.func != fprobe_kprobe_handler)) return -EINVAL; /*