On Tue, 27 Jun 2000, John Polstra G wrote:

> The comment leading into kmem_malloc (in sys/vm/vm_kern.c) is
> worrying me:
>  *      This routine has its own private kernel submap (kmem_map) and object
>  *      (kmem_object).  This, combined with the fact that only malloc uses
>  *      this routine, ensures that we will never block in map or object waits.
> Actually, this function is called by m_clalloc (in
> sys/kern/uipc_mbuf.c) too.  The comment is obviously wrong.  Is it a
> problem that this assumption is violated?
>  *      Note that this still only works in a uni-processor environment and
>  *      when called at splhigh().

This comment hasn't changed significantly since Net/2 or earlier.  It
was already wrong there.  In Net/2, and still in 4.4BSDLite[1-2], both
malloc() and m_clalloc() call kmem_malloc() at splimp().  The safety
of this depends on malloc() not being called from non-network interrupt
handlers.  splhigh() would have to be used instead of splimp() if any
interrupt handler could call malloc().  malloc() can be called safely
from timeout interrupt handlers too, because splimp() masks timeouts.

In FreeBSD, malloc() can also be called from bio interrupt handlers.
splvm() = splimp() + splbio() is used for malloc() but not for m_clalloc()
or m_mballoc().

> The first part will be news to the folks running SMP. :-) The business
> about splhigh is also wrong.  But what worries me is that malloc calls
> it at splmem, while m_clalloc calls it at splimp.  Is that a problem?

malloc() calls it on kmem_map while m_clalloc() call it on mb_map, so I
think there is no problem in principle.  vm just has to call splvm()
itself and not depend on kmem_malloc() being called at splvm() (so the
comment is broken in yet another way).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to