Дожили

Пришло тут в рассылочку по FreeBSD вот такое вот письмо:

Hello.

Some time ago I faced with a problem booting with 400GB physmem.
The problem is that vm.max_proc_mmap type overflows with
such high value, and that results in a broken mmap() syscall.
The max_proc_mmap value is a signed int and roughly calculated
at vmmapentry_rsrc_init() as u_long vm_kmem_size quotient:
vm_kmem_size / sizeof(struct vm_map_entry) / 100.

Although at the time it was introduced at svn r57263 the value
was quite low (f.e. the related commit log stands:
"The value defaults to around 9000 for a 128MB machine."),
the problem is observed on amd64 where KVA space after
r212784 is factually bound to the only physical memory size.

With INT_MAX here is 0x7fffffff, and sizeof(struct vm_map_entry)
is 120, it's enough to have sligthly less than 256GB to be able
to reproduce the problem.

I rewrote vmmapentry_rsrc_init() to set large enough limit for
max_proc_mmap just to protect from integer type overflow.
As it's also possible to live tune this value, I also added a
simple anti-shoot constraint to its sysctl handler.
I'm not sure though if it's worth to commit the second part.

As this patch may cause some bikeshedding,
I'd like to hear your comments before I will commit it.

http://plukky.net/~pluknet/patches/max_proc_mmap.diff