cvs commit: src/sys/kern subr_mbuf.c

[Bosko Milekic]

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 at unixdaemons.com
bmilekic at FreeBSD.org