All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: <bpf@vger.kernel.org>, "Andrii Nakryiko" <andrii@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Eduard Zingerman" <eddyz87@gmail.com>,
	"Emil Tsalapatis" <emil@etsalapatis.com>,
	"Ihor Solodrai" <ihor.solodrai@linux.dev>,
	"Tejun Heo" <tj@kernel.org>, <kkd@meta.com>,
	<kernel-team@meta.com>
Subject: Re: [PATCH bpf-next v3 06/15] bpf: Recognize __nullable on pointer members of kernel structs
Date: Fri, 16 Oct 2026 01:31:26 +0000	[thread overview]
Message-ID: <DM5VHTPNK75L.25IC5ASG1QDJ9@gmail.com> (raw)
In-Reply-To: <CAP01T743a5wuvP=5cc8Aqb=PHGhSFWcir0sCSWMvMT_=gk8Kjw@mail.gmail.com>

On Fri Oct 16, 2026 at 1:24 AM UTC, Kumar Kartikeya Dwivedi wrote:
> On Fri, 16 Oct 2026 at 03:10, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> On Fri, Oct 16, 2026 at 01:41 AM Kumar Kartikeya Dwivedi <memxor@gmail.com> wrote:
>> > it on, as the tag says. A tagged member of an existing struct thus asks
>> > every program that reads it for a check, including one that reads it
>> > through a probed pointer and relied on a NULL dereference reading as
>> > zero.
>>
>> Commit log reads like BTF_TYPE_SAFE_*() can go away one day,
>> but with this change adding __nullable to a member of task_struct
>> breaks every tracing prog that walks through it without a check.
>> So the tag cannot be added to existing structs and
>> BTF_TYPE_SAFE_*_OR_NULL lists are here to stay, right?
>>
>
> Well, BTF_TYPE_SAFE_*_OR_NULL also enforces a NULL check, so not clear
> to me how using the annotation over that will break a program (see
> type_is_trusted_or_null() usage). The only difference is that this
> annotation works with type tags applied directly on the struct.
>
> The only reason I did not drop those macros yet is because our
> baseline GCC version does not support type tags, once we move to that
> point we can drop both the macros, rework kfunc suffixes, etc.
> sched_ext is fine taking that dependency. The tag when specified on a
> struct member directly will do the right thing, just like
> BTF_TYPE_SAFE_*_OR_NULL does.

Got it.
Can we start moving into this direction?
At least for clang compiled kernels we can drop BTF_TYPE_SAFE_*_OR_NULL ?

  reply	other threads:[~2026-10-16  1:31 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 23:41 [PATCH bpf-next v3 00/15] Fix some arena paper cuts Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 01/15] bpf: Compute the program digest before resolving the fd_array Kumar Kartikeya Dwivedi
2026-10-16  0:28   ` bot+bpf-ci
2026-10-15 23:41 ` [PATCH bpf-next v3 02/15] selftests/bpf: Bind an exclusive map through a continuous fd_array Kumar Kartikeya Dwivedi
2026-10-15 23:53   ` sashiko-bot
2026-10-16  0:00     ` Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 03/15] libbpf: Keep the fd_array fill index out of bpf_program__clone() Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 04/15] selftests/bpf: Clone a program that calls a module kfunc Kumar Kartikeya Dwivedi
2026-10-16  0:12   ` bot+bpf-ci
2026-10-15 23:41 ` [PATCH bpf-next v3 05/15] compiler_types: Add __arena and __nullable BTF type tag qualifiers Kumar Kartikeya Dwivedi
2026-10-16  1:08   ` Alexei Starovoitov
2026-10-16  1:15     ` Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 06/15] bpf: Recognize __nullable on pointer members of kernel structs Kumar Kartikeya Dwivedi
2026-10-15 23:54   ` sashiko-bot
2026-10-16  0:00     ` Kumar Kartikeya Dwivedi
2026-10-16  1:09   ` Alexei Starovoitov
2026-10-16  1:24     ` Kumar Kartikeya Dwivedi
2026-10-16  1:31       ` Alexei Starovoitov [this message]
2026-10-15 23:41 ` [PATCH bpf-next v3 07/15] bpf: Turn loads of __arena pointer members into arena pointers Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 08/15] selftests/bpf: Test __nullable pointer members Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 09/15] selftests/bpf: Test __arena " Kumar Kartikeya Dwivedi
2026-10-16  1:11   ` Alexei Starovoitov
2026-10-15 23:41 ` [PATCH bpf-next v3 10/15] libbpf: Bind the arena of an object to every program in it Kumar Kartikeya Dwivedi
2026-10-16  0:28   ` bot+bpf-ci
2026-10-15 23:41 ` [PATCH bpf-next v3 11/15] selftests/bpf: Test arena binding by libbpf Kumar Kartikeya Dwivedi
2026-10-16  0:28   ` bot+bpf-ci
2026-10-15 23:41 ` [PATCH bpf-next v3 12/15] bpf: Set up the arena base only in functions that use it Kumar Kartikeya Dwivedi
2026-10-16  1:13   ` Alexei Starovoitov
2026-10-15 23:41 ` [PATCH bpf-next v3 13/15] libbpf: Render the arena type tag with its address space Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 14/15] selftests/bpf: Test the address space rendering of the arena type tag Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 15/15] selftests/bpf: Test an arena kfunc argument passed from a subprogram Kumar Kartikeya Dwivedi

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=DM5VHTPNK75L.25IC5ASG1QDJ9@gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=kernel-team@meta.com \
    --cc=kkd@meta.com \
    --cc=memxor@gmail.com \
    --cc=tj@kernel.org \
    /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.