From owner-freebsd-smp Sat Jul 13 19:50:28 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F79937B400 for ; Sat, 13 Jul 2002 19:50:25 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id D996943E58 for ; Sat, 13 Jul 2002 19:50:24 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 6448 invoked from network); 14 Jul 2002 02:50:21 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 14 Jul 2002 02:50:21 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g6E2oA043207; Sat, 13 Jul 2002 22:50:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020713152319.75c416a2.makonnen@pacbell.net> Date: Sat, 13 Jul 2002 22:50:20 -0400 (EDT) From: John Baldwin To: Mike Makonnen Subject: Re: Getting resource limits out from under Giant Cc: bright@mu.org, freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 13-Jul-2002 Mike Makonnen wrote: > On Fri, 12 Jul 2002 14:09:32 -0400 (EDT) > John Baldwin wrote: > >> >> >> You need to ensure you have a stable reference to the limits >> structure. If you are dereferencing p_limit you need to use the proc >> lock to protect reading that pointer. The lock also ensure the value >> is up to date. >> > > I see what you mean: > > foolimit = p->p_limit->pl_rlimit[FOOLIMIT].rlim_cur; > > is OK. But > > plim = p->p_limit; > ... > ... > foolimit = p->p_limit->pl_rlimit[FOOLIMIT].rlim_cur; > > needs to lock both the proc and the limit. Even better, it should use > the first form if it can. > > The part I am not clear about is when modifying a value in the limits > structure. > There is one instance in the patch where I do this: > > a: > allocate some memory > lock proc > lock p->plimit > check if we must copy-on-write > do so if necessary > unlock plimit > unlock proc > free some memory > lock p->plimit > if conditions have changed and we must do a copy-on-write > goto a > modify limits as necessary > > My reasoning for dropping both locks in the middle and reaquiring only > the > limit lock is that anyone who might mess with our p->plimit must > aquire both the proc and the limit lock. So, as long as I have the limit > lock, there isn't any chance that it will go stale on me. > > I will work on the patch some more this weekend and repost. Why not just do a simple change: don't drop the locks so quick, but go ahead and do the modify limit step after using your preallocated memory to do the copy-on-write. Then you can drop your locks and free any memory using cached pointers. No need for a loop and much simpler. Basically, all you need to do is move your 'free some memory' step down to the bottom, then you can immediately go from the copy-on-write step to the modify limits step. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message