Date: Sun, 17 Apr 2011 18:23:44 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: SMP question w.r.t. reading kernel variables Message-ID: <1146958696.171268.1303079024509.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110417205950.GV48734@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sun, Apr 17, 2011 at 03:49:48PM -0400, Rick Macklem wrote:
> > Hi,
> >
> > 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?
> >
> > For example:
> > A if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0)
> > return (EPERM);
> > versus
> > B MNT_ILOCK(mp);
> > if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) {
> > MNT_IUNLOCK(mp);
> > return (EPERM);
> > }
> > MNT_IUNLOCK(mp);
> >
> > 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).
> >
> > 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.
Sounds like A should be ok then. The tests matter when dounmount()
calls VFS_SYNC() and VFS_UNMOUNT(), pretty much as you guessed. To
be honest, most of it will be the thread doing the dounmount() call,
although other threads fall through VOP_INACTIVE() while they are
terminating in VFS_UNMOUNT() and these need to do the test, too.
{ I just don't know much about the SMP stuff, so I don't know when
a cache on another core might still have a stale copy of a value.
I've heard the term "memory barrier", but don't really know what it
means.:-)
Thanks, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1146958696.171268.1303079024509.JavaMail.root>