Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp611071rwl; Thu, 5 Jan 2023 01:55:55 -0800 (PST) X-Google-Smtp-Source: AMrXdXthG/fGbbr6xnDjnQU2WjWKOiwyFemzHOM5H5m7qtjAt+kZSsESO52h6ZKUepBGLykxK3+S X-Received: by 2002:a17:902:8f8a:b0:189:cbf6:9534 with SMTP id z10-20020a1709028f8a00b00189cbf69534mr49022447plo.0.1672912555592; Thu, 05 Jan 2023 01:55:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672912555; cv=none; d=google.com; s=arc-20160816; b=Ye4/fugT4O+WCQ68XavCKNYMR09ruLCTuT1TAqwJNxiWZAQyXDpa1IBjTFy/dUzzl5 vZ5UyfyWRB75YoYiPuJo0AzoepirH/sVmyRxk0Tiqlbei/TcfJvOGbLJB06PwSN6PVoP cb4+XncKPdrY7mnYKsza1WduAdDcQz2cc0X6sm39VjSHr/lG7iYfctV7S0CcMKh0OJcV cTvcsG/IWNQ1sOwKKbs1pZeT0A6XbWjIEOJycrWaVsrFdd4ycwj+fU7304PSGRGCcqdS CVH0ZphuaoJUWLSa+DzKzCuSJ0lCdshFcud7Mw0cmCK8Wn8BtML/4FSrTTnyuZR5Auce Oh3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=GfrBRkojWZ5wSAZVEYUzeElYRu2x1ZaqlGLpQM2iEDg=; b=tV26NsflOVJVaQJnKAxa2XSRQmX/OBQsxVW3i1pO2VgeOkcNd9stzZYKykR+a/4Gv4 DIq511W5wZjjayEi9qCqQWj4L5QYYA7ApQyBUaorOhbx4ZQJEkXk2mqG9WgfeWP4kA6Q l/OO+/f7ptdj0/Sn81Am3Deqkd7O+jHHfqnakw/qU9RlyrlnXbaPlb5jHFoeKCyR4x8X XDP9j9avZE0C4UrL1LcrW00C/0ZmJ/JGSrY3Ez9gWpXnmTx5HVV86Fe+zmlRZHcnuGSk K9DIJUjK4WyCs6aLeFaRY4rmBz0cW6OqoOqVmKqLHHBIk00jDaP6vQNm016ymT7Hjvfc ZnLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=eJ9EewVV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w184-20020a6362c1000000b004403ddda6e6si38930769pgb.847.2023.01.05.01.55.48; Thu, 05 Jan 2023 01:55:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=eJ9EewVV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231768AbjAEJkQ (ORCPT + 57 others); Thu, 5 Jan 2023 04:40:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44950 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230471AbjAEJkN (ORCPT ); Thu, 5 Jan 2023 04:40:13 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 464A9544E1; Thu, 5 Jan 2023 01:40:12 -0800 (PST) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id C97806BCE9; Thu, 5 Jan 2023 09:32:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1672911154; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GfrBRkojWZ5wSAZVEYUzeElYRu2x1ZaqlGLpQM2iEDg=; b=eJ9EewVVG17Zq1paOFU+Vxn1uYwM+B3pteGCxVy2WDcALlOBGhnSTbR3GqbQ97m9Spqdnf Cr/0sZlPnsEW+W4uakHaFRcBJ+XRd/giFZhLF5b42ID3orqUXqNZDCe4LQrlGvsJpMQxYu srnPtSlsEDFGzX7MrqGO5EOEiM67ew4= Received: from suse.cz (unknown [10.100.201.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 639952C16E; Thu, 5 Jan 2023 09:32:34 +0000 (UTC) Date: Thu, 5 Jan 2023 10:32:34 +0100 From: Petr Mladek To: Zhen Lei Cc: Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Joe Lawrence , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Steven Rostedt , Masami Hiramatsu , Mark Rutland , bpf@vger.kernel.org, linux-trace-kernel@vger.kernel.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Luis Chamberlain , linux-modules@vger.kernel.org Subject: Re: [PATCH 2/3] bpf: Optimize get_modules_for_addrs() Message-ID: References: <20221230112729.351-1-thunder.leizhen@huawei.com> <20221230112729.351-3-thunder.leizhen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2023-01-04 17:25:08, Petr Mladek wrote: > On Fri 2022-12-30 19:27:28, Zhen Lei wrote: > > Function __module_address() can quickly return the pointer of the module > > to which an address belongs. We do not need to traverse the symbols of all > > modules to check whether each address in addrs[] is the start address of > > the corresponding symbol, because register_fprobe_ips() will do this check > > later. > > > > Assuming that there are m modules, each module has n symbols on average, > > and the number of addresses 'addrs_cnt' is abbreviated as K. Then the time > > complexity of the original method is O(K * log(K)) + O(m * n * log(K)), > > and the time complexity of current method is O(K * (log(m) + M)), M <= m. > > (m * n * log(K)) / (K * m) ==> n / log2(K). Even if n is 10 and K is 128, > > the ratio is still greater than 1. Therefore, the new method will > > generally have better performance. > > > > Signed-off-by: Zhen Lei > > --- > > kernel/trace/bpf_trace.c | 101 ++++++++++++++++----------------------- > > 1 file changed, 40 insertions(+), 61 deletions(-) > > > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > > index 5f3be4bc16403a5..0ff9037098bd241 100644 > > --- a/kernel/trace/bpf_trace.c > > +++ b/kernel/trace/bpf_trace.c > > @@ -2684,69 +2684,55 @@ static void symbols_swap_r(void *a, void *b, int size, const void *priv) > > } > > } > > > > -struct module_addr_args { > > - unsigned long *addrs; > > - u32 addrs_cnt; > > - struct module **mods; > > - int mods_cnt; > > - int mods_cap; > > -}; > > - > > -static int module_callback(void *data, const char *name, > > - struct module *mod, unsigned long addr) > > +static int get_modules_for_addrs(struct module ***out_mods, unsigned long *addrs, u32 addrs_cnt) > > { > > - struct module_addr_args *args = data; > > - struct module **mods; > > - > > - /* We iterate all modules symbols and for each we: > > - * - search for it in provided addresses array > > - * - if found we check if we already have the module pointer stored > > - * (we iterate modules sequentially, so we can check just the last > > - * module pointer) > > - * - take module reference and store it > > - */ > > - if (!bsearch(&addr, args->addrs, args->addrs_cnt, sizeof(addr), > > - bpf_kprobe_multi_addrs_cmp)) > > - return 0; > > + int i, j, err; > > + int mods_cnt = 0; > > + int mods_cap = 0; > > + struct module *mod; > > + struct module **mods = NULL; > > > > - if (args->mods && args->mods[args->mods_cnt - 1] == mod) > > - return 0; > > + for (i = 0; i < addrs_cnt; i++) { > > + mod = __module_address(addrs[i]); > > This must be called under module_mutex to make sure that the module > would not disappear. > > > + if (!mod) > > + continue; > > > > - if (args->mods_cnt == args->mods_cap) { > > - args->mods_cap = max(16, args->mods_cap * 3 / 2); > > - mods = krealloc_array(args->mods, args->mods_cap, sizeof(*mods), GFP_KERNEL); > > - if (!mods) > > - return -ENOMEM; > > - args->mods = mods; > > - } > > + /* check if we already have the module pointer stored */ > > + for (j = 0; j < mods_cnt; j++) { > > + if (mods[j] == mod) > > + break; > > + } > > This might get optimized like the original code. > > My understanding is that the addresses are sorted in "addrs" array. > So, the address is either part of the last found module or it belongs > to a completely new module. I thought more about it and I think that I was wrong, see below. > for (i = 0; i < addrs_cnt; i++) { > /* > * The adresses are sorted. The adress either belongs > * to the last found module or a new one. > * > * This is safe because we already have reference > * on the found modules. > */ > if (mods_cnt && within_module(addrs[i], mods[mods_cnt - 1])) > continue; within_module() checks two sections (init and core). They are allocated separately, see module_alloc() called in move_module(). There might be a section from another modules between the init and core section of a module. The optimization worked in the original code because module_kallsyms_on_each_symbol() always iterated over all symbols from a module. That said, I am not sure if bpf trace might be added for symbols in the module init section. But it might be better to stay on the safe side. Best Regards, Petr