This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 2018-01-01 15:00, Richard Henderson wrote:
> On 12/30/2017 10:44 AM, 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
> 
> However, do_prlimit still uses RLIM_INFINITY, so I'm a bit confused about how
> this change is supposed to make any difference.

The prlimit64 syscall does the conversion between the two variants of
RLIM_INFINITY, through the rlim_to_rlim64 and rlim64_to_rlim functions.
Therefore depending if the getrlimit/setrlimit or the prlimit64 syscalls
are used, the RLIM_INFINITY value is different.

> Even if it did, surely the best solution is not to map __{old}_getrlimit64 to
> the prlimit64 syscall, but to the original getrlimit syscall so that userland
> need do no mapping at all of the return value structure.

This has two issues:
- The RLIM_INFINITY value defined on the glibc side is correct for the
  getrlimit/setrlimit functions, but not for the prlimit one which is
  also provided by the GNU libc. The goal of the second patch is
  actually to change this value to fix that issue.
- Using different syscalls depending on the architecture causes issues
  when seccomp is being used, and requires additional whitelisting for
  them. It's something that is usually not well done for non-mainstream
  architectures like alpha. This has caused issue for example in systemd
  (not sure about alpha in particular though).

Aurelien

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]