[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bd4ed630-b370-4dea-aa19-5c3797106dce@redhat.com>
Date: Wed, 26 Nov 2025 07:16:46 +0100
From: Viktor Malik <vmalik@...hat.com>
To: Sami Tolvanen <samitolvanen@...gle.com>
Cc: bpf@...r.kernel.org, Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
<martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>,
Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
Jiri Olsa <jolsa@...nel.org>, Jamal Hadi Salim <jhs@...atatu.com>,
Cong Wang <xiyou.wangcong@...il.com>, Jiri Pirko <jiri@...nulli.us>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor
kfunc type
On 11/25/25 21:16, Sami Tolvanen wrote:
> Hi Viktor,
>
> On Fri, Nov 21, 2025 at 8:06 AM Viktor Malik <vmalik@...hat.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@...hat.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
>
Powered by blists - more mailing lists