Re: [PATCH 1/4] Alpha: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant [BZ #22648]

[Aurelien Jarno <aurelien at aurel32 dot net>]

On 2017-12-31 17:33, Adhemerval Zanella wrote:
> On 30/12/2017 16:44, Aurelien Jarno wrote:
> > RLIM64_INFINITY was supposed to be a glibc convention rather than
> > anything seen by the kernel, but it ended being passed to the kernel
> > through the prlimit64 syscall.
> > 
> > * On the kernel side, the value is defined for the prlimit64 syscall for
> >   all architectures in include/uapi/linux/resource.h:
> > 
> >   #define RLIM64_INFINITY           (~0ULL)
> > 
> > * On the kernel side, the value is defined for getrlimit and setrlimit
> >   in arch/alpha/include/uapi/asm/resource.h
> > 
> >   #define RLIM_INFINITY            0x7ffffffffffffffful
> > 
> > * On the GNU libc side, the value is defined in
> >   sysdeps/unix/sysv/linux/alpha/bits/resource.h:
> > 
> >   # define RLIM64_INFINITY 0x7fffffffffffffffLL
> > 
> > This was not an issue until the getrlimit and setrlimit glibc functions
> > have been changed in commit 045c13d185 ("Consolidate Linux setrlimit and
> > getrlimit implementation") to use the prlimit64 syscall instead of the
> > getrlimit and setrlimit ones.
> > 
> > This patch fixes that by adding a wrapper to fix the value passed to or
> > received from the kernel, before or after calling the prlimit64 syscall.
> 
> Sigh, at least seem only alpha still defines RLIMIT64_INFINITY as 
> 0x7ffffffffffffffful.  I did see some failures related to 'allocatestack.c:480' 
> you pointed out (basically all the rt/* ones from 2.26 release info),
> however the issue only triggers when the tests are ran from make with
> either make check or make <folder>/tests.  If I ran the tests directly
> using 'testrun.sh' the same one succeeds.
> 
> Anyway, do you think you can came up with a regression tests for this
> issues? Otherwise change LGTM

As long as getrlimit and setrlimit behave the same way, it's difficult
to do so. I guess it's possible to call prlimit directly and compare the
values with getrlimit and setrlimit. Such a test will fail for
architectures which have a different representation of RLIM_INFINITY in
the kernel and the libc, so it is somehow dependent on patch 2 (assuming
that alpha is the last concerned architecture, which seems to be the
case).

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net