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

[anthony.yznaga@oracle.com]

On 4/2/26 4:13 PM, anthony.yznaga@oracle.com wrote:
>
> On 4/2/26 12:17 AM, David Hildenbrand (Arm) wrote:
>> On 4/2/26 02:44, Andrew Morton wrote:
>>> On Wed,  1 Apr 2026 17:34:16 -0700 Anthony Yznaga 
>>> <anthony.yznaga@oracle.com> wrote:
>>>
>>>> On configs where MAP_DROPPABLE is not supported (currently any 32-bit
>>>> config except for PPC32), mmap fails with errno set to ENOTSUPP.
>>>> However, ENOTSUPP is not a standard error value that userspace knows
>>>> about. The acceptable userspace-visible errno to use is EOPNOTSUPP.
>>>> checkpatch.pl has a warning to this affect.
>>> Sounds very reasonable.
>>>
>>> EOPNOTSUPP is clearly a networking thing so what on earth is it doing
>>> coming out of mmap code?  Our poor operator is now looking at a 
>>> networking
>>> error code and wondering what this supposedly non-networking
>>> application is up to.
>>>
>>> But just that's a pet peeve - I lost that one decades ago.
>>>
>>>> Fixes: 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always 
>>>> lazily freeable mappings")
>>> Nearly two years ago so I think I'll add this to mm-unstable for
>>> 7.1-rc1 and shall let it trickle back a little more slowly than might a
>>> 7.0-rcX hotfix.
>>>
>>>
>>
>> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
>>
>>
>> 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.