Re: [PATCH 1/2] mm: fix mmap errno value when MAP_DROPPABLE is not supported

From: David Hildenbrand (Arm)

Date: Tue Apr 14 2026 - 04:17:15 EST


On 4/14/26 02:43, anthony.yznaga@xxxxxxxxxx wrote:
>
> On 4/2/26 4:13 PM, anthony.yznaga@xxxxxxxxxx wrote:
>>
>> On 4/2/26 12:17 AM, David Hildenbrand (Arm) wrote:
>>>
>>> Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
>>>
>>>
>>> But
>>>
>>> ~/git/linux/mm$ git grep ENOTSUPP
>>> hugetlb_vmemmap.c:                      ret = -ENOTSUPP;
>>> mmap.c:                         return -ENOTSUPP;
>>>
>>>
>>> Should we fix up the other one as well?
>>>
>> I'm looking into this. It's returned for the case where vmemmap
>> mappings cannot be split/freed because they are self-hosted due to
>> memory hotplug. Many callers end up ignoring the error, but there may
>> be a way for it to be propagated to userspace as the errno for a
>> failed write to a sysfs file.
>
> To follow up on this, the ENOTSUPP returned by vmemmap_pmd_entry is not
> propagated to user space.  It is used internally to ensure
> HPG_vmemmap_optimized is cleared for a hugetlb folio when HVO cannot be
> applied due to the vmemmap memory being self-hosted.

Thanks for checking, it indeed propagates a bit but never seems to leave
the file. It would probably still be better to just clean that one up as
well.

--
Cheers,

David