BPF List
 help / color / mirror / Atom feed
From: Martin KaFai Lau <martin.lau@linux.dev>
To: thinker.li@gmail.com
Cc: sinquersw@gmail.com, kuifeng@meta.com, bpf@vger.kernel.org,
	ast@kernel.org, song@kernel.org, kernel-team@meta.com,
	andrii@kernel.org, davemarchevsky@meta.com, dvernet@meta.com
Subject: Re: [RFC bpf-next] bpf, selftests/bpf: Support PTR_MAYBE_NULL for struct_ops arguments.
Date: Wed, 10 Jan 2024 15:44:30 -0800	[thread overview]
Message-ID: <55ada30c-039d-4121-a4d2-efda578f600f@linux.dev> (raw)
In-Reply-To: <20240110221750.798813-1-thinker.li@gmail.com>

On 1/10/24 2:17 PM, thinker.li@gmail.com wrote:
> The proposed solution here is to add PTR_MAYBE_NULL annotations to
> arguments

[ ... ]

> == Future Work ==
> 
> We require an improved method for annotating arguments. Initially, we
> anticipated annotating arguments by appending a suffix to argument names,
> such as arg1__maybe_null. However, this approach does not function for
> function pointers due to compiler limitations. Nevertheless, it does work
> for functions. To resolve this, we need compiler support to enable the
> inclusion of argument names in the DWARF for function pointer types.

After reading the high level of the patch,
while it needs compiler work to support decl tagging (or arg name) in a 
struct_ops's func_proto, changing the info->reg_type of a struct_ops's argument 
have been doable in the ".is_valid_access" without new kernel code change in 
verifier/btf.c.

Take a look at the bpf_tcp_ca_is_valid_access() which promotes the info->btf_id 
to "struct tcp_sock". The same could be done for info->reg_type (e.g. adding 
PTR_MAYBE_NULL).

  reply	other threads:[~2024-01-10 23:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-10 22:17 [RFC bpf-next] bpf, selftests/bpf: Support PTR_MAYBE_NULL for struct_ops arguments thinker.li
2024-01-10 23:44 ` Martin KaFai Lau [this message]
2024-01-11  1:50   ` Kui-Feng Lee
2024-01-11 19:08     ` Martin KaFai Lau
2024-01-12  0:30       ` Yonghong Song
2024-01-12  0:35       ` Kui-Feng Lee

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=55ada30c-039d-4121-a4d2-efda578f600f@linux.dev \
    --to=martin.lau@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=davemarchevsky@meta.com \
    --cc=dvernet@meta.com \
    --cc=kernel-team@meta.com \
    --cc=kuifeng@meta.com \
    --cc=sinquersw@gmail.com \
    --cc=song@kernel.org \
    --cc=thinker.li@gmail.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