Tang, On 10/09/2017 10:38 PM, tang.junhui@xxxxxxxxxx wrote:
[snip] As Far as now, except this issue, I can't see any more race during detach, so I don't think we need to take a writeback lock. Could you please show me what problem you worried about?
Ugh, this is partially my fault for not knowing the code path well. keep confusing myself.
One race I think I see: we unset the dirty bit before setting ourselves interruptible. Can bch_writeback_add/queue wake writeback before then (and then writeback sets itself interruptible and never wakes up)?
bch_writeback_add usually holds the writeback lock, but the writeback lock is already released at this time (and bch_writeback_queue as used by bch_cached_dev_detach doesn't traverse the writeback lock).
There's a pretty intricate set of dependencies between the dirty bit, the state in the superblock, the refcount, the writeback lock, and the runnable state of the writeback thread. It feels dangerous, but maybe after I draw graphs of all the dependencies I'll feel better.
Writeback locking needs refactoring for performance anyways-- maybe this can simplified at the same time.
Mike
Regards, Tang -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
