Re: Resource limits interface proposal [was: pull request for writablelimits]

[Jiri Slaby]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/