All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Bobrowski <mattbobrowski@google.com>
To: Shung-Hsi Yu <shung-hsi.yu@suse.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>,
	bpf@vger.kernel.org, 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 <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	David Vernet <void@manifault.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH bpf-next] bpf: use type_may_be_null() helper for nullable-param check
Date: Thu, 5 Sep 2024 08:00:09 +0000	[thread overview]
Message-ID: <ZtllCZOrO9b-MDtE@google.com> (raw)
In-Reply-To: <20240905055233.70203-1-shung-hsi.yu@suse.com>

On Thu, Sep 05, 2024 at 01:52:32PM +0800, Shung-Hsi Yu wrote:
> Commit 980ca8ceeae6 ("bpf: check bpf_dummy_struct_ops program params for
> test runs") does bitwise AND between reg_type and PTR_MAYBE_NULL, which
> is correct, but due to type difference the compiler complains:
> 
>   net/bpf/bpf_dummy_struct_ops.c:118:31: warning: bitwise operation between different enumeration types ('const enum bpf_reg_type' and 'enum bpf_type_flag') [-Wenum-enum-conversion]
>     118 |                 if (info && (info->reg_type & PTR_MAYBE_NULL))
>         |                              ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
> 
> Workaround the warning by moving the type_may_be_null() helper from
> verifier.c into bpf_verifier.h, and reuse it here to check whether param
> is nullable.
> 
> Fixes: 980ca8ceeae6 ("bpf: check bpf_dummy_struct_ops program params for test runs")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202404241956.HEiRYwWq-lkp@intel.com/
> Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
> ---
> Due to kernel test bot not setting the correct email header
> (reported[1]) Eduard probably never saw the report about the warning
> (nor did it show up on Patchwork).
> 
> 1: https://github.com/intel/lkp-tests/issues/383
> ---
>  include/linux/bpf_verifier.h   | 5 +++++
>  kernel/bpf/verifier.c          | 5 -----
>  net/bpf/bpf_dummy_struct_ops.c | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index 8458632824a4..4513372c5bc8 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -927,6 +927,11 @@ static inline bool type_is_sk_pointer(enum bpf_reg_type type)
>  		type == PTR_TO_XDP_SOCK;
>  }
>  
> +static inline bool type_may_be_null(u32 type)
> +{
> +	return type & PTR_MAYBE_NULL;
> +}
> +
>
>  static inline void mark_reg_scratched(struct bpf_verifier_env *env, u32 regno)
>  {
>  	env->scratched_regs |= 1U << regno;
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index b806afeba212..53d0556fbbf3 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -383,11 +383,6 @@ static void verbose_invalid_scalar(struct bpf_verifier_env *env,
>  	verbose(env, " should have been in [%d, %d]\n", range.minval, range.maxval);
>  }
>  
> -static bool type_may_be_null(u32 type)
> -{
> -	return type & PTR_MAYBE_NULL;
> -}
> -
>  static bool reg_not_null(const struct bpf_reg_state *reg)
>  {
>  	enum bpf_reg_type type;
> diff --git a/net/bpf/bpf_dummy_struct_ops.c b/net/bpf/bpf_dummy_struct_ops.c
> index 3ea52b05adfb..f71f67c6896b 100644
> --- a/net/bpf/bpf_dummy_struct_ops.c
> +++ b/net/bpf/bpf_dummy_struct_ops.c
> @@ -115,7 +115,7 @@ static int check_test_run_args(struct bpf_prog *prog, struct bpf_dummy_ops_test_
>  
>  		offset = btf_ctx_arg_offset(bpf_dummy_ops_btf, func_proto, arg_no);
>  		info = find_ctx_arg_info(prog->aux, offset);
> -		if (info && (info->reg_type & PTR_MAYBE_NULL))
> +		if (info && type_may_be_null(info->reg_type))

Maybe as part of this clean up, we should also consider replacing all
the open-coded & PTR_MAYBE_NULL checks with type_may_be_null() which
we have sprinkled throughout kernel/bpf/verifier.c?

/M

  reply	other threads:[~2024-09-05  8:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-05  5:52 [PATCH bpf-next] bpf: use type_may_be_null() helper for nullable-param check Shung-Hsi Yu
2024-09-05  8:00 ` Matt Bobrowski [this message]
2024-09-06  2:10   ` Shung-Hsi Yu
2024-09-05 19:08 ` Eduard Zingerman
2024-09-05 20:40 ` patchwork-bot+netdevbpf

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=ZtllCZOrO9b-MDtE@google.com \
    --to=mattbobrowski@google.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=eddyz87@gmail.com \
    --cc=edumazet@google.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=martin.lau@linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=shung-hsi.yu@suse.com \
    --cc=song@kernel.org \
    --cc=void@manifault.com \
    --cc=yonghong.song@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.