On Wed, Dec 06, 2017 at 02:01:51PM +0900, Byungchul Park wrote: > On 12/6/2017 6:09 AM, Dave Chinner wrote: > >On Tue, Dec 05, 2017 at 10:07:41AM -0500, Theodore Ts'o wrote: > >>On Tue, Dec 05, 2017 at 02:16:45PM +0900, Byungchul Park wrote: > >>> > >>>Hello, > >>> > >>>I believe that the commit e319e1fbd9d42 "block, locking/lockdep: Assign > >>>a lock_class per gendisk used for wait_for_completion()" solved the > >>>false positive. > >>> > >>>Could you tell me if it doesn't handle it, with the report? Then, I > >>>will follow up and try to solve it. > >> > >>No, it doesn't handle it. And there was some discussion in the linked > >>thread on the xfs mailing list that seemed to indicate that it was not > >>a complete fix. > > > >Well, it uses a static key hidden inside the macro > >alloc_disk_node(), so every disk allocated from the same callsite > >points to the same static lockdep map. IOWs, every caller of > >alloc_disk() (i.e. the vast majority of storage devices) are > >configured to point at the same static lockdep map, regardless of > >their location in the storage stack. > > > >The loop device uses alloc_disk(). > > > >IOWs, it doesn't address the problem of false positives due to > >layering in the IO stack at all because we can still have > >filesystems both above and below the lockdep map that has been > >attached to the devices... > > Hello, > > What if we assign different classes to different loop devices? Do > you think it helps to avoid such false positives? It might, but that doesn't address all the other types of device that can also be stacked in arbitrary orders, too. Loop devices are just the obvious, easy to blame messenger. As I said right at the start: this is a generic device layering issue, not a loop device specific issue. > I'm not sure since I'm unfamiliar with the stacking stuff. It would > be appriciated if you let me know your opinion about it. I don't have an answer to the problem, and I haven't spent any time trying to think one up - I rarely use lockdep because I only ever get false positives from it. I've got other problems I need to spend my time on... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
