AuroraMiddleware/glibc
1
0
Fork 0
mirror of https://sourceware.org/git/glibc.git synced 2024-12-12 06:10:10 +00:00
Code Issues Packages Projects Releases Wiki Activity
c97f9a5979
glibc/sysdeps/unix/sysv/linux/mips/setrlimit64.c

65 lines
2.1 KiB
C
Raw Normal View History

Update copyright dates with scripts/update-copyrights. * All files with FSF copyright notices: Update copyright dates using scripts/update-copyrights. * locale/programs/charmap-kw.h: Regenerated. * locale/programs/locfile-kw.h: Likewise.
2019-01-01 00:11:28 +00:00
/* Copyright (C) 2013-2019 Free Software Foundation, Inc.
MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant 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 O32 and N32 ABIs, we therefore end-up with different values on the userland and kernel side: * On the kernel side, the value is defined for all architectures as include/uapi/linux/resource.h: #define RLIM64_INFINITY (~0ULL) * On the GNU libc side, the value is defined in ports/sysdeps/unix/sysv/linux/mips/bits/resource.h: For the O32 and N32 ABI: # define RLIM64_INFINITY 0x7fffffffffffffffULL and for the N64 ABI: # define RLIM64_INFINITY 0xffffffffffffffffUL This was not a problem until the prlimit64 syscall was wired in the 2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement getrlimit64 and setrlimit64, pam_limits.so is setting the limits to a very big value instead of infinity. As a normal user process can later only decrease the value and not increase it, it will later get and EPERM error when trying to set the value to infinity with setrlimit. The GLIBC has this constant for more than 7 years, and as it is defined in a header file, it means a lot of binaries are in the wild. 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.
2013-11-27 13:42:06 +00:00
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
Prefer https to http for gnu.org and fsf.org URLs Also, change sources.redhat.com to sourceware.org. This patch was automatically generated by running the following shell script, which uses GNU sed, and which avoids modifying files imported from upstream: sed -ri ' s,(http|ftp)(://(.*\.)?(gnu|fsf|sourceware)\.org($|[^.]|\.[^a-z])),https\2,g s,(http|ftp)(://(.*\.)?)sources\.redhat\.com($|[^.]|\.[^a-z]),https\2sourceware.org\4,g ' \ $(find $(git ls-files) -prune -type f \ ! -name '*.po' \ ! -name 'ChangeLog*' \ ! -path COPYING ! -path COPYING.LIB \ ! -path manual/fdl-1.3.texi ! -path manual/lgpl-2.1.texi \ ! -path manual/texinfo.tex ! -path scripts/config.guess \ ! -path scripts/config.sub ! -path scripts/install-sh \ ! -path scripts/mkinstalldirs ! -path scripts/move-if-change \ ! -path INSTALL ! -path locale/programs/charmap-kw.h \ ! -path po/libc.pot ! -path sysdeps/gnu/errlist.c \ ! '(' -name configure \ -execdir test -f configure.ac -o -f configure.in ';' ')' \ ! '(' -name preconfigure \ -execdir test -f preconfigure.ac ';' ')' \ -print) and then by running 'make dist-prepare' to regenerate files built from the altered files, and then executing the following to cleanup: chmod a+x sysdeps/unix/sysv/linux/riscv/configure # Omit irrelevant whitespace and comment-only changes, # perhaps from a slightly-different Autoconf version. git checkout -f \ sysdeps/csky/configure \ sysdeps/hppa/configure \ sysdeps/riscv/configure \ sysdeps/unix/sysv/linux/csky/configure # Omit changes that caused a pre-commit check to fail like this: # remote: *** error: sysdeps/powerpc/powerpc64/ppc-mcount.S: trailing lines git checkout -f \ sysdeps/powerpc/powerpc64/ppc-mcount.S \ sysdeps/unix/sysv/linux/s390/s390-64/syscall.S # Omit change that caused a pre-commit check to fail like this: # remote: *** error: sysdeps/sparc/sparc64/multiarch/memcpy-ultra3.S: last line does not end in newline git checkout -f sysdeps/sparc/sparc64/multiarch/memcpy-ultra3.S
2019-09-07 05:40:42 +00:00
<https://www.gnu.org/licenses/>. */
MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant 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 O32 and N32 ABIs, we therefore end-up with different values on the userland and kernel side: * On the kernel side, the value is defined for all architectures as include/uapi/linux/resource.h: #define RLIM64_INFINITY (~0ULL) * On the GNU libc side, the value is defined in ports/sysdeps/unix/sysv/linux/mips/bits/resource.h: For the O32 and N32 ABI: # define RLIM64_INFINITY 0x7fffffffffffffffULL and for the N64 ABI: # define RLIM64_INFINITY 0xffffffffffffffffUL This was not a problem until the prlimit64 syscall was wired in the 2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement getrlimit64 and setrlimit64, pam_limits.so is setting the limits to a very big value instead of infinity. As a normal user process can later only decrease the value and not increase it, it will later get and EPERM error when trying to set the value to infinity with setrlimit. The GLIBC has this constant for more than 7 years, and as it is defined in a header file, it means a lot of binaries are in the wild. 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.
2013-11-27 13:42:06 +00:00
Fix -Wundef warnings for _ABI* on MIPS. This patch fixes -Wundef warnings related to the _ABI* macros on MIPS. GCC predefines only the _ABI* macro related to the ABI actually in use, meaning that a conditional such as "#if _MIPS_SIM == _ABI64" is true only for the ABI in question (all the macros are nonzero), but produces a -Wundef warning for the other ABIs. The normal approach to using these macros is to include <sgidefs.h>, which ensures that all three _ABI* macros are defined rather than just one; this patch does so in the places that caused warnings (the bulk of the warnings arising from <bits/wordsize.h>). Tested that the warnings are fixed. * sysdeps/mips/bits/wordsize.h: Include <sgidefs.h>. * sysdeps/unix/sysv/linux/mips/getrlimit64.c: Likewise. * sysdeps/unix/sysv/linux/mips/setrlimit64.c: Likewise.
2014-03-21 18:21:13 +00:00
#include <sgidefs.h>
MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant 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 O32 and N32 ABIs, we therefore end-up with different values on the userland and kernel side: * On the kernel side, the value is defined for all architectures as include/uapi/linux/resource.h: #define RLIM64_INFINITY (~0ULL) * On the GNU libc side, the value is defined in ports/sysdeps/unix/sysv/linux/mips/bits/resource.h: For the O32 and N32 ABI: # define RLIM64_INFINITY 0x7fffffffffffffffULL and for the N64 ABI: # define RLIM64_INFINITY 0xffffffffffffffffUL This was not a problem until the prlimit64 syscall was wired in the 2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement getrlimit64 and setrlimit64, pam_limits.so is setting the limits to a very big value instead of infinity. As a normal user process can later only decrease the value and not increase it, it will later get and EPERM error when trying to set the value to infinity with setrlimit. The GLIBC has this constant for more than 7 years, and as it is defined in a header file, it means a lot of binaries are in the wild. 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.
2013-11-27 13:42:06 +00:00
#if _MIPS_SIM == _ABIO32 || _MIPS_SIM == _ABIN32
MIPS: Fix RLIM64_INFINITY constant for O32 and N32 ABIs Fix the RLIM64_INFINITY constant for O32 and N32 ABIs to match the kernel one. Change the getrlimit64/setrlimit64 into old compat symbols, and provide the Linux generic getrlimit64/setrlimit64 functions as GLIBC_2_19 version.
2013-11-27 13:42:06 +00:00
# include <shlib-compat.h>
# define setrlimit64 __new_setrlimit64
MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant 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 O32 and N32 ABIs, we therefore end-up with different values on the userland and kernel side: * On the kernel side, the value is defined for all architectures as include/uapi/linux/resource.h: #define RLIM64_INFINITY (~0ULL) * On the GNU libc side, the value is defined in ports/sysdeps/unix/sysv/linux/mips/bits/resource.h: For the O32 and N32 ABI: # define RLIM64_INFINITY 0x7fffffffffffffffULL and for the N64 ABI: # define RLIM64_INFINITY 0xffffffffffffffffUL This was not a problem until the prlimit64 syscall was wired in the 2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement getrlimit64 and setrlimit64, pam_limits.so is setting the limits to a very big value instead of infinity. As a normal user process can later only decrease the value and not increase it, it will later get and EPERM error when trying to set the value to infinity with setrlimit. The GLIBC has this constant for more than 7 years, and as it is defined in a header file, it means a lot of binaries are in the wild. 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.
2013-11-27 13:42:06 +00:00
# include <sysdeps/unix/sysv/linux/setrlimit64.c>
# undef setrlimit64
MIPS: Fix RLIM64_INFINITY constant for O32 and N32 ABIs Fix the RLIM64_INFINITY constant for O32 and N32 ABIs to match the kernel one. Change the getrlimit64/setrlimit64 into old compat symbols, and provide the Linux generic getrlimit64/setrlimit64 functions as GLIBC_2_19 version.
2013-11-27 13:42:06 +00:00
versioned_symbol (libc, __new_setrlimit64, setrlimit64, GLIBC_2_19);
# if SHLIB_COMPAT (libc, GLIBC_2_2, GLIBC_2_19)
MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant 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 O32 and N32 ABIs, we therefore end-up with different values on the userland and kernel side: * On the kernel side, the value is defined for all architectures as include/uapi/linux/resource.h: #define RLIM64_INFINITY (~0ULL) * On the GNU libc side, the value is defined in ports/sysdeps/unix/sysv/linux/mips/bits/resource.h: For the O32 and N32 ABI: # define RLIM64_INFINITY 0x7fffffffffffffffULL and for the N64 ABI: # define RLIM64_INFINITY 0xffffffffffffffffUL This was not a problem until the prlimit64 syscall was wired in the 2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement getrlimit64 and setrlimit64, pam_limits.so is setting the limits to a very big value instead of infinity. As a normal user process can later only decrease the value and not increase it, it will later get and EPERM error when trying to set the value to infinity with setrlimit. The GLIBC has this constant for more than 7 years, and as it is defined in a header file, it means a lot of binaries are in the wild. 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.
2013-11-27 13:42:06 +00:00
/* 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. Given that a lot of binaries with
the wrong constant value are in the wild, provide a wrapper function
fixing the value before the syscall. */
MIPS: Fix RLIM64_INFINITY constant for O32 and N32 ABIs Fix the RLIM64_INFINITY constant for O32 and N32 ABIs to match the kernel one. Change the getrlimit64/setrlimit64 into old compat symbols, and provide the Linux generic getrlimit64/setrlimit64 functions as GLIBC_2_19 version.
2013-11-27 13:42:06 +00:00
# define OLD_RLIM64_INFINITY 0x7fffffffffffffffULL
MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant 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 O32 and N32 ABIs, we therefore end-up with different values on the userland and kernel side: * On the kernel side, the value is defined for all architectures as include/uapi/linux/resource.h: #define RLIM64_INFINITY (~0ULL) * On the GNU libc side, the value is defined in ports/sysdeps/unix/sysv/linux/mips/bits/resource.h: For the O32 and N32 ABI: # define RLIM64_INFINITY 0x7fffffffffffffffULL and for the N64 ABI: # define RLIM64_INFINITY 0xffffffffffffffffUL This was not a problem until the prlimit64 syscall was wired in the 2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement getrlimit64 and setrlimit64, pam_limits.so is setting the limits to a very big value instead of infinity. As a normal user process can later only decrease the value and not increase it, it will later get and EPERM error when trying to set the value to infinity with setrlimit. The GLIBC has this constant for more than 7 years, and as it is defined in a header file, it means a lot of binaries are in the wild. 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.
2013-11-27 13:42:06 +00:00
int
MIPS: Fix RLIM64_INFINITY constant for O32 and N32 ABIs Fix the RLIM64_INFINITY constant for O32 and N32 ABIs to match the kernel one. Change the getrlimit64/setrlimit64 into old compat symbols, and provide the Linux generic getrlimit64/setrlimit64 functions as GLIBC_2_19 version.
2013-11-27 13:42:06 +00:00
attribute_compat_text_section
__old_setrlimit64 (enum __rlimit_resource resource,
const struct rlimit64 *rlimits)
MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant 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 O32 and N32 ABIs, we therefore end-up with different values on the userland and kernel side: * On the kernel side, the value is defined for all architectures as include/uapi/linux/resource.h: #define RLIM64_INFINITY (~0ULL) * On the GNU libc side, the value is defined in ports/sysdeps/unix/sysv/linux/mips/bits/resource.h: For the O32 and N32 ABI: # define RLIM64_INFINITY 0x7fffffffffffffffULL and for the N64 ABI: # define RLIM64_INFINITY 0xffffffffffffffffUL This was not a problem until the prlimit64 syscall was wired in the 2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement getrlimit64 and setrlimit64, pam_limits.so is setting the limits to a very big value instead of infinity. As a normal user process can later only decrease the value and not increase it, it will later get and EPERM error when trying to set the value to infinity with setrlimit. The GLIBC has this constant for more than 7 years, and as it is defined in a header file, it means a lot of binaries are in the wild. 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.
2013-11-27 13:42:06 +00:00
{
struct rlimit64 krlimits;
MIPS: Fix RLIM64_INFINITY constant for O32 and N32 ABIs Fix the RLIM64_INFINITY constant for O32 and N32 ABIs to match the kernel one. Change the getrlimit64/setrlimit64 into old compat symbols, and provide the Linux generic getrlimit64/setrlimit64 functions as GLIBC_2_19 version.
2013-11-27 13:42:06 +00:00
if (rlimits->rlim_cur == OLD_RLIM64_INFINITY)
krlimits.rlim_cur = RLIM64_INFINITY;
MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant 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 O32 and N32 ABIs, we therefore end-up with different values on the userland and kernel side: * On the kernel side, the value is defined for all architectures as include/uapi/linux/resource.h: #define RLIM64_INFINITY (~0ULL) * On the GNU libc side, the value is defined in ports/sysdeps/unix/sysv/linux/mips/bits/resource.h: For the O32 and N32 ABI: # define RLIM64_INFINITY 0x7fffffffffffffffULL and for the N64 ABI: # define RLIM64_INFINITY 0xffffffffffffffffUL This was not a problem until the prlimit64 syscall was wired in the 2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement getrlimit64 and setrlimit64, pam_limits.so is setting the limits to a very big value instead of infinity. As a normal user process can later only decrease the value and not increase it, it will later get and EPERM error when trying to set the value to infinity with setrlimit. The GLIBC has this constant for more than 7 years, and as it is defined in a header file, it means a lot of binaries are in the wild. 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.
2013-11-27 13:42:06 +00:00
else
krlimits.rlim_cur = rlimits->rlim_cur;
MIPS: Fix RLIM64_INFINITY constant for O32 and N32 ABIs Fix the RLIM64_INFINITY constant for O32 and N32 ABIs to match the kernel one. Change the getrlimit64/setrlimit64 into old compat symbols, and provide the Linux generic getrlimit64/setrlimit64 functions as GLIBC_2_19 version.
2013-11-27 13:42:06 +00:00
if (rlimits->rlim_max == OLD_RLIM64_INFINITY)
krlimits.rlim_max = RLIM64_INFINITY;
MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant 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 O32 and N32 ABIs, we therefore end-up with different values on the userland and kernel side: * On the kernel side, the value is defined for all architectures as include/uapi/linux/resource.h: #define RLIM64_INFINITY (~0ULL) * On the GNU libc side, the value is defined in ports/sysdeps/unix/sysv/linux/mips/bits/resource.h: For the O32 and N32 ABI: # define RLIM64_INFINITY 0x7fffffffffffffffULL and for the N64 ABI: # define RLIM64_INFINITY 0xffffffffffffffffUL This was not a problem until the prlimit64 syscall was wired in the 2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement getrlimit64 and setrlimit64, pam_limits.so is setting the limits to a very big value instead of infinity. As a normal user process can later only decrease the value and not increase it, it will later get and EPERM error when trying to set the value to infinity with setrlimit. The GLIBC has this constant for more than 7 years, and as it is defined in a header file, it means a lot of binaries are in the wild. 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.
2013-11-27 13:42:06 +00:00
else
krlimits.rlim_max = rlimits->rlim_max;
MIPS: Fix RLIM64_INFINITY constant for O32 and N32 ABIs Fix the RLIM64_INFINITY constant for O32 and N32 ABIs to match the kernel one. Change the getrlimit64/setrlimit64 into old compat symbols, and provide the Linux generic getrlimit64/setrlimit64 functions as GLIBC_2_19 version.
2013-11-27 13:42:06 +00:00
return __new_setrlimit64 (resource, &krlimits);
MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant 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 O32 and N32 ABIs, we therefore end-up with different values on the userland and kernel side: * On the kernel side, the value is defined for all architectures as include/uapi/linux/resource.h: #define RLIM64_INFINITY (~0ULL) * On the GNU libc side, the value is defined in ports/sysdeps/unix/sysv/linux/mips/bits/resource.h: For the O32 and N32 ABI: # define RLIM64_INFINITY 0x7fffffffffffffffULL and for the N64 ABI: # define RLIM64_INFINITY 0xffffffffffffffffUL This was not a problem until the prlimit64 syscall was wired in the 2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement getrlimit64 and setrlimit64, pam_limits.so is setting the limits to a very big value instead of infinity. As a normal user process can later only decrease the value and not increase it, it will later get and EPERM error when trying to set the value to infinity with setrlimit. The GLIBC has this constant for more than 7 years, and as it is defined in a header file, it means a lot of binaries are in the wild. 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.
2013-11-27 13:42:06 +00:00
}
MIPS: Fix RLIM64_INFINITY constant for O32 and N32 ABIs Fix the RLIM64_INFINITY constant for O32 and N32 ABIs to match the kernel one. Change the getrlimit64/setrlimit64 into old compat symbols, and provide the Linux generic getrlimit64/setrlimit64 functions as GLIBC_2_19 version.
2013-11-27 13:42:06 +00:00
compat_symbol (libc, __old_setrlimit64, setrlimit64, GLIBC_2_2);
# endif
MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant 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 O32 and N32 ABIs, we therefore end-up with different values on the userland and kernel side: * On the kernel side, the value is defined for all architectures as include/uapi/linux/resource.h: #define RLIM64_INFINITY (~0ULL) * On the GNU libc side, the value is defined in ports/sysdeps/unix/sysv/linux/mips/bits/resource.h: For the O32 and N32 ABI: # define RLIM64_INFINITY 0x7fffffffffffffffULL and for the N64 ABI: # define RLIM64_INFINITY 0xffffffffffffffffUL This was not a problem until the prlimit64 syscall was wired in the 2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement getrlimit64 and setrlimit64, pam_limits.so is setting the limits to a very big value instead of infinity. As a normal user process can later only decrease the value and not increase it, it will later get and EPERM error when trying to set the value to infinity with setrlimit. The GLIBC has this constant for more than 7 years, and as it is defined in a header file, it means a lot of binaries are in the wild. 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.
2013-11-27 13:42:06 +00:00
#else /* !_ABI_O32 && !_ABI_N32 */
# include <sysdeps/unix/sysv/linux/setrlimit64.c>
#endif
Reference in New Issue Copy Permalink