2018-10-18 03:27:18

by Hongzhi, Song

[permalink] [raw]
Subject: Question about mmap syscall and POSIX standard on mips arch

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

-----part of code-----

    pa = mmap(addr, len, PROT_READ | PROT_WRITE, MAP_FIXED |
MAP_SHARED, fd,
0);
    if (pa == MAP_FAILED && errno == ENOMEM) {
        printf("Got ENOMEM: %s\nTest PASSED\n", strerror(errno));
exit(PTS_PASS);
    }

-----end----------------


Under POSIX standard, the expected errno should be ENOMEM

when the specific [addr+len] exceeds the bound of memory.


But mips returns EINVAL.

https://github.com/torvalds/linux/blob/bab5c80b211035739997ebd361a679fa85b39465/arch/mips/mm/mmap.c#L69

-------part of code-------

    if (flags & MAP_FIXED) {
        /* Even MAP_FIXED mappings must reside within TASK_SIZE */
        if (TASK_SIZE - len < addr)
            return -EINVAL;

-------end------------------


So, can we change EINVAL to ENOMEM to follow POSIX standard?


--Hongzhi



2018-10-18 04:32:43

by Al Viro

[permalink] [raw]
Subject: Re: Question about mmap syscall and POSIX standard on mips arch

[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.

2018-10-18 23:10:06

by Paul Burton

[permalink] [raw]
Subject: Re: Question about mmap syscall and POSIX standard on mips arch

Hi Al,

On Thu, Oct 18, 2018 at 05:32:00AM +0100, Al Viro wrote:
> [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.

Thanks for the heads up - that does sound like reasonably clear
non-compliance. I'll make a note to put together a patch & test it out,
likely next week, if nobody submits one first.

Thanks,
Paul