Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 Jan 2014 09:43:26 +0000 (UTC)
From: Thorsten Glaser <>
Subject: Re: Removing sbrk and brk

Rich Felker <dalias <at>> writes:

> This seems to be optional behavior; using guard pages with all
> allocations would blow up memory usage several thousand times and

No, they aren’t accessible, so the kernel (should) never maps them
to any real RAM.

> limit the number of allocations possible on 32-bit systems to well
> under one million -- yielding an unusable system.

FSVO unusable. The default datasize ulimit on OpenBSD/i386 2.x/3.x
was 128 MiB, with the maximum having been 1 GiB (now 1.5 GiB, I
believ), anyway, so there is enough space for that. (In general,
they heavily use this – randomisation and guard pages.)

But this is getting even more OT.

> > But I’m just a downstream of omalloc. I really suggest to talk to
> > Otto Moerbeek, who, in contrast to most OpenBSD developers, is
> > pleasant to talk with and approachable.
> Might be interesting

Mmhm. I must admit I had hoped to be able to pick some fruit from
that since you do bring up things I’d not have thought of. But np.

> but pretty off-topic. Using the OpenBSD malloc
> in musl is not something that's really on the table.

OK. I was just suggesting this in case it would have been something
you could have / wanted to use, and had not thought of already.

That’s it from me on the malloc thread.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.