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

[Kostik Belousov]

On Mon, Mar 05, 2007 at 10:17:14PM +0300, Yar Tikhiy wrote:
> On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote:
> > On Monday 05 March 2007 08:23, Yar Tikhiy wrote:
> > = > How will it break them?  swap backing only touches swap if there is
> > = > memory pressure, i.e. precisely the situation in which malloc backing
> > = > will panic.
> > = 
> > = I forgot that in BSD swap wouldn't be allocated in advance to its
> > = consumers.  Then removing the -M flag and making swap backing the
> > = default is a very sound choice.  Thank you for correcting me.
> > 
> > Yar, would you change the man-page's advice and the default, then?
> 
> Yes, I'll be glad to if no objections arise until I finish updating
> my CURRENT machine, i.e., tomorrow. :-)
> 
> > Someone still needs to look into the panic... Who would that be?
> 
> Obviously, Mr(s). Someone. :-)
> 
> The md case exposes a quite tangled nature of the problem.  Funnily
> enough, kernel malloc() cannot just fail in the case because it
> must not fail if called with M_WAITOK.  This means that the system
> has quite a rough choice:
> 
> - put the requesting thread to sleep forever;
> - grow kmem_map, eventually sacrifice all RAM to the greedy thread
>   and die sooner or later;
> - panic immediately.
> 
> If all malloc() callers in the kernel were ready to deal with
> allocation failure, the system could just tell the greedy thread
> to buzz off.  But too many kernel parts depend on malloc(M_WAITOK)
> never failing.  Perhaps it's the root of the problem.

Mark callers that are ready for M_WAITOK failure with some additional
flag, like M_FAILOK (feel free to propose meaningful name there).
At least malloc()-based md could then use it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070305/c8182156/attachment.pgp