On Wed, Sep 02, 2009 at 06:47:49PM -0500, Brad Bosch wrote: > > Assume the worker thread is executing between the dequeue in > async_chainiv_do_postponed and the clear_bit call in > async_chainiv_schedule_work. Further assume that we are processing > the last item on the queue so durring this time, ctx->queue.qlen = > 0. **INUSE is still set at this point. > > Meanwhile, three threads enter async_chainiv_givencrypt for the same > ctx at about the same time. > > Thread one calls test_and_set_bit which returns 1 and calls > async_cahiniv_postpone_request but suppose it has not yet enqueued. > Now INUSE is set and qlen=0. > > Next, the worker thread calls clear_bit in async_chainiv_schedule_work > but it is interrupted before it can call test_and_set_bit. Now INUSE > is clear and qlen=0 > > The test_and_set_bit in thread two is called at this moment and > returns 0 and then calls async_chainiv_givencrypt_tail. Now INUSE is > set and qlen=0. > > Thread one now locks the ctx and calls skcipher_enqueue_givcrypt and > unlocks. Now INUSE is set and qlen=1. > > Thread three calls test_and_set_bit which returns 1 and then it clears > INUSE since qlen=1 and it calls postpone with INUSE clear and qlen=1 How can thread three clear INUSE if test_and_set_bit returned 1? If thread three sees it set then it will postpone. It can only clear it if it was not set originally. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
