From owner-svn-src-all@FreeBSD.ORG Wed Apr 20 12:09:34 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0826E106566B; Wed, 20 Apr 2011 12:09:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 175CD8FC13; Wed, 20 Apr 2011 12:09:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAMTLrk2DaFvO/2dsb2JhbACEUKFjtiSRKoEpg056BI4i X-IronPort-AV: E=Sophos;i="4.64,246,1301889600"; d="scan'208";a="118948223" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 20 Apr 2011 08:09:32 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3E176B3FED; Wed, 20 Apr 2011 08:09:32 -0400 (EDT) Date: Wed, 20 Apr 2011 08:09:32 -0400 (EDT) From: Rick Macklem To: Pawel Jakub Dawidek Message-ID: <630616771.329277.1303301372199.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110420054655.GD1826@garage.freebsd.pl> 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: svn-src-head@freebsd.org, Rick Macklem , svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r220877 - head/sys/fs/nfsclient X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 12:09:34 -0000 > > + tmp_off = uio->uio_offset + uio->uio_resid; > > + mtx_lock(&nmp->nm_mtx); > > + if (tmp_off > nmp->nm_maxfilesize || tmp_off < uio->uio_offset) { > > + mtx_unlock(&nmp->nm_mtx); > > return (EFBIG); > > + } > > + mtx_unlock(&nmp->nm_mtx); > > I don't think you need the lock to protect nm_maxfilesize. Can it > change > from under us? My guess is that it is set on mount time and is not > modified afterwards. > Good question. For NFSv3 - it is only modified by the first fsinfo RPC and that normally happens at mount time, as you guessed above. (This is consistent with RFC1813, which defines the fsinfo RPC as getting non-volatile information.) For NFSv4 - it gets it each time VFS_STATFS() happens. I am not sure that this is correct, but I don't know of anywhere in RFC3530 where it states that this attribute will not change. In practice, I suspect that servers seldom, if ever, change it. So, it is unlikely to change and I'd be comfortable taking the mutex lock off the check for it, if others are? (As you might be aware, I started a thread on hackers-freebsd@ where my question was basically "do you need to mutex lock when you read a global variable". My main concern there was a case that I'm working on w.r.t. forced dismounts. jhb@ suggested that he thinks it is good practice to always lock, to play it safe. At least that was my interpretation?) rick