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