Messages in this thread | | | Date | Thu, 06 May 2010 17:46:12 +0200 | From | Jiri Slaby <> | Subject | Re: Resource limits interface proposal [was: pull request for writable limits] |
| |
On 05/05/2010 05:08 PM, Linus Torvalds wrote: > On Wed, 5 May 2010, Jiri Slaby wrote: >> The drawback is when a 32-bit user passes down a value >= (1 << 32), >> EINVAL shall occur. > > I'd almost prefer to just turn them into RLIMIT_MAX. If somebody asks for > a really huge limit that is bigger than the max we already have, doesn't > RLIMIT_MAX sound like the right thing?
Yes, silently setting the highest possible value (INFINITY) is OK too (as we cannot do better anyway).
>> Just a side note, we cannot use the rlimit64 name which is already >> reserved in glibc headers for limits handling. > > What does the glibc 'struct rlimit64' look like? It's the structure name > that matters, since the system call name would presumably be 'prlimit64()' > due to the pid thing. > > And if the glibc rlimit64 matches what we would use, I think we can decide > to just re-use it.
With glibc-2.11.1 which I have includes from: #ifdef __USE_LARGEFILE64 struct rlimit64 { /* The current (soft) limit. */ rlim64_t rlim_cur; /* The hard limit. */ rlim64_t rlim_max; }; #endif
where rlim64_t expands to __u_quad_t which is #if __WORDSIZE == 64 typedef unsigned long int __u_quad_t; #elif defined __GLIBC_HAVE_LONG_LONG __extension__ typedef unsigned long long int __u_quad_t; #endif
so something like our u64. The structure is the same to what we are about to use. If nobody objects?
-- js
| |