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 <[email protected]> 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=dsknurufz6ngq7...@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
