It is very arbitrary. But its not so easy to fix. Ok, the diff is only
about 8 lines, but its the other things like testing and compat that
make it hard.
On May 19, 2008, at 8:38 AM, Hannah Schroeter <[EMAIL PROTECTED]> wrote:
Hi!
On Mon, May 12, 2008 at 05:49:57PM +0200, Otto Moerbeek wrote:
[...]
De fsck_ffs code allocates a number of arrays directly depending on
the # of indodes in setup(), totalling 4 bytes per inode. Some other
data is also needed, so it's not surprise you hit the 1G data space
limit.
Any chance to get rid of that 1G limit that seems more and more
arbitrary nowadays? I remember reading that just upping that define in
/usr/src/sys/arch/i386/include/vmparam.h doesn't help, i.e. that
something else interacts with that parameter too. I know that on
processors that have neither PAE nor non-PAE NX support one might
not be
able to protect all writable data from execution eventually, if a
program should in fact allocate more than 1G (once the kernel should
need to allocate it with lower virtual addresses). However, the kernel
could be made to prefer high addresses for writable, non-executable
data
(mmap without PROT_EXEC), and the super-user is to decide on how she
sets up the data size resource limits, so if that's <= 1G the
protection
should remain to be fine.
[...]
Kind regards,
Hannah.
