Re: panic: mb_dtor_pack: ref_cnt != 1

From: Brian Fundakowski Feldman <green_at_freebsd.org>
Date: Mon, 7 Nov 2005 15:54:22 -0500
On Sat, Nov 05, 2005 at 08:47:30PM +0100, Andre Oppermann wrote:
> Gleb Smirnoff wrote:
> > 
> > On Sat, Nov 05, 2005 at 11:01:16AM +0300, Gleb Smirnoff wrote:
> > T> On Sat, Nov 05, 2005 at 05:41:05AM +0200, Giorgos Keramidas wrote:
> > T> G> On 2005-11-05 03:34, Gleb Smirnoff <glebius_at_freebsd.org> wrote:
> > T> G> >   Andre, Thierry, Sam,
> > T> G> >
> > T> G> >   this patch should fix the problems
> > T> G>
> > T> G> But it panics in mb_dtor_pack() because ext_type != EXT_CLUSTER
> > T> G> when my ath0 interface tries to associate with an AP.
> > T> G>
> > T> G> I had to change this too, to make things work:
> > T>
> > T> Updated patch.
> > 
> > One more update. Since I have removed this block:
> > 
> >                        if (*(m->m_ext.ref_cnt) == 0)
> >                                *(m->m_ext.ref_cnt) = 1;
> > 
> > I have also altered KASSERT in mb_dtor_pack(). I don't like
> > inventing an incorrect invariant check and then adding helpers
> > to avoid it being triggered.
> 
> This block is still required for the packet zone as the refcount
> is not re-initialized for mbuf+cluster out of the packet zone.
> You may up with wrong refcounts if you remove this check.  It
> is not directly related to the KASSERT in mb_dtor_pack() but to
> the way atomic_fetchadd_int() works in concurrency situations.
> 
> I have committed a fix to the same effect as your proposed patch.
> When UMA is fixed this may be reverted again.

Could you submit a UMA bug report?  There are a reasonable number
of hackers around that can fix UMA/VM bugs.  I wouldn't mind at
trying my hand at one again these days.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green_at_FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\
Received on Mon Nov 07 2005 - 19:54:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:47 UTC