From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Hongzhi, Song" <hongzhi.song@windriver.com>
Cc: linux-kernel@vger.kernel.org, mm-commits@vger.kernel.org,
linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Question about mmap syscall and POSIX standard on mips arch
Date: Thu, 18 Oct 2018 05:32:00 +0100 [thread overview]
Message-ID: <20181018043200.GE32577@ZenIV.linux.org.uk> (raw)
In-Reply-To: <e897b11f-1577-9298-7c82-7bbdea56e7e5@windriver.com>
[mips folks Cc'd]
On Thu, Oct 18, 2018 at 11:26:02AM +0800, Hongzhi, Song wrote:
> Hi all,
>
> Ltp has a POSIX teatcase about mmap, 24-2.c.
>
> https://github.com/linux-test-project/ltp/blob/e816127e5d8efbff5ae53e9c2292fae22f36838b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-2.c#L94
[basically, MAP_FIXED mmap with addr + len > TASK_SIZE fails with
-EINVAL on mips and -ENOMEM elsewhere]
> Under POSIX standard, the expected errno should be ENOMEM
>
> when the specific [addr+len] exceeds the bound of memory.
The mmap() function may fail if:
[EINVAL]
The addr argument (if MAP_FIXED was specified) or off is not a multiple
of the page size as returned by sysconf(), or is considered invalid by
^^^^^^^^^^^^^^^^^^^^^^^^^^^
the implementation.
^^^^^^^^^^^^^^^^^^^
So that behaviour gets past POSIX. That part is mostly about the
things like cache aliasing constraints, etc., but it leaves enough
space to weasel out. Said that, this
[ENOMEM]
MAP_FIXED was specified, and the range [addr,addr+len) exceeds that allowed
for the address space of a process; or, if MAP_FIXED was not specified and
there is insufficient room in the address space to effect the mapping.
is a lot more specific, so switching to -ENOMEM there might be a good idea,
especially since on other architectures we do get -ENOMEM in that case,
AFAICS.
next prev parent reply other threads:[~2018-10-18 4:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-18 3:26 Question about mmap syscall and POSIX standard on mips arch Hongzhi, Song
2018-10-18 4:32 ` Al Viro [this message]
2018-10-18 23:09 ` Paul Burton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181018043200.GE32577@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=hongzhi.song@windriver.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=mm-commits@vger.kernel.org \
--cc=ralf@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.