Date: Tue, 28 May 2019 15:11:42 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Alexander Lochmann <alexander.lochmann@tu-dortmund.de> Cc: freebsd-fs@freebsd.org, Horst Schirmeier <horst.schirmeier@tu-dortmund.de> Subject: Re: RFC: LockDoc - Detecting Locking Bugs in the FreeBSD Kernel Message-ID: <20190528121142.GI2748@kib.kiev.ua> In-Reply-To: <d5a0fab7-56a1-94d0-a7f6-cb514664d8cb@tu-dortmund.de> References: <67482bf7-be1a-8f8d-ca80-2087bfc8cf99@tu-dortmund.de> <20190528105529.GH2748@kib.kiev.ua> <d5a0fab7-56a1-94d0-a7f6-cb514664d8cb@tu-dortmund.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 28, 2019 at 01:36:37PM +0200, Alexander Lochmann wrote: > 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? No, I cannot, this was the sole point of my response. > 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190528121142.GI2748>