> > Appearently this patch only fixed my debug printk loop that used sg_next > from scatterlist API instead of scatterwalk_sg_next from scatterwalk API. > Sorry for the noise. > Thanks for looking at this. I think I am dealing with 2 problems, one is that occasionally my buffers are from vmalloc, and needs to have some logic using vmalloc_to_page(). But I don't know if ciphers should handle that internally, blkcipher.c certainly seems to have several modes, although I do not see how to *set* them. Second problem is most likely what you were looking at. It is quite easy to make the crypto code die. For example, if I use "ccm(aes)" which can take the dst buffer, plus a hmac buffer; cipher = kmalloc( ciphersize, ... hmac = kmalloc( 16, ... sg_set_buf( &sg[0], cipher, ciphersize); sg_set_buf( &sg[1], hmac, 16); aead_encrypt()... and all is well, but if you shift hmac address away from PAGE boundary, like: hmac = kmalloc( 16 + 32, ... hmac += 32; sg_set_buf( &sg[1], hmac, 16); ie, allocate a larger buffer, and put the pointer into the page a bit. And it will die in scatterwalk very often. +32 isnt magical, any non-zero number works. Lund -- Jorgen Lundman | <lundman@xxxxxxxxxxx> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home) -- 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
