[PATCH 02/13] mm/vma: update do_mmap() to use vma_flags_t
Lance Yang
lance.yang at linux.dev
Thu Jul 2 08:08:32 PDT 2026
On 2026/7/2 22:16, Lorenzo Stoakes wrote:
> On Thu, Jul 02, 2026 at 07:15:31PM +0800, Lance Yang wrote:
[...]
>>
>> [...]
>>> diff --git a/mm/mmap.c b/mm/mmap.c
>>> index 46174e706bbe..547352183214 100644
>>> --- a/mm/mmap.c
>>> +++ b/mm/mmap.c
>> [...]
>>> @@ -488,23 +496,27 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
>>> * Check to see if we are violating any seals and update VMA
>>> * flags if necessary to avoid future seal violations.
>>> */
>>> - err = memfd_check_seals_mmap(file, &vm_flags);
>>> + err = memfd_check_seals_mmap(file, &vma_flags);
>>> if (err)
>>> return (unsigned long)err;
>>> } else {
>>> switch (flags & MAP_TYPE) {
>>> case MAP_SHARED:
>>> - if (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))
>>> + if (vma_flags_can_grow(&vma_flags))
>>> return -EINVAL;
>>> /*
>>> * Ignore pgoff.
>>> */
>>> pgoff = 0;
>>> - vm_flags |= VM_SHARED | VM_MAYSHARE;
>>> + vma_flags_set(&vma_flags, VMA_SHARED_BIT, VMA_MAYSHARE_BIT);
>>> break;
>>> - case MAP_DROPPABLE:
>>> - if (VM_DROPPABLE == VM_NONE)
>>> + case MAP_DROPPABLE: {
>>> + vma_flags_t droppable = VMA_DROPPABLE;
>>> +
>>> + if (vma_flags_empty(&droppable))
>>> return -EOPNOTSUPP;
>>> + vma_flags_set_mask(&vma_flags, droppable);
>>> +
>>> /*
>>> * A locked or stack area makes no sense to be droppable.
>>> *
>>> @@ -515,23 +527,24 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
>>> */
>>> if (flags & (MAP_LOCKED | MAP_HUGETLB))
>>> return -EINVAL;
>>> - if (vm_flags & (VM_GROWSDOWN | VM_GROWSUP))
>>> + if (vma_flags_can_grow(&vma_flags))
>>> return -EINVAL;
>>>
>>> - vm_flags |= VM_DROPPABLE;
>>
>> Old code checked VM_GROWSDOWN|VM_GROWSUP before seting VM_DROPPABLE. New
>> code flips that around. Hmm, shouldn't master, just made me look twice ;)
>>
>> Maybe keep old order?
>
> I guess I feared that defining droppable above then referencing it below would
> be less clear?
>
> Can move if you feel strongly about it, and sorry for making the move at the
> same time as the general vm_flags_t -> vma_flags_t refactor as it does make that
> less clear...
No need to churn just for me. Thanks :)
More information about the Linux-rockchip
mailing list