From owner-freebsd-arch@FreeBSD.ORG Wed Mar 26 17:04:18 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEA1237B404; Wed, 26 Mar 2003 17:04:18 -0800 (PST) Received: from mail01.stbernard.com (mail01.stbernard.com [64.154.93.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id D173F43F93; Wed, 26 Mar 2003 17:04:17 -0800 (PST) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com ([192.168.4.61]) by mail01.stbernard.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Mar 2003 17:04:17 -0800 From: Wes Peters Organization: Softweyr.com To: John Baldwin Date: Wed, 26 Mar 2003 17:04:17 -0800 User-Agent: KMail/1.5 References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303261704.17095.wes@softweyr.com> X-OriginalArrivalTime: 27 Mar 2003 01:04:17.0489 (UTC) FILETIME=[CA861C10:01C2F3FC] X-Spam-Status: No, hits=-25.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: Poul-Henning Kamp cc: freebsd-arch@freebsd.org Subject: Re: Patch to protect process from pageout killing X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2003 01:04:19 -0000 On Wednesday 26 March 2003 09:13, John Baldwin wrote: > On 26-Mar-2003 Wes Peters wrote: > > On Tuesday 25 March 2003 08:34, John Baldwin wrote: > >> On 25-Mar-2003 Wes Peters wrote: > >> > On Monday 24 March 2003 08:36, Poul-Henning Kamp wrote: > >> >> Also, doesn't this result in the flag being inerited with > >> >> fork() and thereby negating the effect you are seeking for > >> >> squid ? > >> > > >> > I looked through all the places in kern_fork.c where p2->p_flag > >> > gets set and didn't see anything that looked like it would > >> > inherit P_PROTECTED from p1->p_flag. Did I miss something? I'm > >> > obviously a bit of a neophyte in this part of the kernel. > >> > >> rlimit's are inherited. However, due to a "feature" bug in your > >> patch, the P_PROTECTED flag doesn't get turned on when the rlimit > >> is inherited in fork1(). > > > > feature bug? If you mean the fact that the setting for P_PROTECTED > > isn't stored in the rlimit, that was intentional. rlimits are > > inherited and I specifically didn't want that behavior, similar to > > p_cpulimit. I still agree resource limits are not an ideal > > interface to use for this, I'll look further. > > I mean that you should be setting P_PROTECTED in fork() based on the > inherited rlimit's since otherwise the value of the rlimit is out of > sync with the P_PROTECTED flag. Hence a bug. However, since non- > inheritance is the desired behavior, it is also a feature, hence > "feature" bug. Ah, actually it would be best to explicitly clear the RLIMIT_PROTECT in the rlimit, except the RLIMIT_PROTECT isn't stored in the rlimit. Eww, that was not good. Problem is, there isn't a generic syscall for munging proc items. As I said, it was a less-than-optimal syscall to abuse, I'll go back to pondering madvise(2) or mprotect(2) which almost sort of make sense. -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com