Message ID | 19099.63038.425414.514063@waldo.imnotcreative.homeip.net |
---|---|
State | Not Applicable, archived |
Delegated to: | David Miller |
Headers | show |
On Mon, Aug 31, 2009 at 11:11:42AM -0500, Brad Bosch wrote: > > OK. I was looking for something subtle because the crash takes a long > time to happen. But do you agree that the race I described above also > a real bug? No I don't think it is. CHAINV_STATE_INUSE guarantees that only one entity can use ctx->err at any time. > Yes, I see that this bug must be the bug we would likely encounter first. > Apparently, async_chainiv_do_postponed was never tested? But I don't > see how the patch you proposed below helps. We still don't seem to be > returning NULL from skcipher_dequeue_givcrypt when we reach the end of > the queue because __crypto_dequeue_request is not checking for NULL > before it subtracts offset. Where we subtract the offset the pointer can never be NULL. Please try my patch. Thanks,
Index: skcipher.h =================================================================== RCS file: /share/cvs/sdg/kernels/kernel.wms/kernel_2_6_27/src/include/crypto/internal/skcipher.h,v retrieving revision 1.1.1.1.4.2 diff -u -r1.1.1.1.4.2 skcipher.h --- skcipher.h 10 Mar 2009 05:25:25 -0000 1.1.1.1.4.2 +++ skcipher.h 31 Aug 2009 15:56:50 -0000 @@ -85,8 +85,9 @@ static inline struct skcipher_givcrypt_request *skcipher_dequeue_givcrypt( struct crypto_queue *queue) { - return container_of(ablkcipher_dequeue_request(queue), - struct skcipher_givcrypt_request, creq); + struct ablkcipher_request *req = ablkcipher_dequeue_request(queue); + return req ? container_of(req, struct skcipher_givcrypt_request, creq) + : NULL; } static inline void *skcipher_givcrypt_reqctx(