Hello Eugene, On 9/19/18 7:12 PM, Eugene Syromyatnikov wrote: > It's still 32 bit. Thanks. Patch applied. Cheers, Michael > Signed-off-by: Eugene Syromyatnikov <evgsyr@xxxxxxxxx> > --- > man2/getrlimit.2 | 15 +++++---------- > 1 file changed, 5 insertions(+), 10 deletions(-) > > diff --git a/man2/getrlimit.2 b/man2/getrlimit.2 > index 3a4d48f..b0adfb2 100644 > --- a/man2/getrlimit.2 > +++ b/man2/getrlimit.2 > @@ -762,7 +762,11 @@ and > .BR setrlimit () > system calls is a (32-bit) > .IR "unsigned long" . > -Furthermore, in Linux versions before 2.6.36, > +.\" Linux still uses long for limits internally: > +.\" c022a0acad534fd5f5d5f17280f6d4d135e74e81 > +.\" kernel/sys.c:do_prlimit() still uses struct rlimit which > +.\" uses kernel_ulong_t for its members, i.e. 32-bit on 32-bit kernel. > +Furthermore, in Linux, > the kernel represents resource limits on 32-bit platforms as > .IR "unsigned long" . > However, a 32-bit data type is not wide enough. > @@ -788,15 +792,6 @@ wrapper function silently converted the limit value to > .BR RLIM_INFINITY . > In other words, the requested resource limit setting was silently ignored. > .PP > -This problem was addressed in Linux 2.6.36 with two principal changes: > -.IP * 3 > -the addition of a new kernel representation of resource limits that > -uses 64 bits, even on 32-bit platforms; > -.IP * > -the addition of the > -.BR prlimit () > -system call, which employs 64-bit values for its resource limit arguments. > -.PP > Since version 2.13, > .\" https://www.sourceware.org/bugzilla/show_bug.cgi?id=12201 > glibc works around the limitations of the > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
