From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 17 22:23:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92689106564A for ; Sun, 17 Apr 2011 22:23:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 546DE8FC08 for ; Sun, 17 Apr 2011 22:23:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAHFnq02DaFvO/2dsb2JhbACETqIEiG+qQo9FgSmDTnoEjgM X-IronPort-AV: E=Sophos;i="4.64,229,1301889600"; d="scan'208";a="117733651" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 17 Apr 2011 18:23:44 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8B86EB3F30; Sun, 17 Apr 2011 18:23:44 -0400 (EDT) Date: Sun, 17 Apr 2011 18:23:44 -0400 (EDT) From: Rick Macklem To: Kostik Belousov Message-ID: <1146958696.171268.1303079024509.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110417205950.GV48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org Subject: Re: SMP question w.r.t. reading kernel variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 22:23:45 -0000 > 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