From: Slava Imameev <slava.imameev@crowdstrike.com>
To: <alexei.starovoitov@gmail.com>
Cc: <andrii@kernel.org>, <ast@kernel.org>, <bot+bpf-ci@kernel.org>,
<bpf@vger.kernel.org>, <clm@meta.com>, <daniel@iogearbox.net>,
<davem@davemloft.net>, <eddyz87@gmail.com>, <edumazet@google.com>,
<haoluo@google.com>, <horms@kernel.org>,
<ihor.solodrai@linux.dev>, <john.fastabend@gmail.com>,
<jolsa@kernel.org>, <kpsingh@kernel.org>, <kuba@kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-kselftest@vger.kernel.org>,
<linux-open-source@crowdstrike.com>, <martin.lau@kernel.org>,
<martin.lau@linux.dev>, <netdev@vger.kernel.org>,
<pabeni@redhat.com>, <sdf@fomichev.me>, <shuah@kernel.org>,
<slava.imameev@crowdstrike.com>, <song@kernel.org>,
<yonghong.song@linux.dev>
Subject: Re: Re: [PATCH bpf-next v3 1/2] bpf: Support multi-level pointer params via SCALAR_VALUE for trampolines
Date: Tue, 24 Feb 2026 08:23:33 +1100 [thread overview]
Message-ID: <20260223212333.11438-1-slava.imameev@crowdstrike.com> (raw)
In-Reply-To: <CAADnVQ+okfKHvKzCy9vLQkpevhvHMFXhincqmFOQX9zN_vtQyA@mail.gmail.com>
Alexei Starovoitov <ast@kernel.org> wrote:
> On Mon, Feb 23, 2026 at 2:48=E2=80=AFAM Slava Imameev
> <slava.imameev@crowdstrike.com> wrote:
> >
> > I think support for broader types can be provided in a compatible way
> > with future annotated support, as I explained in my reply to the v2
> > review:
> >
> > "
> > > so I suggest treating 'void **' as a scalar as Eduard suggested.
> > > This particular sb_eat_lsm_opts() hook
> > > doesn't have a useful type behind it anyway.
> > > I'm less certain about 'char **'. If we make it scalar too
> > > it will be harder to make it a pointer to nul terminated string later=
> .
> >
> > > So I would do 'void **' -> scalar for now only.
> >
> > I changed to scalar in v3, keeping broader scope for pointer types.
> >
> > We encountered double pointers of various types that required
> > workarounds, such as:
> >
> > int __posix_acl_chmod(struct posix_acl **acl, gfp_t gfp, umode_t mode)
> >
> > Adding support for void** alone doesn't address the broader issue
> > with other double pointer types.
> >
> > When annotated array support (including char**) is added in the
> > future, it should remain compatible with the scalar approach for
> > legacy (unannotated) parameters. Unannotated parameters will
> > continue using scalar handling.
> > "
>
> but then there is no need to relax it for double pointers only.
>
> - if (is_void_or_int_ptr(btf, t))
> + if (is_void_or_int_ptr(btf, t) || !btf_type_is_struct_ptr(btf, t))
>
> would make 'scalar' a fallback for anything unrecognized,
> and we can argue that making it smarter in the future
> maybe hopefully won't break progs.
I can increase coverage to anything that's not a pointer to structure.
I added support only for multi-level pointers of any type because
we needed workarounds for them in our development. This was the real
case we encountered in practice.
Multi-level pointers support appears to be a safe extension since any
future support for arrays and output values would require annotation
(similar to Microsoft SAL), which differentiates between current
unannotated scalar cases and new annotated cases.
next prev parent reply other threads:[~2026-02-23 21:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 8:31 [PATCH bpf-next v3 0/2] bpf: Add multi-level pointer parameter support " Slava Imameev
2026-02-23 8:31 ` [PATCH bpf-next v3 1/2] bpf: Support multi-level pointer params via SCALAR_VALUE " Slava Imameev
2026-02-23 9:06 ` bot+bpf-ci
2026-02-23 10:47 ` Slava Imameev
2026-02-23 16:58 ` Alexei Starovoitov
2026-02-23 21:23 ` Slava Imameev [this message]
2026-02-23 8:31 ` [PATCH bpf-next v3 2/2] selftests/bpf: Add trampolines multi-level pointer params test coverage Slava Imameev
2026-02-23 16:38 ` Alexei Starovoitov
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=20260223212333.11438-1-slava.imameev@crowdstrike.com \
--to=slava.imameev@crowdstrike.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=horms@kernel.org \
--cc=ihor.solodrai@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-open-source@crowdstrike.com \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®