panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up

[Yar Tikhiy]

On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote:
> On Tuesday 27 February 2007 15:53, Alex Kozlov wrote:
> = > Yes, I switched to swap-backed md already. But the malloc-based variety is 
> = > currently the _default_ (see /etc/defaults/rc.conf)...
> = Bad default.
> 
> Filing a PR.

Keep in mind that changing the default can break existing setups.
Such setups are likely to be broken anyway, but...  E.g., if we
drop the -M flag, it will break systems with tons of RAM but little
swap using tmpmfs.  OTOH, if we add '-o reserve', that will break
systems with a too large but mostly unused tmpmfs.  A sort of a loud
announcement will be needed.

By the way, I seem to be the one responsible for the paragraph in
rc.conf(5) advocating -M "for maximum performance and system stability
at low memory conditions".  When I wrote it, I thought as follows:
were the system low on memory, additional swap activity due to mfs
would just make the system start thrashing sooner, while malloc'd
mfs would just report ENOSPC.  I was unaware of the panic back then.
Perhaps it was a misconception, either.  I haven't heard of any real
pitfalls in swap-backed mfs, and getting ENOSPC on /tmp early is no
good.

> = > Creation of a 2Gb malloc-based md should've failed on a machine with
> = > 768Mb of RAM, shouldn't it have?
> = Only if you set '-o reserve'. Memory for malloc-based md was allocated
> = dynamically.
> 
> But malloc can only allocate from RAM, right? So the amount of RAM is the hard 
> limit, which a malloc-based md can not exceed even in theory. This means, 
> md-creation should've failed...
> 
> In fact, the limit should, of course, be even lower -- and mdmfs should be 
> smart enough to substract the sizes of other kernel memory chunks from the 
> maximum.
> 
> Since even that would still not be a guarantee against running out, the system 
> should be able to recover gracefully instead of panicing. Do you agree?

FWIW, some discussion of the panic is in the audit trail of kern/87255.
Irrespective of tmpmfs defaults, this is a way to panic the system
with stock tools and without doing something totally stupid like
writing junk to /dev/mem.

-- 
Yar