This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: setrlimit change to prlimit change in behavior?
On 18/10/2017 18:10, Carlos O'Donell wrote:
> 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.
I recall very similar discussion some time ago that lead to a LTP fix [1].
As for valgrind, they were also testing for the specific undefined glibc
behaviour.
[1] https://github.com/linux-test-project/ltp/commit/259db6fed55f88ab32a0875e66803eee44d298be