On Tue, 2 Sep 2014 09:05:15 -0400, Chris Mason wrote: >>>>> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c >>>>> index 08e65e9..56b1546 100644 >>>>> --- a/fs/btrfs/disk-io.c >>>>> +++ b/fs/btrfs/disk-io.c >>>>> @@ -698,7 +719,12 @@ static void end_workqueue_bio(struct bio *bio, int >>>>> err) >>>>> >>>>> fs_info = end_io_wq->info; >>>>> end_io_wq->error = err; >>>>> - btrfs_init_work(&end_io_wq->work, end_workqueue_fn, NULL, NULL); >>>>> + >>>>> + if (likely(end_io_wq->metadata != BTRFS_WQ_ENDIO_DIO_REPAIR)) >>>>> + btrfs_init_work(&end_io_wq->work, end_workqueue_fn, NULL, >>>>> + NULL); >>>>> + else >>>>> + INIT_WORK(&end_io_wq->work.normal_work, dio_end_workqueue_fn); >>>> >>>> It's not clear why this one is using INIT_WORK instead of >>>> btrfs_init_work, or why we're calling directly into queue_work instead >>>> of btrfs_queue_work. What am I missing? >>> >>> I'm sorry that I forgot writing the explanation in this patch's changlog, >>> I wrote it in Patch 0. >>> >>> "2.When the io on the mirror ends, we will insert the endio work into the >>> system workqueue, not btrfs own endio workqueue, because the original >>> endio work is still blocked in the btrfs endio workqueue, if we insert >>> the endio work of the io on the mirror into that workqueue, deadlock >>> would happen." >> >> Can you elaborate the deadlock? >> >> Now that buffer read can insert a subsequent read-mirror bio into btrfs endio >> workqueue without problems, what's the difference? > > We do have problems if we're inserting dependent items in the same > workqueue. > > Miao, please make a repair workqueue. I'll also have a use for it in > the raid56 parity work I think.
OK, I'll update the patch soon. Thanks Miao -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
