Date: Wed, 26 Mar 2003 17:04:17 -0800 From: Wes Peters <wes@softweyr.com> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-arch@freebsd.org Subject: Re: Patch to protect process from pageout killing Message-ID: <200303261704.17095.wes@softweyr.com> In-Reply-To: <XFMail.20030326121325.jhb@FreeBSD.org> References: <XFMail.20030326121325.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200303261704.17095.wes>