From: Viktor Malik <vmalik@redhat.com>
To: Sami Tolvanen <samitolvanen@google.com>
Cc: bpf@vger.kernel.org, Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, 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>, Jamal Hadi Salim <jhs@mojatatu.com>,
Cong Wang <xiyou.wangcong@gmail.com>,
Jiri Pirko <jiri@resnulli.us>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type
Date: Wed, 26 Nov 2025 07:16:46 +0100 [thread overview]
Message-ID: <bd4ed630-b370-4dea-aa19-5c3797106dce@redhat.com> (raw)
In-Reply-To: <CABCJKudpUh7i9PTWV_k5ZWehkyRvHcRTwSOWQu_1yjCE9h_bTg@mail.gmail.com>
On 11/25/25 21:16, Sami Tolvanen wrote:
> Hi Viktor,
>
> On Fri, Nov 21, 2025 at 8:06 AM Viktor Malik <vmalik@redhat.com> wrote:
>>
>> On 7/28/25 22:26, Sami Tolvanen wrote:
>>> With CONFIG_CFI_CLANG enabled, the kernel strictly enforces that
>>> indirect function calls use a function pointer type that matches the
>>> target function. I ran into the following type mismatch when running
>>> BPF self-tests:
>>>
>>> CFI failure at bpf_obj_free_fields+0x190/0x238 (target:
>>> bpf_crypto_ctx_release+0x0/0x94; expected type: 0xa488ebfc)
>>> Internal error: Oops - CFI: 00000000f2008228 [#1] SMP
>>> ...
>>>
>>> As bpf_crypto_ctx_release() is also used in BPF programs and using
>>> a void pointer as the argument would make the verifier unhappy, add
>>> a simple stub function with the correct type and register it as the
>>> destructor kfunc instead.
>>
>> Hi,
>>
>> this patchset got somehow forgotten and I'd like to revive it.
>>
>> We're hitting kernel oops when running the crypto cases from test_progs
>> (`./test_progs -t crypto`) on CPUs with IBT (Indirect Branch Tracking)
>> support. I managed to reproduce this on the latest bpf-next, see the
>> relevant part of dmesg at the end of this email.
>>
>> After applying this patch, the oops no longer happens.
>>
>> It looks like the series is stuck on a sparse warning reported by kernel
>> test robot, which seems like a false positive. Could we somehow resolve
>> it and proceed with reviewing and merging this?
>
> I agree, it does look like a false positive.
>
>> Since this resolves our issue, adding my tested-by:
>>
>> Tested-by: Viktor Malik <vmalik@redhat.com>
>
> Thanks for testing! I can resend this series when I have a chance to
> put it back in the review queue. The CFI config option also changed
> from CONFIG_CFI_CLANG to just CONFIG_CFI since this was sent, so the
> commit message could use an update too.
That would be very useful, thanks Sami!
Viktor
>
> Sami
>
next prev parent reply other threads:[~2025-11-26 6:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-28 20:26 [PATCH bpf-next v3 0/4] Use correct destructor kfunc types Sami Tolvanen
2025-07-28 20:26 ` [PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type Sami Tolvanen
2025-07-28 23:07 ` Yonghong Song
2025-07-29 17:54 ` kernel test robot
2025-07-29 18:17 ` Sami Tolvanen
2025-11-21 16:06 ` Viktor Malik
2025-11-25 20:16 ` Sami Tolvanen
2025-11-26 6:16 ` Viktor Malik [this message]
2025-07-28 20:26 ` [PATCH bpf-next v3 2/4] bpf: net_sched: " Sami Tolvanen
2025-07-28 23:08 ` Yonghong Song
2025-07-28 20:27 ` [PATCH bpf-next v3 3/4] selftests/bpf: " Sami Tolvanen
2025-07-28 23:08 ` Yonghong Song
2025-07-28 20:27 ` [PATCH bpf-next v3 4/4] bpf, btf: Enforce destructor kfunc type with CFI Sami Tolvanen
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=bd4ed630-b370-4dea-aa19-5c3797106dce@redhat.com \
--to=vmalik@redhat.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=vadim.fedorenko@linux.dev \
--cc=xiyou.wangcong@gmail.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 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®