Coly-- It's a real circular lock dep between registration (a very rare operation) and writeback rate calculation (a fairly rare operation). While it's definitely a real issue, it's a very unlikely one to be actually encountered. (Encountering it requires the every-5-second periodic task of calculating writeback to be running, between writeback lock and register lock [a pretty short window], and then for the user to register a new cached volume) This particular issue was introduced in a8394090a9129b40f9 ("bcache: correct cache_dirty_target in __update_writeback_rate()") as part of 4.14. I'm concerned that if we keep putting in small local patches like this (especially to lock ordering or registration/deregistration behavior) that we're just moving problems around. I'm planning on working on the writeback lock this cycle to make it less contended. As part of this I plan to audit overall lock order, and to broaden use of the registration lock to better control reg/dereg ordering. That is, there's already going to be a lot of change in this path and I hope to catch/fix a lot of issues like this. Mike -- 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