These days I devoted to reading md codes in 2.6.12_r11 I have noticed that you applied two different locking strategy in these two functions: end_read_request: if (uptodate) { set_bit(R5_UPTODATE, &sh->dev[i].flags); } else { md_error(conf->mddev, conf->disks[i].rdev); clear_bit(R5_UPTODATE, &sh->dev[i].flags); } rdev_dec_pending(conf->disks[i].rdev, conf->mddev); clear_bit(R5_LOCKED, &sh->dev[i].flags); set_bit(STRIPE_HANDLE, &sh->state); release_stripe(sh); end_write_request: spin_lock_irqsave(&conf->device_lock, flags); if (!uptodate) md_error(conf->mddev, conf->disks[i].rdev); rdev_dec_pending(conf->disks[i].rdev, conf->mddev); clear_bit(R5_LOCKED, &sh->dev[i].flags); set_bit(STRIPE_HANDLE, &sh->state); __release_stripe(conf, sh); spin_unlock_irqrestore(&conf->device_lock, flags); if these two function excuting on different CPU, the spin lock can work well? and why? -------------- liyiming 2006-12-12 - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html