SMP question w.r.t. reading kernel variables

[Rick Macklem]

> 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