From: Tang Junhui <tang.jun...@zte.com.cn> Hello Mike:
> 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). Yes, It's true. but it's hard to resolve it by holding writeback lock, since not all codes in bch_writeback_thread() are held in writeback lock, actually in a previous patch I have resolved it by changing schedule() to schedule_timeout(WRITE_BACK_WAIT_CYCLE) to avoid permanent sleep. > 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. Yes, we'd better make clear the process, and find the issues and point to do refactor, but I think it is a long run, we need to do it step by step. Regards, Tang
