AuroraMiddleware/glibc
1
0
Fork 0
mirror of https://sourceware.org/git/glibc.git synced 2024-12-02 01:40:07 +00:00
Code Issues Packages Projects Releases Wiki Activity
38d3d5b7bd
glibc/sysdeps/unix/sysv/linux/mips/getrlimit64.c

69 lines
2.2 KiB
C
Raw Normal View History

Update copyright dates with scripts/update-copyrights.
2015-01-02 16:28:19 +00:00
/* Copyright (C) 2013-2015 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
<http://www.gnu.org/licenses/>. */
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 getrlimit64 __new_getrlimit64
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/getrlimit64.c>
# undef getrlimit64
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
Fix posix_spawn getrlimit64 namespace (bug 17991). posix_spawn (a standard POSIX function) brings in a use of getrlimit64 (not a standard POSIX function). This patch fixes this by using __getrlimit64 and making getrlimit64 a weak alias. This is more complicated than some such changes because of files that define getrlimit64 in their own way using symbol versioning after including the main sysdeps/unix/sysv/linux/getrlimit64.c with a getrlimit macro defined. There are various existing patterns for such cases in glibc; the one I've used here is that a getrlimit64 macro disables the weak_alias / libc_hidden_weak calls, leaving it to the including file to define the getrlimit64 name in whatever way is appropriate. Tested for x86_64 and x86 that installed stripped shared libraries are unchanged by this patch. [BZ #17991] * include/sys/resource.h (__getrlimit64): Declare. Use libc_hidden_proto. * resource/getrlimit64.c (getrlimit64): Rename to __getrlimit64 and define as weak alias of __getrlimit64. Use libc_hidden_weak. * sysdeps/posix/spawni.c (__spawni): Call __getrlimit64 instead of getrlimit64. * sysdeps/unix/sysv/linux/getrlimit64.c (getrlimit64): Rename to __getrlimit64. [!getrlimit64] (getrlimit64): Define as weak alias of __getrlimit64. Use libc_hidden_weak. * sysdeps/unix/sysv/linux/i386/getrlimit64.c (getrlimit64): Define using __getrlimit64 not __new_getrlimit64. (__GI_getrlimit64): Likewise. * sysdeps/unix/sysv/linux/mips/getrlimit64.c (getrlimit64): Likewise. (__GI_getrlimit64): Likewise. (__old_getrlimit64): Use __getrlimit64 not __new_getrlimit64. * sysdeps/unix/sysv/linux/powerpc/powerpc64/syscalls.list (getrlimit): Add __getrlimit64 alias. * sysdeps/unix/sysv/linux/wordsize-64/syscalls.list (getrlimit): Likewise. * conform/Makefile (test-xfail-XOPEN2K/spawn.h/linknamespace): Remove variable. (test-xfail-POSIX2008/spawn.h/linknamespace): Likewise. (test-xfail-XOPEN2K8/spawn.h/linknamespace): Likewise.
2015-02-18 00:26:35 +00:00
versioned_symbol (libc, __getrlimit64, getrlimit64, GLIBC_2_19);
strong_alias (__getrlimit64, __GI_getrlimit64)
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 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 after 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_getrlimit64 (enum __rlimit_resource resource,
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;
Fix posix_spawn getrlimit64 namespace (bug 17991). posix_spawn (a standard POSIX function) brings in a use of getrlimit64 (not a standard POSIX function). This patch fixes this by using __getrlimit64 and making getrlimit64 a weak alias. This is more complicated than some such changes because of files that define getrlimit64 in their own way using symbol versioning after including the main sysdeps/unix/sysv/linux/getrlimit64.c with a getrlimit macro defined. There are various existing patterns for such cases in glibc; the one I've used here is that a getrlimit64 macro disables the weak_alias / libc_hidden_weak calls, leaving it to the including file to define the getrlimit64 name in whatever way is appropriate. Tested for x86_64 and x86 that installed stripped shared libraries are unchanged by this patch. [BZ #17991] * include/sys/resource.h (__getrlimit64): Declare. Use libc_hidden_proto. * resource/getrlimit64.c (getrlimit64): Rename to __getrlimit64 and define as weak alias of __getrlimit64. Use libc_hidden_weak. * sysdeps/posix/spawni.c (__spawni): Call __getrlimit64 instead of getrlimit64. * sysdeps/unix/sysv/linux/getrlimit64.c (getrlimit64): Rename to __getrlimit64. [!getrlimit64] (getrlimit64): Define as weak alias of __getrlimit64. Use libc_hidden_weak. * sysdeps/unix/sysv/linux/i386/getrlimit64.c (getrlimit64): Define using __getrlimit64 not __new_getrlimit64. (__GI_getrlimit64): Likewise. * sysdeps/unix/sysv/linux/mips/getrlimit64.c (getrlimit64): Likewise. (__GI_getrlimit64): Likewise. (__old_getrlimit64): Use __getrlimit64 not __new_getrlimit64. * sysdeps/unix/sysv/linux/powerpc/powerpc64/syscalls.list (getrlimit): Add __getrlimit64 alias. * sysdeps/unix/sysv/linux/wordsize-64/syscalls.list (getrlimit): Likewise. * conform/Makefile (test-xfail-XOPEN2K/spawn.h/linknamespace): Remove variable. (test-xfail-POSIX2008/spawn.h/linknamespace): Likewise. (test-xfail-XOPEN2K8/spawn.h/linknamespace): Likewise.
2015-02-18 00:26:35 +00:00
if (__getrlimit64 (resource, &krlimits) < 0)
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
return -1;
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 (krlimits.rlim_cur == RLIM64_INFINITY)
rlimits->rlim_cur = OLD_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
rlimits->rlim_cur = krlimits.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 (krlimits.rlim_max == RLIM64_INFINITY)
rlimits->rlim_max = OLD_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
rlimits->rlim_max = krlimits.rlim_max;
return 0;
}
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_getrlimit64, getrlimit64, 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/getrlimit64.c>
#endif
Reference in New Issue Copy Permalink