From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1189134F257 for ; Fri, 6 Mar 2026 09:57:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772791042; cv=none; b=a20S7geIR0APpGaanbxjWn8FUkwfVj6ZORPWjaG6G8+87Eb4P/CPBZsM/OH/AIn2Lb42B1dYDum9Laym4olnnRoX7zg98kks/aa9MxHuapLndgySCaGmWwl9biSZBLfv62HxXW+AUGSrsx99TcC3XyYqytXIttPSVvI6urefTDM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772791042; c=relaxed/simple; bh=pEQzWCAb2iRAqiobf7jxVYCtdRuojtFnQZa3BQ+Dyyc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PNETXjXwxOTRwyhy0izgf2kQmsgpxx0ZlCoYj6Nw7sF9Z1OmY1vPIjTj069TZCRYo0YB/FQePsaT8OViPdrXrJflfq/HdeCpl1kchPXBVAs5zA7K+DjRmyCEVQF5gz0HXFtJgoisZegMlqnuFjhNSA+Z++cc4Ac8NJ6l0UB6dRA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=EOsxzA63; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="EOsxzA63" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4836f4cbe0bso78164255e9.3 for ; Fri, 06 Mar 2026 01:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772791035; x=1773395835; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=O/K2aprkN4j5Qcb7Uph8KKaqrtRBJnLURcoh9D3mrUw=; b=EOsxzA63XzaseIkVZ6IrLdWGyCJaNf3twu9123Mtl4OPI8F4HlgxpeTUDbG8KmhtST F2YhOX4N///ZNqP/vH0J+ChwK7apappP2VS6FKF95kdzjFeb3eIg6Dc3uwe9cksVBblo Bco2ntcM6lmH0lhej+mRCnQ/12+V4dVodu/YXpS2b0vxwPnRiLFocVbbTu8uGJMvmDPw e28vjCtbCp5M9Y8N7t7s+ExpRU7tnImyBX0Mw8Ku3dvzWyypeRbVElXvm0gQ6IhzZrPC NTI/wAx+pRjlOUAxYebVAFUUqqu9MijnltA7jcVtyLyJSsPPwt7sL3OFKHrbnVMBghqv tO8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772791035; x=1773395835; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=O/K2aprkN4j5Qcb7Uph8KKaqrtRBJnLURcoh9D3mrUw=; b=D3EBOYwHRFg1lfFa5364UxZhGRU3ymnldHZi0YDijk9tw6RJs8C1hLKJ+oM75YMBjv tEWUyUc0ub1W3BVIRybgCSIgQtM8KTPdW43CSZbjTfQhjmNkrzsHPC+90iGMNCFwV612 W2+VttV7Y8dt5GY2+8R80gb5zRTfKvact7AoPPsQaBkXwt9E9gdsG9bxAKihQcFeW+99 bCyybqcT/3xVNnqiBD146oVS7DYsVZ8AocC3jvuu1kJYmWPlTXM+DmcwDSOeWXQz7D48 q2OVO8YYpGvppxXdhFfVLQ3BISC925luDFmwuVvUrTKbrndMqq9o1t+H08H5//4q8cW8 IORA== X-Forwarded-Encrypted: i=1; AJvYcCWab0CMOX/E4cMpMMfmGMxpqu72ohya019KrKBhYQoO7gspZft6Rdv/NyYqItMzNOlAq9NShrZjdcqac/EV@vger.kernel.org X-Gm-Message-State: AOJu0YxH+wgeJ1wH6fiUWGODzVBokBAb+Dp1toNAzKilr+L1JlgJVJ6p 6tvLL2l47hPXhmxU1cawQyXda4ann+HOHNWIgjaWvErZTtZ6bsB2kYXYmM9fdExHWLM= X-Gm-Gg: ATEYQzxRWmPZbp1E/u7ZbOODkobvrqFnwJ6Uy+zTC0QdEOUjJNZXO1uGvcEbc+hsMlk jzUbCb+EiJtJciQq9cNHDOvCVLVWda2sxXPJmVuPVMj0KCm1zECXPF/53Tzf/egI6xwoDJFwytd 0VfBLmI8I2TA51aokAyKzIKXLWlwdVtpO7e+4M5/gIgYqf+szSrpOaOqCwMZt0/29Meen5I0QRP hB/J0q2Qbg0+vlzD9kOWFNJtf3/6kgrGI4KE9+4KjeNiGiodbMziuKdI/kVVIKHH/qrZhv+Hsa4 dfbd7S1jKHEVLuXIufYvT6GTZ7wsK0joB024hvtEeoKWeTgBcDZ5ek2SqzPC7HOZ6Ib/JMk/ZjA aSMPwkniIir5M5D6jDO4DyJabS0Yw5hB4Ga8c0DLNVIELhYlbrwZtEqXUbhblBSSqo3hsrfT67l gsp7ppiMSlRsruNNIqAdzeKualNQ== X-Received: by 2002:a05:600c:4e89:b0:45d:d97c:236c with SMTP id 5b1f17b1804b1-48526951430mr23896805e9.21.1772791035167; Fri, 06 Mar 2026 01:57:15 -0800 (PST) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485256b1eacsm24251685e9.0.2026.03.06.01.57.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 01:57:14 -0800 (PST) Date: Fri, 6 Mar 2026 10:57:12 +0100 From: Petr Mladek To: Song Chen Cc: Steven Rostedt , Miroslav Benes , mcgrof@kernel.org, petr.pavlu@suse.com, da.gomez@kernel.org, samitolvanen@google.com, atomlin@atomlin.com, mhiramat@kernel.org, mark.rutland@arm.com, mathieu.desnoyers@efficios.com, linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, live-patching@vger.kernel.org Subject: Re: [PATCH] kernel/trace/ftrace: introduce ftrace module notifier Message-ID: References: <20260225054639.21637-1-chensong_2000@189.cn> <20260225192724.48ed165e@fedora> <20260226123014.2197d9b7@gandalf.local.home> <321d4670-27cb-453f-a50d-426c83894074@189.cn> Precedence: bulk X-Mailing-List: linux-modules@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <321d4670-27cb-453f-a50d-426c83894074@189.cn> On Fri 2026-02-27 09:34:59, Song Chen wrote: > Hi, > > 在 2026/2/27 01:30, Steven Rostedt 写道: > > On Thu, 26 Feb 2026 11:51:53 +0100 (CET) > > Miroslav Benes wrote: > > > > > > Let me see if there is any way to use notifier and remain below calling > > > > sequence: > > > > > > > > ftrace_module_enable > > > > klp_module_coming > > > > blocking_notifier_call_chain_robust(MODULE_STATE_COMING) > > > > > > > > blocking_notifier_call_chain(MODULE_STATE_GOING) > > > > klp_module_going > > > > ftrace_release_mod > > > > > > Both klp and ftrace used module notifiers in the past. We abandoned that > > > and opted for direct calls due to issues with ordering at the time. I do > > > not have the list of problems at hand but I remember it was very fragile. > > > > > > See commits 7dcd182bec27 ("ftrace/module: remove ftrace module > > > notifier"), 7e545d6eca20 ("livepatch/module: remove livepatch module > > > notifier") and their surroundings. > > > > > > So unless there is a reason for the change (which should be then carefully > > > reviewed and properly tested), I would prefer to keep it as is. What is > > > the motivation? I am failing to find it in the commit log. > > There is no special motivation, i just read btf initialization in module > loading and found direct calls of ftrace and klp, i thought they were just > forgotten to use notifier and i even didn't search git log to verify, sorry > about that. > > > > > Honestly, I do think just decoupling ftrace and live kernel patching from > > modules is rationale enough, as it makes the code a bit cleaner. But to do > > so, we really need to make sure there is absolutely no regressions. > > > > Thus, to allow such a change, I would ask those that are proposing it, show > > a full work flow of how ftrace, live kernel patching, and modules work with > > each other and why those functions are currently injected in the module code. > > > > As Miroslav stated, we tried to do it via notifiers in the past and it > > failed. I don't want to find out why they failed by just adding them back > > to notifiers again. Instead, the reasons must be fully understood and > > updates made to make sure they will not fail in the future. > > Yes, you are right, i read commit msg of 7dcd182bec27, this patch just > reverses it simply and will introduce order issue back. I will try to find > out the problem in the past at first. AFAIK, the root of the problem is that livepatch uses the ftrace framework. It means that: + ftrace must be initialized before livepatch gets enabled + livepatch must be disabled before ftrace support gets removed My understanding is that this can't be achieved by notifiers easily because they are always proceed in the same order. An elegant solution would be to introduce notifier_reverse_call_chain() which would process the callbacks in the reverse order. But it might be non-trivial: + We would need to make sure that it does not break some existing "hidden" dependencies. + notifier_call_chain() uses RCU to process the list of registered callbacks. I am not sure how complicated would be to make it safe in both directions. Best Regards, Petr