[PATCH v2] Test errno setup

[Florian Weimer]

On 03/09/2017 04:00 PM, Stefan Liebler wrote:
> On 03/08/2017 05:20 PM, Zack Weinberg wrote:
>> On 03/06/2017 09:42 PM, Yury Norov wrote:
>>> On Mon, Mar 06, 2017 at 05:49:19PM -0300, Wainer dos Santos Moschetta
>>> wrote:
>>>> LGTM.
>>> Thanks. I don't have the write access to the glibc repo. Could you
>>> (someone else) apply the patch?
>>
>> I have committed the patch.
>>
>> zw
>>
>>
> Hi,
>
> on s390 (31bit), I get the following fails:
> FAIL: misc/test-errno:
> FAIL: mlock: errno is: 12 (Cannot allocate memory) expected: 22 (Invalid
> argument)
>
> FAIL: posix/test-errno:
> FAIL: mlock: errno is: 12 (Cannot allocate memory) expected: 22 (Invalid
> argument)
>
> Is it intended, that the same test is run twice?

Good catch.  I think the Linux test should be renamed, so that it does 
not override the generic test.  We want to run both on Linux.

> Why is the test-errno added to tests in sysdeps/unix/sysv/linux/Makefile
> with:
> ifeq ($(subdir),misc)
> tests += test-errno
> endif

After renaming the source file, something like that will be necessary to 
run the test.

> Regarding mlock-syscall:
> If the compat mlock syscall is used, it returns 12 (ENOMEM).
> This is also observable if you compile and run the testcase with -m32 on
> a x86_64 system.

I'd argue that this is a kernel bug.  EINVAL is required here because 
the address computation overflows (in 32-bit mode).  I don't see a good 
way to force a different error code, without risking thrashing the 
system.  Maybe we could map a page, unmap it, and pass that to mlock? 
That should result in ENOMEM reliably, I think.

> I've compiled and run posix/test-errno.c on my s390x system and
> get the following error:
> FAIL: setsockopt: errno is: 22 (Invalid argument) expected: 9 (Bad file
> descriptor)
> sl=0xfdfa9170 before setsockopt syscall.
> The test succeeds if I sl is initialized to zero.

Right, the initializer is missing.  Assuming that none of the get* calls 
which are called with &sl modify the variable (which is a reasonable 
assumption because they are expected to fail), adding the initializer 
should be the right fix.

Thanks,
Florian