bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	bpf@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
	Luis Chamberlain <mcgrof@kernel.org>,
	linux-modules@vger.kernel.org
Subject: Re: [PATCH 2/3] bpf: Optimize get_modules_for_addrs()
Date: Thu, 5 Jan 2023 10:32:34 +0100	[thread overview]
Message-ID: <Y7aZMkgVgl28Jgmv@alley> (raw)
In-Reply-To: <Y7WoZARt37xGpjXD@alley>

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 <thunder.leizhen@huawei.com>
> > ---
> >  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

  parent reply	other threads:[~2023-01-05  9:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30 11:27 [PATCH 0/3] kallsyms: Optimize the search for module symbols by livepatch and bpf Zhen Lei
2022-12-30 11:27 ` [PATCH 1/3] livepatch: Improve the search performance of module_kallsyms_on_each_symbol() Zhen Lei
2023-01-04 15:36   ` Petr Mladek
2022-12-30 11:27 ` [PATCH 2/3] bpf: Optimize get_modules_for_addrs() Zhen Lei
2023-01-04 16:25   ` Petr Mladek
2023-01-04 17:07     ` Song Liu
2023-01-05  7:31       ` Leizhen (ThunderTown)
2023-01-05  9:05       ` Petr Mladek
2023-01-09  4:02         ` Leizhen (ThunderTown)
2023-01-05  7:48     ` Leizhen (ThunderTown)
2023-01-05  9:32     ` Petr Mladek [this message]
2023-01-09  4:10       ` Leizhen (ThunderTown)
2023-01-05 21:31     ` Jiri Olsa
2023-01-06  9:45       ` Jiri Olsa
2023-01-09  8:51         ` Leizhen (ThunderTown)
2023-01-09 13:48           ` Jiri Olsa
2023-01-09 15:11             ` Leizhen (ThunderTown)
2023-01-11  8:41               ` Leizhen (ThunderTown)
2023-01-11  9:53                 ` Jiri Olsa
2023-01-09  7:03       ` Leizhen (ThunderTown)
2022-12-30 11:27 ` [PATCH 3/3] kallsyms: Delete an unused parameter related to {module_}kallsyms_on_each_symbol() Zhen Lei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y7aZMkgVgl28Jgmv@alley \
    --to=pmladek@suse.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=martin.lau@linux.dev \
    --cc=mbenes@suse.cz \
    --cc=mcgrof@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=thunder.leizhen@huawei.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).