Received: by 2002:a05:7412:f589:b0:e2:908c:2ebd with SMTP id eh9csp573091rdb; Tue, 31 Oct 2023 16:16:04 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHeSoEb9y/5wF5YxqirDclYfIuHOOp/SAFNum3vGdM3amxJH2zFnm8Te+gvPUe40jTiXpGT X-Received: by 2002:a05:6808:210d:b0:3ac:aae1:6d64 with SMTP id r13-20020a056808210d00b003acaae16d64mr16810032oiw.2.1698794164428; Tue, 31 Oct 2023 16:16:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698794164; cv=none; d=google.com; s=arc-20160816; b=UNGhI1woRH8J6YEW73MyR/PleW81wppYry+0zNbOMbaQ0kWj1NkQbibvJZ66WRfnN3 fBlSCU/GhSygK+N7NP4G3UWuDj/PfU746i0GWq64k7p/8rip8ierbaGGZzk+9qrOpYKH BUq72TrMVKJWmMVa8wRwcVSYnomtZGp+r0hYMqpqBlUpJCfC4y0s0QvSxt1zHR5Yv5Jv TUk1n/lsR+vKHfXMwlJNhUvwKO3eJ4m1iYiIPvITVIznf1Hhhz/KLZmDVHKjua/El/42 FAcNWiilxIeQIGTTTIgea4THaPB8xB5TmL5JyUu+HfM2cDgs4cBwGnnXUK8/IM6T2Yu+ S8nA== 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=Hyoh5tRZpzGbrN7vcQkEA4yc/Byvl6t44TbHq9ebh3w=; fh=+PXcMeT32B8SgzFrubwLskrVPWEVoEc6q3Pdkyd6ooo=; b=Pt9J3eYnLV0AeAz+RniQAsGAFCJJiXmO8x/k9DCFBgy5ctJTWoWxw4qHRQ0yuyb0l4 15HIwtdsy364a4wJHlwvLuVG2IF8m240Cmw/DPhNJM5iwzpXbkCE3SPugW1aUTyPchmv 3noWfJMApjYR6l9pNEFVa21R9or6PdPpVtzmSI+SPLdpKx/bgtZpD2wH8qtp7CizE6fl QfK5+33YDjf8Cxv/iakrVz2HSQZJT3sBfzizrDlo9I97LKxiEUZGHwb01zYv1ai1dMEI 6eODMIjXcEkgyGZs5+bqrTVR/ohwBObJ6ExdjtlJsyaA3RxBKom/duldjkIHLdNctAW4 1n5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FQVtNDT6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 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 lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id l19-20020a056a0016d300b006be501e37bcsi389586pfc.155.2023.10.31.16.16.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Oct 2023 16:16:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FQVtNDT6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 67BFD807387E; Tue, 31 Oct 2023 16:15:46 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376862AbjJaXPS (ORCPT + 99 others); Tue, 31 Oct 2023 19:15:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234858AbjJaXPQ (ORCPT ); Tue, 31 Oct 2023 19:15:16 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D8D6F3 for ; Tue, 31 Oct 2023 16:15:13 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD56EC433C8; Tue, 31 Oct 2023 23:15:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698794113; bh=pejAIftFE2imDJQpddTcrQQ2QqxCdUUSl8uEj814KDg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FQVtNDT6Ryb9s+ZkcHNKvpyiBy3ZLiy8zXZ+Ba69XXSzqWSnWbkcXZ0wk0xtnXMvN L1X21up2oQfWirzDaxoGHJUaEGGNhxMAvmuLfavOXhqvTs5yJPOsnurYcsVadeeVQ6 KycDFo3V6Uc7SmlEOOLlI1IbGOuy3pdNvl+NEHcrw7yg/obCRyAyltjMcSaryt5Y5e N8PiJ6xATCT7mcxqpzFvWMrTRkjBpidk3K+T4SVxzdwVKwcEnyAxwIpMegkg0r4nfT oRMOk8poIqDn3V5GtXm+M5xjAFVJ79uXMa/bfefIjeo4FknB1W1qK1wsLCWAg0nqmY 0JZtym9UoJV0A== Date: Wed, 1 Nov 2023 08:15:09 +0900 From: Masami Hiramatsu (Google) To: Francis Laniel Cc: LKML , Linux trace kernel , Steven Rostedt , Andrii Nakryiko Subject: Re: [PATCH for-next] tracing/kprobes: Add symbol counting check when module loads Message-Id: <20231101081509.605080231a2736b91331cb85@kernel.org> In-Reply-To: <1868732.tdWV9SEqCh@pwmachine> References: <169854904604.132316.12500381416261460174.stgit@devnote2> <1868732.tdWV9SEqCh@pwmachine> X-Mailer: Sylpheed 3.7.0 (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=-4.7 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 31 Oct 2023 16:15:46 -0700 (PDT) Hi, On Tue, 31 Oct 2023 23:24:43 +0200 Francis Laniel wrote: > > @@ -729,17 +744,55 @@ static int count_mod_symbols(void *data, const char > > *name, unsigned long unused) return 0; > > } > > > > -static unsigned int number_of_same_symbols(char *func_name) > > +static unsigned int number_of_same_symbols(const char *mod, const char > > *func_name) { > > struct sym_count_ctx ctx = { .count = 0, .name = func_name }; > > > > - kallsyms_on_each_match_symbol(count_symbols, func_name, &ctx.count); > > + if (!mod) > > + kallsyms_on_each_match_symbol(count_symbols, func_name, > &ctx.count); > > > > - module_kallsyms_on_each_symbol(NULL, count_mod_symbols, &ctx); > > + module_kallsyms_on_each_symbol(mod, count_mod_symbols, &ctx); > > I may be missing something here or reviewing too quickly. > Wouldn't this function return count to be 0 if func_name is only part of the > module named mod? No, please read below. > Indeed, if the function is not in kernel symbol, > kallsyms_on_each_match_symbol() will not loop. > And, by giving mod to module_kallsyms_on_each_symbol(), the corresponding > module will be skipped, so count_mob_symbols() would not be called. > Hence, we would have 0 as count, which would lead to ENOENT later. Would you mean the case func_name is on the specific module? If 'mod' is specified, module_kallsyms_on_each_symbol() only loops on symbols in the module names 'mod'. int module_kallsyms_on_each_symbol(const char *modname, int (*fn)(void *, const char *, unsigned long), void *data) { struct module *mod; unsigned int i; int ret = 0; mutex_lock(&module_mutex); list_for_each_entry(mod, &modules, list) { struct mod_kallsyms *kallsyms; if (mod->state == MODULE_STATE_UNFORMED) continue; if (modname && strcmp(modname, mod->name)) continue; ... So with above change, 'if mod is not specified, search the symbols in kernel and all modules. If mod is sepecified, search the symbol on the specific module'. Thus, "if func_name is only part of the module named mod", the module_kallsyms_on_each_symbol() will count the 'func_name' in 'mod' module correctly. Thank you, Thank you, -- Masami Hiramatsu (Google)