Re: False lockdep completion splats with loop device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux