Re: [PATCH 1/2] mm: fix mmap errno value when MAP_DROPPABLE is not supported
From: anthony . yznaga
Date: Thu Apr 02 2026 - 19:14:00 EST
On 4/2/26 12:17 AM, David Hildenbrand (Arm) wrote:
On 4/2/26 02:44, Andrew Morton wrote: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.
On Wed, 1 Apr 2026 17:34:16 -0700 Anthony Yznaga <anthony.yznaga@xxxxxxxxxx> wrote:
On configs where MAP_DROPPABLE is not supported (currently any 32-bitSounds very reasonable.
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.
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@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?