Date: Sun, 17 Apr 2011 23:59:50 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-hackers@freebsd.org Subject: Re: SMP question w.r.t. reading kernel variables Message-ID: <20110417205950.GV48734@deviant.kiev.zoral.com.ua> In-Reply-To: <397135152.167477.1303069788579.JavaMail.root@erie.cs.uoguelph.ca> References: <397135152.167477.1303069788579.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--kAOhhqH5290wydqT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Apr 17, 2011 at 03:49:48PM -0400, Rick Macklem wrote:
> Hi,
>=20
> I should know the answer to this, but... When reading a global kernel
> variable, where its modifications are protected by a mutex, is it
> necessary to get the mutex lock to just read its value?
>=20
> For example:
> A if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) !=3D 0)
> return (EPERM);
> versus
> B MNT_ILOCK(mp);
> if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) !=3D 0) {
> MNT_IUNLOCK(mp);
> return (EPERM);
> }
> MNT_IUNLOCK(mp);
>=20
> My hunch is that B is necessary if you need an up-to-date value
> for the variable (mp->mnt_kern_flag in this case).
>=20
> Is that correct?
mnt_kern_flag read is atomic on all architectures.
If, as I suspect, the fragment is for the VFS_UNMOUNT() fs method,
then VFS guarantees the stability of mnt_kern_flag, by blocking
other attempts to unmount until current one is finished.
If not, then either you do not need the lock, or provided snipped
which takes a lock is unsufficient, since you are dropping the lock
but continue the action that depends on the flag not being set.
--kAOhhqH5290wydqT
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAk2rVMYACgkQC3+MBN1Mb4gB3ACePUpmsKcRi+YR8JrDJV9eILIE
FvIAoOd7y/4YwblAStOkizqUNQ+0bamZ
=6NGS
-----END PGP SIGNATURE-----
--kAOhhqH5290wydqT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110417205950.GV48734>