Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp4716430pxb; Tue, 25 Jan 2022 17:25:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJx2js/LrN+lQ9Sx0yt8cClmKsrfXqRW/EnTwckQdV427LNfPPdOn8mMmfsUAyLFddOtg08V X-Received: by 2002:a17:907:9712:: with SMTP id jg18mr18951373ejc.15.1643160319527; Tue, 25 Jan 2022 17:25:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643160319; cv=none; d=google.com; s=arc-20160816; b=SDI4XOV0XlF8N5g5J+k+i57t41qpUaymcHJipVoO0rGvE2jmNVLlVZxvlHCAiq1y7o 5ccqCYT6N225X+4xbkuFsNQzoiJIU6tK+WVIbIoHDLhEU5UIx6XD3eRKuldt5/SDZ3jQ pIGK4kel8+IdCg7rr26E88Y3n2nipl+AQ95dkH1mHMWX5Z8BdTbtPqIlA7RuQYxdMQBZ Rjl52SQVBQWy2iOB0QC8G1iLlHzefBfKAZNd8IRuKA/X96JcWMZ7ku1KfUaYfjtx0AS5 VlcxqX0ilS/v8T28WHf0CtnGIhO2bods3aTVfovzSfALLKuJ+60u4o7P1A1gzxJQDNWE 2O8w== 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; bh=gHdYwSPtTSvjm3qtH9U/E3ley0FocO5vEcZTaQLQWsI=; b=U+608nKQFTSitx9IW8gOYFEBuyTq39/+PHgQV7s6Di/nq1ksOA9FwVY40Z50xnsYon oEKT8G7f+lKgoqL8xT5LYBKfdk29ca3fvAp1V6RQTk/HryZtAWpTnOs2NrD/lFvJIgnx RINoePACBEkV00C8MdIlEtzrd4k99PqxFECw+kzFu7z0BW5Nag9dAmZMHS033J5z/0O2 sHkHv0JTaEaGvsXVIU9NjCfPWbrFg0fFTz5ca9vrRh5wl3RsUJyIB+ozpPyKLiePPxUO Q10HpM5tx2+/ry3Ut55G+mMVOMibqPlFEJZNIkQBE0NxO+7RopRoKKSWmkx5a+uvd9UD ssGg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k7si10343455edr.50.2022.01.25.17.24.55; Tue, 25 Jan 2022 17:25:19 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354737AbiAYRJv (ORCPT + 99 others); Tue, 25 Jan 2022 12:09:51 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:38026 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359219AbiAYRII (ORCPT ); Tue, 25 Jan 2022 12:08:08 -0500 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 B047561155; Tue, 25 Jan 2022 17:08:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87F60C340E0; Tue, 25 Jan 2022 17:08:05 +0000 (UTC) Date: Tue, 25 Jan 2022 12:08:04 -0500 From: Steven Rostedt To: Masami Hiramatsu Cc: Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , netdev@vger.kernel.org, bpf@vger.kernel.org, lkml , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , "Naveen N . Rao" , Anil S Keshavamurthy , "David S . Miller" Subject: Re: [PATCH v5 7/9] fprobe: Add exit_handler support Message-ID: <20220125120804.595afd8b@gandalf.local.home> In-Reply-To: <164311277634.1933078.2632008023256564980.stgit@devnote2> References: <164311269435.1933078.6963769885544050138.stgit@devnote2> <164311277634.1933078.2632008023256564980.stgit@devnote2> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; 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, 25 Jan 2022 21:12:56 +0900 Masami Hiramatsu wrote: > Add exit_handler to fprobe. fprobe + rethook allows us > to hook the kernel function return without fgraph tracer. > Eventually, the fgraph tracer will be generic array based > return hooking and fprobe may use it if user requests. > Since both array-based approach and list-based approach > have Pros and Cons, (e.g. memory consumption v.s. less > missing events) it is better to keep both but fprobe > will provide the same exit-handler interface. Again the 55 character width ;-) > > Signed-off-by: Masami Hiramatsu > --- > Changes in v5: > - Add dependency for HAVE_RETHOOK. > Changes in v4: > - Check fprobe is disabled in the exit handler. > Changes in v3: > - Make sure to clear rethook->data before free. > - Handler checks the data is not NULL. > - Free rethook only if the rethook is using. > --- > @@ -82,6 +117,7 @@ static int convert_func_addresses(struct fprobe *fp) > */ > int register_fprobe(struct fprobe *fp) > { > + unsigned int i, size; > int ret; > > if (!fp || !fp->nentry || (!fp->syms && !fp->addrs) || > @@ -96,10 +132,29 @@ int register_fprobe(struct fprobe *fp) > fp->ops.func = fprobe_handler; > fp->ops.flags = FTRACE_OPS_FL_SAVE_REGS; > > + /* Initialize rethook if needed */ > + if (fp->exit_handler) { > + size = fp->nentry * num_possible_cpus() * 2; > + fp->rethook = rethook_alloc((void *)fp, fprobe_exit_handler); Shouldn't we check if fp->rethook succeeded to be allocated? > + for (i = 0; i < size; i++) { > + struct rethook_node *node; > + > + node = kzalloc(sizeof(struct fprobe_rethook_node), GFP_KERNEL); > + if (!node) { > + rethook_free(fp->rethook); > + ret = -ENOMEM; > + goto out; > + } > + rethook_add_node(fp->rethook, node); > + } > + } else > + fp->rethook = NULL; > + > ret = ftrace_set_filter_ips(&fp->ops, fp->addrs, fp->nentry, 0, 0); > if (!ret) > ret = register_ftrace_function(&fp->ops); > > +out: > if (ret < 0 && fp->syms) { > kfree(fp->addrs); > fp->addrs = NULL; > @@ -125,8 +180,16 @@ int unregister_fprobe(struct fprobe *fp) > return -EINVAL; > > ret = unregister_ftrace_function(&fp->ops); > + if (ret < 0) > + return ret; If we fail to unregister the fp->ops, we do not free the allocated nodes above? -- Steve > > - if (!ret && fp->syms) { > + if (fp->rethook) { > + /* Make sure to clear rethook->data before freeing. */ > + WRITE_ONCE(fp->rethook->data, NULL); > + barrier(); > + rethook_free(fp->rethook); > + } > + if (fp->syms) { > kfree(fp->addrs); > fp->addrs = NULL; > }