Fix SMP races in dm-crypt
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 patches 9 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | Call clone_init earlydrivers/ | +7 | 0 replies | |
| 2/3 | Do not access the bio after generic_make_requestdrivers/ | +4 | 0 replies | |
| 3/3 | Get rid of first_clone in dm-cryptdrivers/ | +1 | 0 replies |
Reviews trailers per patch
None of the 3 patches has a Reviewed-by or Acked-by of their own; the series has one for all of them.
| Patch | Christophe Saout |
|---|---|
| Series | A-b |
| 1/3 | |
| 2/3 | |
| 3/3 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH 0/3] Fix SMP races in dm-crypt
(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
Signature · 2 lines
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax