Date: Sat, 24 Nov 2012 10:46:17 -0500 From: Ryan Stone <rysto32@gmail.com> To: Attilio Rao <attilio@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Spurious witness warning when destroying spin mtx Message-ID: <CAFMmRNwn-d5P=hRxx9gyhNYJ%2B7ycVqzv-4FzXXvZGg0bC81REg@mail.gmail.com> In-Reply-To: <CAJ-FndDL18oQdFZQh4AKr9NbOc2WxWJoDVjOtkjt%2Bb7w36E_kA@mail.gmail.com> References: <CAFMmRNyYccyXFh0r2jC2Q5ynYQH09SiZNguLp8X4JWSX4Lua5w@mail.gmail.com> <CAJ-FndDL18oQdFZQh4AKr9NbOc2WxWJoDVjOtkjt%2Bb7w36E_kA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 24, 2012 at 10:01 AM, Attilio Rao <attilio@freebsd.org> wrote:
> I seriously wonder why right now we don't assume the lock is unheld.
> There are likely historically reasons for that, but I would like to
> know which one are those and eventually fix them out.
> FWIK, all the other locking primitives assume the lock is already
> unheld when destroying and I think it would be good to have that for
> mutexes as well.
>
> Can you please show which lock triggers the panic you saw?
>
> Thanks,
> Attilio
>
>
It was taskqueue_free:
void
taskqueue_free(struct taskqueue *queue)
{
TQ_LOCK(queue);
queue->tq_flags &= ~TQ_FLAGS_ACTIVE;
taskqueue_terminate(queue->tq_threads, queue);
KASSERT(TAILQ_EMPTY(&queue->tq_active), ("Tasks still running?"));
KASSERT(queue->tq_callouts == 0, ("Armed timeout tasks"));
mtx_destroy(&queue->tq_mutex);
free(queue->tq_threads, M_TASKQUEUE);
free(queue, M_TASKQUEUE);
}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNwn-d5P=hRxx9gyhNYJ%2B7ycVqzv-4FzXXvZGg0bC81REg>