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