Collective resource limits status report #3

Gabor Kovesdan gabor at
Wed Jun 23 08:51:09 UTC 2010

While trying to eliminate some bugs, I've looked at your patch in 
detail. I've adapted most part but I've got some comments.
> +typedef __uint32_t     __jid_t;
This has to be signed because calls may return -1.
> +#define        JLIM_NLIMITS    8
> +
> +/*
> + * Job limit string identifiers
> + */
> +
> +#ifdef _JLIMIT_IDENT
> +static char *jlimit_ident[JLIM_NLIMITS] = {
> +       "cputime",
> +       "datasize",
> +       "files",
> +       "processes",
> +       "threads",
> +       "vmemory",
> +       "physmem",
> +       "ressetsize",
> +};
> +#endif
A quick look at the limit manipulation syscalls doesn't suggest that we 
need these. I see you did it in a consistent way with rlimits but why to 
have those if they aren't really necessary. Or are they?
> @@ -97,6 +102,8 @@
>          long    ui_ptscnt;              /* (b) number of pseudo-terminals */
>          uid_t   ui_uid;                 /* (a) uid */
>          u_int   ui_ref;                 /* (b) reference count */
> +       jid_t   ui_jid;                 /* (c) job in which this uid_t lives */
> +       struct ulimit *ui_limit;
>   };
Unfortunately, IRIX is not the most well-documented operating system, so 
I still have some doubts on the actual behavior but I don't think a user 
lives in a job or does it? It's true that makenewjob() takes an uid_t 
argument but I think that will be a credential info for the created job, 
however I haven't been able to figure yet where it is used. What I am 
quite sure about is that job is an unescapable container and you can 
create a job with makenewjob(), which doesn't only create the job but 
associates the caller process to the job and then forked processes will 
also live in the same job. Please correct me if I am wrong. I've asked 
in the list if someone could provide me access to an IRIX machine but no 
answer yet... It would be nice to try out how it actually works on IRIX.


Gabor Kovesdan
FreeBSD Volunteer

EMAIL: gabor at .:|:. gabor at
WEB: .:|:.

More information about the soc-status mailing list