Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 May 2019 13:36:37 +0200
From:      Alexander Lochmann <alexander.lochmann@tu-dortmund.de>
To:        Konstantin Belousov <kib@freebsd.org>
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:  <d5a0fab7-56a1-94d0-a7f6-cb514664d8cb@tu-dortmund.de>
In-Reply-To: <20190528105529.GH2748@kib.kiev.ua>
References:  <67482bf7-be1a-8f8d-ca80-2087bfc8cf99@tu-dortmund.de> <20190528105529.GH2748@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UvUJfYpdjsYTzuinmVwFQmDAxb6ujYqdw
Content-Type: multipart/mixed; boundary="upj5BSVFJBoVVn8D7Azzj03BkKop7d49I";
 protected-headers="v1"
From: Alexander Lochmann <alexander.lochmann@tu-dortmund.de>
To: Konstantin Belousov <kib@freebsd.org>
Cc: freebsd-fs@freebsd.org, Horst Schirmeier <horst.schirmeier@tu-dortmund.de>
Message-ID: <d5a0fab7-56a1-94d0-a7f6-cb514664d8cb@tu-dortmund.de>
Subject: Re: RFC: LockDoc - Detecting Locking Bugs in the FreeBSD Kernel
References: <67482bf7-be1a-8f8d-ca80-2087bfc8cf99@tu-dortmund.de>
 <20190528105529.GH2748@kib.kiev.ua>
In-Reply-To: <20190528105529.GH2748@kib.kiev.ua>

--upj5BSVFJBoVVn8D7Azzj03BkKop7d49I
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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 visibilit=
y.
> It is safe to access a vnode without holding any locks as far as the vn=
ode
> 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.
>=20
> 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.=

>=20
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 opera=
te
> on partially initialized vnode.
Dito.

- Alex

>=20
> There could be valid reports, but digging in the present amount of repo=
rts
> with false positive is mostly equivalent to reviewing all mount/unmount=

> and vnode creation/reclamation paths.  It is too much to spend time use=
fully,
> IMO.
>=20

--=20
Technische Universit=C3=A4t 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


--upj5BSVFJBoVVn8D7Azzj03BkKop7d49I--

--UvUJfYpdjsYTzuinmVwFQmDAxb6ujYqdw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEElhZsUHzVP0dbkjCRWT7tBbw+9v0FAlztHUUACgkQWT7tBbw+
9v0nwg//XsLET6bGE7kW90igUf3oU2e6CVKDeYMDyZePTFsVc0Zl/QHLTvrF/plC
L3WKQ4gwiMul4rjzSfzVhZ6eTas1imacErUNp9l+BeWKHG5EU3jWPHBuWF9A0DNb
h2NRA1Up3hXZ5TJiygtl1re5uR8/lQf6AJVRzMVAdp+nlGmAU+oH31MJ4hX36HvT
gq49FeYyumrVDc079MpG3kcI6bbvee04UT0kcK6D1mv1FWuAfWKkNRo49fBJN+lw
SjNe/VOarNuhMM7fjEkKuUm/FXfV+qVUMQzdPdICYF9MBRK70VMPTsVaEZSQrsm7
u1LIEWFAqMwI8g61XSfJwqEPqYQOa+IWuZ4tqoiAu+9ObaMvd01lSEHVHOCFn3Iq
MUCbJYPUSxztgO0u2aGt1G/n3BFD9CgS0v+l2L1l4bYUCtYY49PVAzfgPrXTeDDP
3kJYJpsGSwNp2JulKPVo1UsCDSMCecbw2PIyWcASqhLkhvrssYpDapdC716Qu6r4
n+TpZBPWlj6qcarsIt2lE3gU+jxD2hDeXKfXjGs+rClyVsqyUHOud+U5ujqh4RYe
PL5YGvTORKYE8JSqnVbO4vAE4/M4v7QvmiD+8ljp9vSy9iq2SvZ2awkXWiaIWZjq
G+P8grLOx+gssdiEH5bY03YfbXeMs3tIEZrVjEzO/39rP4SSkGY=
=6Zy1
-----END PGP SIGNATURE-----

--UvUJfYpdjsYTzuinmVwFQmDAxb6ujYqdw--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d5a0fab7-56a1-94d0-a7f6-cb514664d8cb>