From owner-soc-status@FreeBSD.ORG Wed Jun 23 08:51:08 2010 Return-Path: Delivered-To: soc-status@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7473106564A; Wed, 23 Jun 2010 08:51:08 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 583A08FC0C; Wed, 23 Jun 2010 08:51:08 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id E0ED714DBCE6; Wed, 23 Jun 2010 10:51:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Gu6ThZPh1NPI; Wed, 23 Jun 2010 10:51:04 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id A56A314DBCFE; Wed, 23 Jun 2010 10:51:04 +0200 (CEST) Message-ID: <4C21CAF0.2040607@FreeBSD.org> Date: Wed, 23 Jun 2010 10:50:56 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; es-ES; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: pluknet References: <4C1BCB96.4040608@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: soc-status@freebsd.org Subject: Re: Collective resource limits status report #3 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 08:51:09 -0000 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. Thanks, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org