Date: Tue, 3 Jun 2003 15:20:28 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Bosko Milekic <bmilekic@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_mbuf.c Message-ID: <20030603192028.GA53682@unixdaemons.com> In-Reply-To: <200306031919.h53JJDE3002020@repoman.freebsd.org> References: <200306031919.h53JJDE3002020@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030603192028.GA53682>