Subject: Re: mmap, siginfo
To: None <,>
From: r.o.s.s <>
List: tech-kern
Date: 02/17/2002 18:57:52
We don't apply the datasize limits very seriously to mmap(2) calls,
but we do check that any one call doesn't bust the limit. Effectively,
cmucl was intentionally activating a bug in mmap(2) instead of clearing
the soft setrlimit(2).

Sometimes I think those limits are more trouble than they are worth,
although mmap(2) would have returned a reasonable ENOMEM in the
limit-busting case. Or, you could argue that the goofy check in
mmap(2) is worse than no check at all, because it's confusing.


> From: Thor Lancelot Simon <>
> On Sun, Feb 17, 2002 at 04:30:00PM -0600, John R Towler wrote:
> > 
> > Difficulties apparently are manifest in the OS facilities desired in
> > the new, experimental port of cmucl to NetBSD/x86.  Wrt  the comments
> > below, the facilities desired are 
> > 
> > ((a) the ability to map memory in chunks >= 128M 
> I don't understand what the problem is, here.  I mmap more than 128MB
> at a time with some regularity; no problems to report.
> Perhaps the author of the comment you enclosed didn't check that his
> resource limits were set appropriately?  I note that:
> 1) The default "datasize" limit is 128MB
> 2) Many other Unix variants incorrecly *don't count mmap allocations
>    against *any* resource limit *at all**, allowing the use of mmap()
>    to completely bollix up the system.