From owner-svn-src-head@FreeBSD.ORG Sun Sep 5 16:14:26 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8922410656B6; Sun, 5 Sep 2010 16:14:26 +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 DFBC08FC1F; Sun, 5 Sep 2010 16:14:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAB9fg0yDaFvO/2dsb2JhbACDGJ5xqBGQeIEigyd0BIoY X-IronPort-AV: E=Sophos;i="4.56,321,1280721600"; d="scan'208";a="92881407" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Sep 2010 12:14:24 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D3B29B3F20; Sun, 5 Sep 2010 12:14:24 -0400 (EDT) Date: Sun, 5 Sep 2010 12:14:24 -0400 (EDT) From: Rick Macklem To: John Baldwin Message-ID: <1589618736.502674.1283703264801.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201009050846.14288.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, dfr@freebsd.org Subject: Re: svn commit: r212216 - head/sys/fs/nfsclient X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 16:14:26 -0000 > On Saturday 04 September 2010 08:10:18 pm Rick Macklem wrote: > > Author: rmacklem > > Date: Sun Sep 5 00:10:18 2010 > > New Revision: 212216 > > URL: http://svn.freebsd.org/changeset/base/212216 > > > > Log: > > Disable use of the NLM in the experimental NFS client, since > > it will crash the kernel because it uses the nfsmount and > > nfsnode structures of the regular NFS client. > > Hmm, perhaps we could provide new VFS and/or VOP methods for NLM to > use > instead of reaching inside of those structures directly? I think we > really > want to support NLM on the new NFS client as many folks want working > NFS > locking. > Actually, passing the extra information in would just be a matter of adding extra arguments to nlm_advlock(), which is always called by the nfs clients and never as a VOP_ADVLOCK() call. This would be slightly ugly, but not that messy and doesn't require VOP changes. Where it gets ugly is that nlm_advlock() saves "struct nfsmount *nmp" in a structure called "struct nlm_feedback_arg nf" and uses that later to fiddle with fields in *nmp in nlm_down() and nlm_up() called from nlm_feedback(), which is called asynchronously from the krpc layer. (This does need to be fixed someday, since it is badly broken for forced dismounts.) If you look at nlm_down() and nlm_up(), it uses the *nmp to avoid doing a vfs_event_signal() call multiple times for a mount point. Since I don't understand what vfs_event_signal(fsid, VQ_NOTRESPLOCK, 0); actually does, I don't know if multiple calls would be a serious problem? I suppose I could add a global/malloc'd list of structures to nlm_advlock() { one for each *nmp } to keep this flag, but then I'm not sure I'd know when to get rid of elements in the list (because I wouldn't know when a mount point is dismounted?). I looked at this some time ago, when kib@ was trying to fix forced dismounts, but never got it fixed then. If this ugly bit is fixed, I think adding extra args to nlm_advlock() would make it work for both clients concurrently. If anyone can help with the ugly part, please pass along any suggestions. Thanks, rick ps: and I don't want to "own" the nlm:-)