[dm-devel] [PATCH 0/3] Fix SMP races in dm-crypt
Christophe Saout
christophe at saout.de
Thu Mar 22 20:51:16 UTC 2007
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 at saout.de>
>
> 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?
More information about the dm-devel
mailing list