On Fri, 2016-10-14 at 10:05 +0100, Ard Biesheuvel wrote: > > Indeed. And the decrypt path does the same for auth_tag[]. Hadn't gotten that far, due to the BUG_ON() in CONFIG_DEBUG_SG in the encrypt path :) > But that still means there are two separate problems here, one which > affects the WPA code, and one that only affects the generic CCM > chaining mode (but not the accelerated arm64 implementation) Yes. The generic CCM chaining still doesn't typically have a request on the stack though. In fact, ESP (net/ipv4/esp4.c) for example will do temporary allocations with kmalloc for every frame, it seems. > Unsurprisingly, I would strongly prefer those to be fixed properly > rather than backing out my patch, but I'm happy to help out whichever > solution we reach consensus on. Yeah, obviously, it would be good to use the accelerated versions after all. > I will check whether this removes the issue when not using > crypto/ccm.ko Ok. I think we can probably live with having those 48 bytes in per-CPU buffers, but I suppose we don't really want to have ~500. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
