From owner-cvs-all  Tue Jan  9 15:59:17 2001
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id E5EC437B400; Tue,  9 Jan 2001 15:58:57 -0800 (PST)
Received: (from bmilekic@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f09NwvD53053;
	Tue, 9 Jan 2001 15:58:57 -0800 (PST)
	(envelope-from bmilekic)
Message-Id: <200101092358.f09NwvD53053@freefall.freebsd.org>
From: Bosko Milekic <bmilekic@FreeBSD.org>
Date: Tue, 9 Jan 2001 15:58:57 -0800 (PST)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/kern uipc_mbuf.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

bmilekic    2001/01/09 15:58:57 PST

  Modified files:
    sys/kern             uipc_mbuf.c 
  Log:
  In m_mballoc_wait(), drop the mmbfree mutex lock prior to calling
  m_reclaim() and re-acquire it when m_reclaim() returns. This means that
  we now call the drain routines without holding the mutex lock and
  recursing into it. This was done for mainly two reasons:
  
  (i) Avoid the long recursion; long recursions are typically bad and this
      is the case here because we block all other code from freeing mbufs
      if they need to. Doing that is kind of counter-productive, since we're
      really hoping that someone will free.
  
  (ii) More importantly, avoid a potential lock order reversal. Right now,
       not all the locks have been added to our networking code; but
       without this change, we're introducing the possibility for deadlock.
       Consider for example ip_drain(). We will likely eventually introduce
       a lock for ipq there, and so ip_freef() will be called with ipq lock
       held. But, ip_freef() calls m_freem() which in turn acquires the
       mmbfree lock. Since we were previously calling ip_drain() with mmbfree
       held, our lock order would be: mmbfree->ipq->mmbfree. Some other code
       may very well lock ipq first and then call ip_freef(). This would
       result in the regular lock order, ipq->mmbfree. Clearly, we have
       deadlock if one thread acquires the ipq lock and sits waiting for
       mmbfree while another thread calling m_reclaim() acquires mmbfree
       and sits waiting for the ipq lock.
  
  Also, make sure to add a comment above m_reclaim()'s definition briefly
  explaining this. Also document this above the call to m_reclaim() in
  m_mballoc_wait().
  
  Suggested and reviewed by: alfred
  
  Revision  Changes    Path
  1.61      +16 -13    src/sys/kern/uipc_mbuf.c



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message