Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Thu, 12 May 2022 10:05:22 -0700
From:   David Vernet <void@manifault.com>
To:     Wan Jiabing <wanjiabing@vivo.com>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Ingo Molnar <mingo@redhat.com>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Martin KaFai Lau <kafai@fb.com>,
        Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
        John Fastabend <john.fastabend@gmail.com>,
        KP Singh <kpsingh@kernel.org>, netdev@vger.kernel.org,
        bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] bpf: use 'error_xxx' tags in
 bpf_kprobe_multi_link_attach
Message-ID: <20220512170522.3e47hwj53plhr4qq@dev0025.ash9.facebook.com>
References: <20220512141710.116135-1-wanjiabing@vivo.com>
 <20220512141710.116135-2-wanjiabing@vivo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220512141710.116135-2-wanjiabing@vivo.com>
User-Agent: NeoMutt/20211029
Precedence: bulk

On Thu, May 12, 2022 at 10:17:08PM +0800, Wan Jiabing wrote:
> Use 'error_addrs', 'error_cookies' and 'error_link' tags to make error
> handling more efficient.

Can you add a bit more context to this commit summary? The added goto
labels aren't what make the code more performant, it's the avoidance of
unnecessary free calls on NULL pointers that (supposedly) does.

> 
> Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
> ---
>  kernel/trace/bpf_trace.c | 20 +++++++++++---------
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 2eaac094caf8..3a8b69ef9a0d 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -2467,20 +2467,20 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
>  	if (uaddrs) {
>  		if (copy_from_user(addrs, uaddrs, size)) {
>  			err = -EFAULT;
> -			goto error;
> +			goto error_addrs;
>  		}
>  	} else {
>  		struct user_syms us;
>  
>  		err = copy_user_syms(&us, usyms, cnt);
>  		if (err)
> -			goto error;
> +			goto error_addrs;
>  
>  		sort(us.syms, cnt, sizeof(*us.syms), symbols_cmp, NULL);
>  		err = ftrace_lookup_symbols(us.syms, cnt, addrs);
>  		free_user_syms(&us);
>  		if (err)
> -			goto error;
> +			goto error_addrs;
>  	}
>  
>  	ucookies = u64_to_user_ptr(attr->link_create.kprobe_multi.cookies);
> @@ -2488,18 +2488,18 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
>  		cookies = kvmalloc(size, GFP_KERNEL);
>  		if (!cookies) {
>  			err = -ENOMEM;
> -			goto error;
> +			goto error_addrs;
>  		}
>  		if (copy_from_user(cookies, ucookies, size)) {
>  			err = -EFAULT;
> -			goto error;
> +			goto error_cookies;
>  		}
>  	}
>  
>  	link = kzalloc(sizeof(*link), GFP_KERNEL);
>  	if (!link) {
>  		err = -ENOMEM;
> -		goto error;
> +		goto error_cookies;
>  	}
>  
>  	bpf_link_init(&link->link, BPF_LINK_TYPE_KPROBE_MULTI,
> @@ -2507,7 +2507,7 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
>  
>  	err = bpf_link_prime(&link->link, &link_primer);
>  	if (err)
> -		goto error;
> +		goto error_link;
>  
>  	if (flags & BPF_F_KPROBE_MULTI_RETURN)
>  		link->fp.exit_handler = kprobe_multi_link_handler;
> @@ -2539,10 +2539,12 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
>  
>  	return bpf_link_settle(&link_primer);
>  
> -error:
> +error_link:
>  	kfree(link);
> -	kvfree(addrs);
> +error_cookies:
>  	kvfree(cookies);
> +error_addrs:
> +	kvfree(addrs);
>  	return err;
>  }
>  #else /* !CONFIG_FPROBE */
> -- 
> 2.35.1
> 

Could you clarify what performance gains you observed from doing this? I
wouldn't have expected avoiding a couple of calls and NULL checks to have a
measurable impact on performance, and I'm wondering whether the complexity
from having multiple goto labels is really worth any supposed performance
gains.

Thanks,
David