lkml.org 
[lkml]   [2010]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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


    \
     
     \ /
      Last update: 2010-05-06 17:49    [W:4.133 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site