On 10/12/26 17:55, Lorenzo Stoakes (ARM) wrote:
> On Mon, Oct 12, 2026 at 05:08:09PM +0200, David Hildenbrand (Arm) wrote:
>> On 10/9/26 20:04, Lorenzo Stoakes (ARM) wrote:
>
>>> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
>>> index 7b6847200b43..b69fe5e34339 100644
>>> --- a/kernel/bpf/arena.c
>>> +++ b/kernel/bpf/arena.c
>>> @@ -620,8 +620,9 @@ static int arena_map_mmap(struct bpf_map *map, struct
>>> vm_area_struct *vma)
>>> * clears VM_MAYEXEC. Set VM_DONTEXPAND to avoid potential change
>>> * of user_vm_start. Set VM_DONTCOPY to prevent arena VMA from
>>> * being copied into the child process on fork.
>>> + * This is a kernel page so set VM_MIXEDMAP.
>>> */
>>> - vm_flags_set(vma, VM_DONTEXPAND | VM_DONTCOPY);
>>> + vm_flags_set(vma, VM_MIXEDMAP | VM_DONTEXPAND | VM_DONTCOPY);
>>> vma->vm_ops = &arena_vm_ops;
>>> return 0;
>>> }
>>>
>>
>> Historically, VM_MIXEDMAP really just means: can contain refcounted and
>> non-refcounted things. Everything with a struct page is refcounted.
>>
>> I think we are now changing the semantics to mean "maps kernel pages". I
>> think
>
> Yes.
>
> It was sort of implicit before given insert_page() etc. but still really
> meaning
> that it _might_ be both.
Yeah, it's in the name. Mixed: pfn and/or ordinary.
>
>> this is fine, but we really have to update the documentation (and possibly
>> rename this thing to something more expressive?)
>
> Yeah I completely agree.
>
> I will rename it, but I think that's best for 7.5 obviously! :)
Yes.
VM_PFNMAP / VM_MIXEDMAP - These contain kernel-mapped data which cannot be
reasonably reconstructed on page fault.
the description is already pretty clear. just not that kernel-mapped pages
*must* use one of these.
(again, the ->fault thing returning allcoated kernel memory is nasty)
--
Cheers,
David
