Re: setrlimit change to prlimit change in behavior?

[Carlos O'Donell <carlos at redhat dot com>]

On 10/18/2017 12:06 PM, Mark Wielaard wrote:
> On Wed, 2017-10-18 at 10:44 -0700, Carlos O'Donell wrote:
>> On 10/18/2017 08:04 AM, Andreas Schwab wrote:
>>> If there is no special case for NULL then it is not allowed.
>>
>> Agreed.
>>
>> And testing for NULL and returning EFAULT is not something we actually
>> want to do, please see:
>> https://sourceware.org/glibc/wiki/Style_and_Conventions#Error_Handling
> 
> Thanks for that reference. Of course for my use case (syscall argument
> sanity checking) I shouldn't rely on the glibc behavior. So we can
> certainly change our testcase to not go through glibc and use direct
> syscalls.
> 
> But if I were to rely on the glibc behavior what exactly defines the
> contract? Naively I used the man page for setrlimit.

The linux man pages are not the canonical documentation for the interface.
I suggest sending them a patch to adjust their documentation to prevent
further confusion.

The canonical documentation is the glibc manual e.g. info setrlimit,
which says only EPERM is a documented return, and NULL is not discussed
as part of the contract:
https://www.gnu.org/software/libc/manual/html_node/Limits-on-Resources.html#index-setrlimit

Likewise POSIX Issue 7:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/setrlimit.html

> http://man7.org/linux/man-pages/man2/setrlimit.2.html
> Which at first glance seems to define the contract for glibc (and the
> kernel combined). And it does explicitly say:
> 
> ERRORS          
>        EFAULT A pointer argument points to a location outside the
> 	      accessible address space.

This is a case of the linux man pages project *overspecifying* the
interface and doing so is a bad idea. We take great pains in glibc, and
the upstream standards bodies to avoid doing this where it would limit
the implementation. Consider that a requirement for the above would mean
that pointers into setrlimit would have to be tested forever! That would
slow things down needlessly for conforming applications.

> I cannot immediately deduce from this document which errors define the
> contract of the linux kernel interface and which of glibc.

The linux man pages have two kinds of documentation

- linux kernel interface documentation (see futex for an example)

- API documentation (see getrlimit/setrlimit, prlimit for an example)

And it does a very good job of explaining which you are looking at.

In this case you are looking at linux man pages API documentation for
interfaces which are part of a published standard, though linux-isms
and glibc-isms have leaked into the documentation usually in the form of 
overspecifications, we should work to remove them.

At this moment you *cannot* know what the linux kernel interface is
for setprlimit without going to the linux kernel sources, and getting 
confirmation from core kernel developers to document that interface.
Such an interface documentation may not exist and for futex it didn't
and took tons of work for Michael and Torvald to write one such that
glibc could have something rock-solid to depend upon for concurrency
uses.

Lastly, note that nothing prevents interfaces from returning additional
error codes not specified in the standard, and in those cases your
application should just abort. In glibc we do this for futex syscalls
if the error code is outside of the contract provided by the kernel,
thus we fail early and catastrophically if someone breaks futex with
new undocumented error codes (see futex-internal.h (futex_fatal_error)).

I hope that answers your question and give you some insight into what
is going on and why. I also hope it spurs you into action to help
Michael Kerrisk make the linux man pages a better project by
contributing fixes.

-- 
Cheers,
Carlos.