From owner-cvs-src@FreeBSD.ORG Tue Jun 3 12:20:31 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7D8837B401; Tue, 3 Jun 2003 12:20:31 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1FEA43FA3; Tue, 3 Jun 2003 12:20:30 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])h53JKTZn053823; Tue, 3 Jun 2003 15:20:29 -0400 (EDT) Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.9/8.12.1/Submit) id h53JKSCR053822; Tue, 3 Jun 2003 15:20:28 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) X-Authentication-Warning: angelica.unixdaemons.com: bmilekic set sender to bmilekic@unixdaemons.com using -f Date: Tue, 3 Jun 2003 15:20:28 -0400 From: Bosko Milekic To: Bosko Milekic Message-ID: <20030603192028.GA53682@unixdaemons.com> References: <200306031919.h53JJDE3002020@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200306031919.h53JJDE3002020@repoman.freebsd.org> User-Agent: Mutt/1.4.1i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_mbuf.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2003 19:20:32 -0000 Oops: Panic and way to reproduce provided by: silby On Tue, Jun 03, 2003 at 12:19:13PM -0700, Bosko Milekic wrote: > bmilekic 2003/06/03 12:19:13 PDT > > FreeBSD src repository > > Modified files: > sys/kern subr_mbuf.c > Log: > Fix a potential bucket leak where when freeing to an empty bucket > we failed to put the bucket back into the general cache/container. > > Also, fix a bad assumption. There was a KASSERT() that aimed to > guarantee that whenever the pcpu container's mc_starved was > 0, > that whatever the bucket we were freeing to was an empty bucket, > assuming it belonged to the pcpu container cache. However, there > is at least one case where this is not true anymore; consider: > 1) All containers empty, next thread to try to alloc will touch > a pcpu container, notice it's empty, and increment the pcpu > container's mc_starved. > 2) Some other thread frees an mbuf belonging to a bucket in > the general cache/container. Then it frees another mbuf > belonging to the same bucket (still in gen container). > 3) Some third thread tries to allocate an mbuf from the pcpu > container and, since empty, grabs one mbuf now available > in the general cache and moves the non-empty bucket from > which it took 1 mbuf and to which the thread in (2) freed > to, and moves it to the pcpu container. > 4) A final thread tries to free an mbuf belonging to the > NON-EMPTY bucket mentionned in (2) and (3) and, since > the pcpu container's mc_starved is > 0, but the bucket > is obviously non-empty, it trips on the KASSERT. > This meant that one could potentially get a panic in some > cases when out of mbufs and clusters. The problem could > be mitigated by commenting out some cv_signal() calls, > but I'm assuming that was pure coincidence and this is > the correct fix. > > Revision Changes Path > 1.51 +29 -57 src/sys/kern/subr_mbuf.c > -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org