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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to