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