Skip site navigation (1)Skip section navigation (2)
Date:      16 Jul 1999 14:09:07 +0300
From:      Ville-Pertti Keinonen <will@iki.fi>
To:        cgd@netbsd.org (Chris G. Demetriou)
Cc:        hackers@freebsd.org, dillon@apollo.backplane.com
Subject:   Re: Replacement for grep(1) (part 2)
Message-ID:  <86iu7kn964.fsf@not.demophon.com>
In-Reply-To: cgd@netbsd.org's message of "14 Jul 1999 02:03:32 %2B0300"
References:  <199907132110.OAA23817@lestat.nas.nasa.gov> <871zecyx0k.fsf@redmail.redback.com>

next in thread | previous in thread | raw e-mail | index | archive | help

cgd@netbsd.org (Chris G. Demetriou) writes:

> Matthew Dillon <dillon@apollo.backplane.com> writes:
> >     The text size of a program is irrelevant, because swap is never
> >     allocated for it.  The data and BSS are only relevant when they

No, you can mprotect read-only vnode mappings to writable.  Most
things wouldn't be hurt badly if this changed, though, I suspect that
this already varies between operating systems.

> >     are modified.
> > 
> >     The only thing swap is ever used for is the dynamic allocation of memory.
> >     There are three ways to do it:  sbrk(), mmap(... MAP_ANON), or
> >     mmap(... MAP_PRIVATE).

> yup, almost: not all MAP_PRIVATE mappings need backing store, only
> MAP_PRIVATE and writeable mappings.  (MAP_PRIVATE does _not_ guarantee
> that you won't see modifications made via other MAP_SHARED mappings.)

...but in *this* case, you certainly shouldn't allow mprotect to fail
(with what, ENOMEM?).

It's certainly counterintuitive to me that mprotect could fail due to
a resource shortage.

> Actually, only now have you brought that up.  And, that's very system
> dependent.  On NetBSD/i386 the default is 2MB, and, it's worth noting
> that you only need to reserve as much as the current stack limit
> allows (after that, you're going to get a signal anyway, and if more

So what setrlimit accepts depends on how much memory is available?

Ok, programs changing their stack limit are rare, but this would still
be another API change.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86iu7kn964.fsf>