On 11/18/2017 09:32 AM, Coly Li wrote: > On 19/11/2017 1:01 AM, Michael Lyle wrote: >> 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) >> > > Hi Mike, > > Thanks for response. It seems I can almost 100% reproduce this lockdep > warning on my simple test environment. Just compiling mainline kernel > with locking debug enabled, then attach a backing device to a cache > device, and use fio to write around 30G 4KB blocksize data on bcache > device. This is why this warning grabs my eyes. > > From the lockdep warning it seems this should be very rare to happen, > but I don't know why it happens almost every time in my testing... Coly-- Do you get an actual deadlock here, or just a lockdep warning? The lockdep warning just lets you know that locks were acquired in different orders and that an issue is possible. I'd expect a lockdep warning every time, but almost never an actual deadlock. > [snip] > Another warning is the nested locking in btree levels, so far I don't > have no idea what happens here yet .... I am guessing there is a missing free of a lock-- which only creates problems with lockdep on but we should fix it. Mike
