Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp146315rwd; Mon, 15 May 2023 21:59:54 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4Or8OwG/hW6zYSB7km4+IydcqSa/uelTkLGSQtTtXfuMTy6bmNlTl8RU2lpcnGvaqmLBw/ X-Received: by 2002:aa7:88ce:0:b0:645:6142:7f5a with SMTP id k14-20020aa788ce000000b0064561427f5amr38233194pff.3.1684213194137; Mon, 15 May 2023 21:59:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684213194; cv=none; d=google.com; s=arc-20160816; b=CT0ha/FVIfE/9MHsXq1pdOZDD/gRm8RfmN89kfsnMnOZH6zrVBTKkrLcqt3fJ5KMp/ m/9Lw9rI5jrpgNhwJIRgezBxJcG6h36JWnJIfSDQlZSmpXdNPpcvZLgdOQ+UzKXdtzSP 8cRmnmTB5WTt+ZfGZIlnEhcdLF1PqhOu/c3MVayRcxhrSOByoYfXnValpqmXi7+fzxet q0vOzSRYPxpDvolxm/kBHlajPixykscwyHqmJOmshgxl16Gsm/hyzGwsOHCyiR77hSAG RBajIz8XFWo60CkyogKQFs0JpJ06twYaR1wcFb8wQLyId1tFvfiFDF4c51Bl5BUkgwMg b0bg== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=Fk/gAQxt+J18g18yvV4eSxOeBEZ32BWuJ0XfOqB1K+I=; b=b4D7znJ4aZCIKCCyxwVNpmvvxPmoGDb+TOpOaerxOv2Sqy87ubB2XwlrnxeN4th6rC 91v1KFuUzqorST/dDMjkMnzGOxp4ck3V7CbIlYffi0uiM3bSk7Hgju1+nVNb1US16LUQ WRsQJwg7qH6TwNNS2a2rrdH+VjRzMBrWTawmPzysCtjBKE5WjhDHzEi584yTSG7zuhPX EBECyeM2wBHtRtb1FSgIiAprYB0OTXfW7EQhe2No2mP70orAjtTZYBiQnFpj20Uf5VoG SqY70rRas9I+BKcEYRnJ3g6L45EibaPC6IH1TTztO4cXysAcIYdYig6OfR2fNbZ/sQSH GDtg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="CyFJjn/I"; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k13-20020aa79d0d000000b006375460490dsi19234259pfp.136.2023.05.15.21.59.40; Mon, 15 May 2023 21:59:54 -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="CyFJjn/I"; 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 S229879AbjEPEZ2 (ORCPT + 99 others); Tue, 16 May 2023 00:25:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229876AbjEPEZX (ORCPT ); Tue, 16 May 2023 00:25:23 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C7189468E; Mon, 15 May 2023 21:25:21 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 4C183625E2; Tue, 16 May 2023 04:25:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8036CC433D2; Tue, 16 May 2023 04:25:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684211120; bh=PY/RoOzkUy2hM6zBTkR44gqIGTp4DWfEnEc7SqX2Ea0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CyFJjn/IUHl2FfBle4tevPAFdK50g8q94ecGv8r5F/56N2qnXWP1VnrFQdZl+uJWG uNQzg/b23zTfejXabX3Fvz8TYB1bsWxz+afGK6a9oXkkIOOy6XSa/B6NhOiCGSNnzR 8/TS2vea6ybEkEy+A4WIG6FbW2AoaxhU7sD2+BXIKx41n2aVnSWYZbvOOa/nA/iuxR /kHphWmksO9OBrPbfnNCooVJ9lGbSbjlEGD3VhPHEYRVh3BoAY7Nh2J/AV3HbjfBsl wfcchnh/fIbT3v2vo9su/S7G5CV8zU2WwywofAKxxxuGibPqHxvfLyGjP3I7pHpu6M Mf0BUPRCNt/PA== Date: Tue, 16 May 2023 13:25:16 +0900 From: Masami Hiramatsu (Google) To: Ze Gao Cc: Steven Rostedt , Ze Gao , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH 3/4] fprobe: add recursion detection in fprobe_exit_handler Message-Id: <20230516132516.c902edcf21028874a74fb868@kernel.org> In-Reply-To: <5f8081030f6f5d5af56c93fff95f0a7fadde04ad.1684120990.git.zegao@tencent.com> References: <5f8081030f6f5d5af56c93fff95f0a7fadde04ad.1684120990.git.zegao@tencent.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 15 May 2023 11:26:40 +0800 Ze Gao wrote: > fprobe_hander and fprobe_kprobe_handler has guarded ftrace recusion > detection but fprobe_exit_handler has not, which possibly introduce > recurive calls if the fprobe exit callback calls any traceable > functions. Checking in fprobe_hander or fprobe_kprobe_handler > is not enough and misses this case. Good catch! Yes, this can fix such recursive call case because if we put a fprobe to the exit of the "func()", recursive call happens as below; func() { } => rethook => fprobe_exit_handler() => fp->exit_handler() { func() { } => rethook => fprobe_exit_handler() => fp->exit_handler() { func() { } => rethook ... Note that this should not happen with fprobe-based events because all the code (except for tests) under kernel/trace/ are marked notrace automatically. kretprobe avoids this by setting itself to current_kprobe, thus the other kprobes recursively called from the rethook will be skipped. > > So add recusion free guard the same way as fprobe_hander and also > mark fprobe_exit_handler notrace. Since ftrace recursion check does > not employ ips, so here use entry_ip and entry_parent_ip the same as > fprobe_handler. Looks good to me. Fixes: 5b0ab78998e3 ("fprobe: Add exit_handler support") Cc: stable@vger.kernel.org Acked-by: Masami Hiramatsu (Google) > > Signed-off-by: Ze Gao > --- > kernel/trace/fprobe.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c > index ad9a36c87ad9..cf982d4ab142 100644 > --- a/kernel/trace/fprobe.c > +++ b/kernel/trace/fprobe.c > @@ -17,6 +17,7 @@ > struct fprobe_rethook_node { > struct rethook_node node; > unsigned long entry_ip; > + unsigned long entry_parent_ip; > char data[]; > }; > > @@ -39,6 +40,7 @@ static inline notrace void __fprobe_handler(unsigned long ip, unsigned long > } > fpr = container_of(rh, struct fprobe_rethook_node, node); > fpr->entry_ip = ip; > + fpr->entry_parent_ip = parent_ip; > if (fp->entry_data_size) > entry_data = fpr->data; > } > @@ -109,19 +111,30 @@ static void notrace fprobe_kprobe_handler(unsigned long ip, unsigned long parent > ftrace_test_recursion_unlock(bit); > } > > -static void fprobe_exit_handler(struct rethook_node *rh, void *data, > +static void notrace fprobe_exit_handler(struct rethook_node *rh, void *data, > struct pt_regs *regs) > { > struct fprobe *fp = (struct fprobe *)data; > struct fprobe_rethook_node *fpr; > + int bit; > > if (!fp || fprobe_disabled(fp)) > return; > > fpr = container_of(rh, struct fprobe_rethook_node, node); > > + /* we need to assure no calls to traceable functions in-between the > + * end of fprobe_handler and the beginning of fprobe_exit_handler. > + */ > + bit = ftrace_test_recursion_trylock(fpr->entry_ip, fpr->entry_parent_ip); > + if (bit < 0) { > + fp->nmissed++; > + return; > + } > + > fp->exit_handler(fp, fpr->entry_ip, regs, > fp->entry_data_size ? (void *)fpr->data : NULL); > + ftrace_test_recursion_unlock(bit); > } > NOKPROBE_SYMBOL(fprobe_exit_handler); > > -- > 2.40.1 > -- Masami Hiramatsu (Google)