From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 605F978F2F for ; Wed, 22 Apr 2026 00:54:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776819262; cv=none; b=vAvBeShGB/DI3zEfRItWi+jBTN9iyeai7OAnzggNCAE6BjOtjPN9faZLoCjbzzmmDgkJ9hmfo8ngGpoZD5EL5fyfulXPhApKgAYbgP+njmXwgAjsuBy/pTUtOmZ6IW+5dEC/ZEImxew6SUxolDGDwCVc+xvkug+UyUsG3lyVV58= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776819262; c=relaxed/simple; bh=2an5hwYIHyf4saiFOg59F3jagfWB/DaFFCu4bO87lJ4=; h=Date:From:To:Cc:Subject:Message-Id:Mime-Version:Content-Type; b=fWMPQpEwY41OhltBzKyEfufGpG+Ti/e82nQ+t8BFEAXm3GitjkG0BOue934dk3ZVj4IZZ13+IVHhTQDtYIblYUn8tKUbobdHahW74ap/4KWFBdjQU7lXxfwhqXMOt+Xwbq8a8CFmhVYwYaf0j9ASTsIZMQvqrBfwIth2HtZKO6s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p9K4lNOI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p9K4lNOI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC593C2BCB0; Wed, 22 Apr 2026 00:54:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776819261; bh=2an5hwYIHyf4saiFOg59F3jagfWB/DaFFCu4bO87lJ4=; h=Date:From:To:Cc:Subject:From; b=p9K4lNOIY5JkB2vfi7e9r+cfGczdi6Hlxl156u6QiEEfSY5ZldNVi3BAEx7+ihJ8D NPABJyMErgwN9d6CEHOrjiAI1IziMRQZTiti+jRZH1i/2plohClmZAsKH1c/dcjVbJ MzsSqq3eBiDpCoVkwuCV7xCpmJ4duPfcnGwATxbF5qfzllwDk6w2iu4FeRe53MPvXk WXoxH8CUU8g4zCK5xvGza8XJor5yhsIQC33VbLgDCtvRQTIr6+LuHRE2kT7eleTe7E gOpESbmTM20PBzLzDZOvL3qOGOY90QakVuT5BZUDEu0JLcytBAGU6+AbbEBa8xrKT+ aUK/xJ9d0ZoNw== Date: Wed, 22 Apr 2026 09:54:18 +0900 From: Masami Hiramatsu (Google) To: Linus Torvalds Cc: Masami Hiramatsu (Google) , Steven Rostedt , Masami Hiramatsu , linux-kernel@vger.kernel.org Subject: [GIT PULL] probes: Fixes for v7.1 Message-Id: <20260422095418.4674fe1a3b1bd5fcc7186f67@kernel.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Linus, Probes fixes for v7.1 - fprobe: Fixed several bugs, which includes followings: . Prevention of re-registration: Added an earlier check to reject re-registering an already active fprobe before its state is modified during the initialization phase. . Robustness in failure paths: - Ensured fprobes are correctly removed from all internal tables and properly RCU-freed during registration failure. - Modified unregister_fprobe() to proceed with unregistration even if temporary memory allocation fails. . RCU safety in module unloading: Avoided a potential "sleep in RCU" warning by removing a kcalloc() call in the module notifier path. This also tries to remove fprobe_hash_node even if memory allocation fails. . Type-aware unregistration: Fixed a bug where unregistering an fprobe did not account for different types (entry-only vs. entry-exit) at the same address, which previously left "junk" entries in the underlying ftrace/fgraph ops. . Unregistration of empty ftrace_ops: Avoided unneeded performance overhead because of making registered ftrace_ops empty (means trace all functions.) This counts remaining entries and unregister ftrace_ops when it becomes empty. - ftracetest: In addition to the fix, two new selftests to check above fixes, are included: . Module Unloading Test: Specifically verifies that fprobe events on a module are correctly cleaned up and do not trigger "trace-all" behavior when the module is removed. . Multiple Fprobe Events Test: Ensures that having multiple fprobes on the same function correctly manages the ftrace hash map during removal. Please pull the latest probes-v7.1-2 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git probes-v7.1-2 Tag SHA1: 02ae3fda580c7421659230990bd1520a908f9808 Head SHA1: 453553e1ed53ca364454e155ba33e110d02c75cd Masami Hiramatsu (Google) (8): tracing/fprobe: Reject registration of a registered fprobe before init tracing/fprobe: Unregister fprobe even if memory allocation fails tracing/fprobe: Remove fprobe from hash in failure path tracing/fprobe: Avoid kcalloc() in rcu_read_lock section tracing/fprobe: Check the same type fprobe on table as the unregistered one tracing/fprobe: Fix to unregister ftrace_ops if it is empty on module unloading selftests/ftrace: Add a testcase for fprobe events on module selftests/ftrace: Add a testcase for multiple fprobe events ---- kernel/trace/fprobe.c | 472 ++++++++++++++------- .../test.d/dynevent/add_remove_fprobe_module.tc | 87 ++++ .../test.d/dynevent/add_remove_multiple_fprobe.tc | 69 +++ 3 files changed, 466 insertions(+), 162 deletions(-) create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/add_remove_fprobe_module.tc create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/add_remove_multiple_fprobe.tc --------------------------- -- Masami Hiramatsu (Google)