Re: False lockdep completion splats with loop device

[Byungchul Park <byungchul.park@lge.com>]

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?

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.

-- 
Thanks,
Byungchul