(I'm resending this, because it seems mailman ate this posting the first time around - apologies if you're seeing this twice). I investigated kernel Bug 5948 (Oops when accessing SATA with device mapper on AMD 64 X2) to help cut down on the number of open bugs. The problem reported in that bug seems to be caused by memory pressure when writing - crypt_alloc_buffer can return less than the full number of pages required. In that case, the bio is split, but we're keeping a pointer to the first chunk of the request around in first_clone, and copy it. If the first clone completes I/O while we're cloning it, we oops on garbage in the bvec. I was able to reproduce this on 2.6.20 - and the following patches seem to fix it for me. dm-crypt-clone_init-early We need to call clone_init early on, before we can conceivably ever call bio_put on the clone dm-crypt-clone-race Do no access bios after generic_make_request dm-crypt-drop-first_clone Drop the first_clone business, and always allocate a fresh bio. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play okir@xxxxxx | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
