RFC: LockDoc - Detecting Locking Bugs in the FreeBSD Kernel

[Alexander Lochmann]

Thanks for your fast feedback!

On 28.05.19 12:55, Konstantin Belousov wrote:
>>
>> It might be possible that LockDoc considers a certain access as a bug
>> due to an incomplete blacklist of init and destroy functions.
>> Hence, we appreciate any feedback refining our blacklist.
> It is worse.  I did quick look, and all the issues among 5 I looked at
> where reported because the tool does not understand the vnode visibility.
> It is safe to access a vnode without holding any locks as far as the vnode
> cannot be found by other threads.
At which data type have you looked at? vnode?
Can you please tell us which functions should be blacklisted?
We have an idea in mind to overcome that issue. For now, we have to rely
on the function blacklist.
> 
> For instance, while mount (VFS_MOUNT) initializes the filesystem, VFS
> ensures that no thread could ever reach into it, e.g. by lookups.  One
> way of ensuring it is by locking the covered vnode.  So a report that
> devfs mount operates on some not-enough-locked vnode is false positive.
> 
Can you please tell us to which report you are referring to?
> Same for the freshly created vnode on the mounted filesystem, while the
> vnode not inserted into vfs hash or mount point vnode' list.  In fact,
> we typically lock the new vnode exclusively right before adding to
> hash and calling insmntque(), exactly to prevent other threads to operate
> on partially initialized vnode.
Dito.

- Alex

> 
> There could be valid reports, but digging in the present amount of reports
> with false positive is mostly equivalent to reviewing all mount/unmount
> and vnode creation/reclamation paths.  It is too much to spend time usefully,
> IMO.
> 

-- 
Technische Universität Dortmund
Alexander Lochmann                PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16                 phone:  +49.231.7556141
D-44227 Dortmund                  fax:    +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20190528/fd106eab/attachment.sig>