Collective resource limits status report #3

[pluknet]

On 23 June 2010 12:50, Gabor Kovesdan <gabor at freebsd.org> wrote:
> 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.

It might return jid_t (-1) then as it's done similarly for getpid(2) family
which return pid_t(-1) on error, or similarly for inet_addr(3) which returns
INADDR_NONE (0xffffffff, or -1 for uint32_t, let it be signed) on error.

>>
>> +#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
>>

This is modeled by me after IRIX'ish jstat(1) manpage.
I'm still unsure, so it's up to you if it worth to be there.
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?cmd=getdoc&coll=0650&db=man&fname=1%20jstat
(though I'm afraid it may be a bit obsolete).

> 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...

I'd say some part (none, some processes, or all of them) of that (and only
that) user lives in a job.

Yeah, IRIX documentation has a bit of uncertainty for me as well.
They wrote: "With the IRIX kernel job limits feature, all processes
associated with a particular login session or batch submission are
encapsulated as a single logical unit called a job. The job is the
container used to group processes by login session."
But next: "Limits on resource usage are applied on a per user basis for a
particular job".
"Job limits software helps ensure that each user has access to the
appropriate amount of system resources such as CPU time and memory
and makes sure that users do not exceed their allotted amount."

Btw, it's interesting how to properly make getjusage(2), if a process
running inside a job wants to change it's uid/gid
(if basing on the claim that a job scope is limited by per-user basis).

> It would be nice to try out how it actually works on IRIX.

Yes, that would answer many questions...

-- 
wbr,
pluknet