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

[Yar Tikhiy]

On Mon, Mar 05, 2007 at 09:30:22PM +0200, Kostik Belousov wrote:
> 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.

The problem isn't that we don't have such a flag yet.  It's that
some parts of the kernel would rather we didn't have it. :-)  Of
course, introducing the flag or changing semantics of malloc() in
a similar way is a necessary start.

-- 
Yar