Am Donnerstag, den 22.03.2007, 13:41 -0700 schrieb Andrew Morton: > > Hi Olaf, > > err, which Olaf are you addressing? He is not cc'ed. Stupid client... didn't notice. Thanks . > > > (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@xxxxxxxx> > > I'm hunting around, but cannot find the patches to which you refer. Maybe > they're on dm-devel only? Yes, but Olaf also Cc'ed you. Didn't you get them? -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
