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. -- 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
