From owner-cvs-src@FreeBSD.ORG Tue Jun 3 12:19:14 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 1F18937B401; Tue, 3 Jun 2003 12:19:14 -0700 (PDT) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEC0643FB1; Tue, 3 Jun 2003 12:19:13 -0700 (PDT) (envelope-from bmilekic@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.12.6/8.12.6) with ESMTP id h53JJD0U002021; Tue, 3 Jun 2003 12:19:13 -0700 (PDT) (envelope-from bmilekic@repoman.freebsd.org) Received: (from bmilekic@localhost) by repoman.freebsd.org (8.12.6/8.12.6/Submit) id h53JJDE3002020; Tue, 3 Jun 2003 12:19:13 -0700 (PDT) Message-Id: <200306031919.h53JJDE3002020@repoman.freebsd.org> From: Bosko Milekic Date: Tue, 3 Jun 2003 12:19:13 -0700 (PDT) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Subject: 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:19:14 -0000 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