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

[anthony.yznaga@oracle.com]

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.