From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 9E70C3876AB for ; Thu, 9 Apr 2026 12:37:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775738240; cv=none; b=agB5UrUibw5gA8a4xbl9pxn4pMQ2B2naVVdNQhiBp3Ml8jjJv0tVeQBivYqjxvG58vdRQlWECFIsKV+ZaCbKPhnaWEHr8GJ8Cp/0Qjm226mkLeTzBQdoqQgtiNvNJyiaeZnTn22qXZNIoufBpyJBy9+4W6ilbAwe6FKWzD1UsYg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775738240; c=relaxed/simple; bh=kXqVC67K7Ok0URFdMQss6lTIGbLrxnPL13nMpdUnN/k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dX/ALoN84T5nvxWfCCquiANQVpX4mASwF66SYAauZpX4QM+MB4aTV7c87ASUcfEDsv8VbaPNWeLp/wxY8AuKANPGGEjNZAo4PdY7lOSi3+YRIoQeKmOnLugFYZ+55CD0hJfBPcdYRTusv/xfRlPV6qe7QvpDVEIuIrczjoUZPrI= 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=SueCztIF; arc=none smtp.client-ip=209.85.128.44 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="SueCztIF" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-488b0046078so9178285e9.1 for ; Thu, 09 Apr 2026 05:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1775738238; x=1776343038; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=DXMv5P2otA71oVxzctM87KJsMKwFOqSK4K4FBNtEt2c=; b=SueCztIFgURyMdqUY2D5JdT1xiLTmI/DfOmKuqUjDrd2r7hrlpHxDhhSrvnzauD/Db gd6XWOToDf651nfNocXYFmCXeSjWtm1/Re1Kwuimr/GaBtNn5hFcjPIsAsGQC5UFemDo DXcEOPpGOFkj+crkWm/fpAb8KgP6izmquk/0l8LF/z4z+bWAF6p9yXDUAqFW5xyfCb8e QlYTEztF/CbIN8HI2K7HJBXnyiS3LBmN30ag8w4ksIpVltauPn/itCWb88qd5hCDc1lH EtLAvTKieQDEOYzX0KAMdhEDB3F9CdwpTFy3Ko4/nrVwS9IA0r1iocNFM8HhdcxD2Q56 MqJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775738238; x=1776343038; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DXMv5P2otA71oVxzctM87KJsMKwFOqSK4K4FBNtEt2c=; b=m8UA6mDEKgEb+QnBIKoId7DpL0bxJYDW7Vq01mCGgh4VVYqf/bNoo5sOfHwLiS5X/r LFjhIQB8BUNsPf0ckS6+MFili9RNsSgDlLFF2ZfcB+Qcphykyop91aD+3EEHncZQbwhS HoQxsj/vWbG5MmIF4AwuhLiPVep09y4QI8Cr6CchklIfWNQY+2CFrnLbQEer54pss4aR f3I2QlhUDVk09afLmvXWdSj643PsUsVhYr2nTFHryypHqLuoBTNGVe7wK6apW9WCDoKN mpIugL5P3Eft2dWm+Zl9KI+5PxSvWHNMs+Gi3N9IASKTkcVFaRuCCsfleALndoubWTuk VBjA== X-Forwarded-Encrypted: i=1; AJvYcCXDuKy9FB7CgMr/t0+5VAnTuUoBJs08UbRTnt33GbCRyZPIRigByh1RF3SxY4VcDZvwfmuEIkn+jckHqoI=@vger.kernel.org X-Gm-Message-State: AOJu0YyzyBJFlh7ZRa21LjI4QTJd/kbUQwHXqunEdzt0jaeZr7JBl0kF Y/hu9FPoBgdDh0V4bqzoeefAXTmSWdjil2kPrC3Ai4J3joyIOj9BCE0XLT4R3i8OeIE= X-Gm-Gg: AeBDies/fop7HOSKR1IySAhOA2WWAbYVBBzbS4G5tuRxTl1MX91UpXQuAzA6Eqag79j eDg2ANXAxQ8FXC5DOxNUHd5zK1/ZS2FfLZdZ7LWtWTGZLAGbiInjFZt5gDbvBMlo842OgD8Tzhy zHI51H0TeW6luiE2Yd21bceghnViojSfJcES2qW6F5ibzEnB0wEKpSIikq4T4yhS+diVUxi2DpD yTJa7fTpC60GJn2kZ4M94bMwEkVEaMJ7k0oFgzotscoOP/BpvlFrKh2ymkD+UHuMMXGQ2bnilM4 Z9dBlFTLV7V6EpJ8Uj0+M0WJEuWRkZNMSQEBVSq0443sY/ych4Z04Cca8092pYdKIsDbPxGfWLR Szys8/RJjGRNPXPwxQIkkTB1d/muuGjeIZvvvRVpn+tEh6BNe7wMYrM4o9D6kpYVxy03cQjg3bq 5rU5tsQyszHC6HOxUcG86WgsGOwwsPnjgku8s9sWPWYvyx X-Received: by 2002:a05:600c:314d:b0:488:bc6a:5285 with SMTP id 5b1f17b1804b1-488bc6a538bmr157487535e9.30.1775738238024; Thu, 09 Apr 2026 05:37:18 -0700 (PDT) Received: from [10.100.51.209] (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488cfa75ae2sm100719905e9.14.2026.04.09.05.37.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Apr 2026 05:37:17 -0700 (PDT) Message-ID: <47cd7c31-c914-433c-82d8-22875c32122c@suse.com> Date: Thu, 9 Apr 2026 14:37:17 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tracing: preserve module tracepoint strings To: Cao Ruichuang Cc: rostedt@goodmis.org, mhiramat@kernel.org, mathieu.desnoyers@efficios.com, mcgrof@kernel.org, da.gomez@kernel.org, samitolvanen@google.com, atomlin@atomlin.com, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-modules@vger.kernel.org References: <20260406170944.51047-1-create0818@163.com> Content-Language: en-US From: Petr Pavlu In-Reply-To: <20260406170944.51047-1-create0818@163.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/6/26 7:09 PM, Cao Ruichuang wrote: > tracepoint_string() is documented as exporting constant strings > through printk_formats, including when it is used from modules. > That currently does not work. > > A small test module that calls > tracepoint_string("tracepoint_string_test_module_string") loads > successfully and gets a pointer back, but the string never appears > in /sys/kernel/tracing/printk_formats. The loader only collects > __trace_printk_fmt from modules and ignores __tracepoint_str. > > Collect module __tracepoint_str entries too, copy them to stable > tracing-managed storage like module trace_printk formats, and let > trace_is_tracepoint_string() recognize those copied strings. This > makes module tracepoint strings visible through printk_formats and > keeps them accepted by the trace string safety checks. The documentation for tracepoint_string() in include/linux/tracepoint.h contains: * The @str used must be a constant string and persistent as it would not * make sense to show a string that no longer exists. But it is still fine * to be used with modules, because when modules are unloaded, if they * had tracepoints, the ring buffers are cleared too. As long as the string * does not change during the life of the module, it is fine to use * tracepoint_string() within a module. The implemented approach copies all strings referenced by __tracepoint_str and keeps them for the kernel's lifetime. I wonder if the code could directly reference the original data and handle its removal when the module is unloaded, or if the quoted comment should be updated to reflect the new behavior. -- Thanks, Petr