Re: [PATCH bpf-next v2 1/2] bpf: Disallow BPF_F_LOCK with mixed special fields and centralize flag checks

[Leon Hwang <leon.hwang@linux.dev>]

On 28/1/26 23:22, Leon Hwang wrote:
> 
> 
> On 2026/1/28 10:27, Kumar Kartikeya Dwivedi wrote:
>> On Fri, 23 Jan 2026 at 06:58, Leon Hwang <leon.hwang@linux.dev> wrote:
>>>
>>> Disallow combining BPF_F_LOCK with map values that contain special BTF
>>> fields other than bpf_spin_lock (e.g. kptr or uptr). Such mixing may lead
>>> to subtle or undefined behavior in map value handling. Reject these
>>> combinations early by returning -EOPNOTSUPP.
>>
>> The commit log is really suboptimal in giving context on why you're doing this.
>> You should summarize the discussion from [0], otherwise unless people
>> go dig that thread they'd have no clue.
>>
>> Also, I would remove the 'undefined behavior' wording. It's just
>> semantically different, in that the update doesn't free fields,
>> but there's no undefined behavior.
>>
>>   [0]: https://lore.kernel.org/bpf/CAADnVQLib8ebe8cmGRj98YZiArendX8u=dSKNUrUFz6NGq7LRg@mail.gmail.com
>>

Hi Martin,

Do you recall the original reasoning for disallowing BPF_F_LOCK together
with BPF_UPTR in 'bpf_task_storage.c::bpf_pid_task_storage_update_elem()'?

I didn’t find an explicit explanation in the commit message of
ba512b00e5ef (“bpf: Add uptr support in the map_value of the task local
storage”), and I’m trying to better understand the underlying concern.

This is in the context of addressing Alexei’s comment in the linked
discussion: I’d like to clearly articulate the risks of mixing
BPF_F_LOCK with other special fields, rather than relying on vague
phrasing.

Thanks,
Leon