On 6/1/17 8:57 PM, David Miller wrote: > From: David Miller <davem@xxxxxxxxxxxxx> > Date: Thu, 01 Jun 2017 17:44:19 -0400 (EDT) > >> Ok, I can reproduce this bug on my systems. I'll see if I can figure out >> what is going on. > > So I've done several tests to try and narrow down the cause. > > First, I implemented crc32c() inside of the test module, doing > exactly the same thing that lib/libcrc32c.c is doing. So this > make it use a separate tfm. > > This never fails. > > Then, I implemented a separate module "davem_crc32c.ko" that is > identical to lib/libcrc32.c except it uses it's own 'tfm' and it > exports the symbol davem_crc32c() instead of crc32c(). And finally I > adjust the test case to call davem_crc32c() instead of crc32c(). > > This also never fails. > > So it only fails if we use the lib/libcrc32.c shared with the rest of > the kernel. > > I really can't figure out yet why this sharing can even matter. The > per-computation state is all in the on-stack 'shash': > > SHASH_DESC_ON_STACK(shash, tfm); > > So invocations of crc32c() should not be able to corrupt the state of > other parallel invocations. > > I'll keep digging, but that is where I am right now. Thanks for digging. On ARM, there was a gcc bug causing similar results - I /think/ it was https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293 "programs could fail sporadically with this if an interrupt happens at the wrong instant in time and data was written onto the current stack." https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02292.html Maybe totally unrelated; if not, hope it helps. :) -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
