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
Attachment:
pgpNcIyQ9_FKW.pgp
Description: PGP signature