Re: [PATCH 0/3] Fix SMP races in dm-crypt

[Christophe Saout <christophe@saout.de>]

Hi Olaf,

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

I fully agree. I didn't notice when the sharing of the bvec went away,
but it's no longer needed and the code is simpler. As for the other two
- ouch, you're right.

Thanks for investigating fixing these things.

All four patches are

Acked-By: Christophe Saout <christophe@saout.de>