On Thu, Nov 06, 2008 at 11:00:17AM -0500, Thor Lancelot Simon wrote:
>
> It is almost as if crypto_mtx weren't mutexing, specifically around the
> TAILQ manipulation for the return queue -- it looks like the TAILQ calls
> in cryptoret() get a stale TAILQ_HEAD that points at freed data. We tried
> putting membar_sync() before and after the traversal of the TAILQ in
> cryptoret() and crypto_ret_q_remove() but this didn't help; I'm not sure
> it should -- do these operations guarantee that *other* CPUs have all
> pending loads/stores flushed?
I'm seeing something vaguely similar with revivesa. With some local bug
fixes, I'm consistently seeing panics in the unblock-generation code, when
I pull a thread off of a sleepqueue; the TAILQ is corrupt. This is
slightly different from what you're doing in that I'm manually
manipulating the queue and not going through a main interface.
I admit it could also be that I need some memory barriers...
Take care,
Bill