On Mon, Jun 27, 2016 at 7:51 AM, David Miller <da...@davemloft.net> wrote: > From: Eric Dumazet <eric.duma...@gmail.com> > Date: Sat, 25 Jun 2016 18:09:35 +0200 > >> From: Eric Dumazet <eduma...@google.com> >> >> Some arches have virtually mapped kernel stacks, or will soon have. >> >> tcp_md5_hash_header() uses an automatic variable to copy tcp header >> before mangling th->check and calling crypto function, which might >> be problematic on such arches. >> >> So use percpu storage as we already do for the pseudo header, >> and reduce number of crypto functions calls, as these headers >> are ridiculously small. >> >> Signed-off-by: Eric Dumazet <eduma...@google.com> >> Reported-by: Andy Lutomirski <l...@amacapital.net> >> --- >> I am not sure the md5 crypto functions have a problem with data backed >> in virtually mapped stacks, but this patch seems to remove the doubt. > > In a non-SMP build this storage will be in the kernel image itself. > > And this violates the crypto layer's requirements. > > It has to be memory taken from the page allocator or kmalloc. So > before vmalloc'd stacks, the current code is perfectly fine. And > with vmalloc'd stacks this patch trades one bug for another.
After poking around a bit: could this use crypto_shash_init + crypto_shash_finup? Those functions seem like they'll be just fine with any virtual address, and I bet they're considerably faster than using the ahash API. --Andy -- Andy Lutomirski AMA Capital Management, LLC
