On 5/31/17 11:19 AM, Eric Sandeen wrote: > On 5/31/17 10:53 AM, David Miller wrote: >> From: Anatoly Pugachev <matorola@xxxxxxxxx> >> Date: Wed, 31 May 2017 14:56:52 +0300 >> >>> While debugging occasional crc32c checksum errors with xfs disk reads on >>> sparc64 (T5 [sun4v] 3.6 GHz CPU ldom, debian unstable/sid), Eric have found >>> that crc32c sometimes returns wrong checksum for data. Eric made a simple >>> test kernel module (included), which produce the following results on my >>> sparc64 machines: > > cc: linux-xfs, because this problem cropped up on xfs/sparc. FWIW, the testcase (module which does crc = crc32c(CRC_SEED, data, 512); 1 million times in a loop on the same data, and printk's if the result ever changes) does not fail on x86_64 or ARM (well, not after a gcc bug was fixed on ARM ...) -Eric > -Eric > >> I don't think that crc32c() is thread safe because of the way it is >> implemented with a shared TFM crypto object allocated once at boot >> time. >> >> I think you are seeing the corruption any time an interrupt comes in >> on the same cpu as your test module is running on and does a crc32c() >> calculation, corrupting the context key value being used by your >> invocation. >> >> At least that's my guess, I could have misread how the key is stored >> and managed around operations. >> >> Can you try something like disabling cpu IRQs around the crc32c() function >> in lib/libcrc32c.c? Something like: >> >> u32 retval; >> >> local_irq_disable(); >> >> shash->tfm = tfm; >> shash->flags = 0; >> *ctx = crc; >> >> err = crypto_shash_update(shash, address, length); >> BUG_ON(err); >> >> retval = *ctx; >> >> local_irq_enable(); >> >> return retval; >> >> Thanks. >> > -- > 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 > -- 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
