From nobody@FreeBSD.org  Sun Mar 22 14:00:13 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 89A61106566C
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 22 Mar 2009 14:00:13 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 742E08FC1E
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 22 Mar 2009 14:00:13 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n2ME0C0l066551
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 22 Mar 2009 14:00:12 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n2ME0CV7066550;
	Sun, 22 Mar 2009 14:00:12 GMT
	(envelope-from nobody)
Message-Id: <200903221400.n2ME0CV7066550@www.freebsd.org>
Date: Sun, 22 Mar 2009 14:00:12 GMT
From: Matthias Schuendehuette <msch@snafu.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Cancel of a NFS-lock fails repeatedly
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         132934
>Category:       kern
>Synopsis:       [nfs] Cancel of a NFS-lock fails repeatedly
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    jh
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Mar 22 14:10:01 UTC 2009
>Closed-Date:    Mon Oct 25 15:53:03 UTC 2010
>Last-Modified:  Mon Oct 25 15:53:03 UTC 2010
>Originator:     Matthias Schuendehuette
>Release:        6.4 + 7.1
>Organization:
SIEMENS AG
>Environment:
>Description:
If a NFS client (in my case a HP-UX 11.11 client) tries to cancel a NFS lock, the FreeBSD-Server doesn't reply at all.  This is true for FreeBSD-6.4 and FreeBSD 7.1. (with and without kernel support for NFS locking).

Since NFS-Serving is the major task of our FreeBSD servers, this error is a show-stopper for us, which prevents us from further upgrading the operating system.

FreeBSD 6.3 and 7.0 do not show such behaviour.
>How-To-Repeat:
Mount a filesystem from a FreeBSD-Server on a HP-UX 11.11 machine via NFS V3.
Try to lock a file (that works) then try to remove the lock. You'll wait forever...

I found the problem with my (HP-UX)homedirectory on a FreeBSD NFS-Server. The login shell locks .profile and hangs after the last statement of .profile.

Wireshark shows a continuing stream of "NLM V4 CANCEL MSG"es from the client to the server, which will never be answered.
>Fix:


>Release-Note:
>Audit-Trail:

From: Zachary Loafman <zachary.loafman@isilon.com>
To: bug-followup@FreeBSD.org, msch@snafu.de
Cc:  
Subject: Re: kern/132934: [nfs] Cancel of a NFS-lock fails repeatedly
Date: Fri, 8 May 2009 11:48:08 -0700

 I scrounged up an HP-UX client at Isilon and testing it against the
 kernel NLM code using the flock test in tools/regression/file/flock. It
 passes with flying colors:
 
 # ./flock /mnt/zl/hpux; echo $?
 1 - F_GETLK on unlocked region: SUCCEED
 2 - F_SETLK on locked region: SUCCEED
 3 - F_SETLKW on locked region: SUCCEED
 4 - F_GETLK on locked region: SUCCEED
 5 - F_SETLKW simple deadlock: SUCCEED
 6 - F_SETLKW complex deadlock: SUCCEED
 7 - F_SETLK shared lock on exclusive locked region: SUCCEED
 8 - F_SETLK shared lock on share locked region: SUCCEED
 9 - F_SETLK exclusive lock on share locked region: SUCCEED
 10 - trying to set bogus pid or sysid values: SUCCEED
 12 - F_SETLKW on locked region which is then unlocked: SUCCEED
 13 - F_SETLKW on locked region, race with owner: SUCCEED
 14 - soak test: SUCCEED
 15 - flock(2) semantics: SUCCEED
 0
 # uname -a
 HP-UX cqhp01 B.11.31 U ia64 3687355900 unlimited-user license
 
 I'm going to try some other experiments now, but if you have any hints
 on a tighter repro, I'd appreciate it.

From: Zachary Loafman <zachary.loafman@isilon.com>
To: Matthias Schuendehuette <msch@snafu.de>
Cc: dfr@rabson.org, John Gemignani <john.gemignani@isilon.com>,
	bug-followup@FreeBSD.org
Subject: Re: kern/132934: [nfs] Cancel of a NFS-lock fails repeatedly
Date: Sat, 9 May 2009 05:00:36 -0700

 Matthias -
 
 I think I figured it out. As I mentioned last night, the AUTH coming
 from the HP-UX 11.11 servers is AUTH_NULL. There's a check in
 nlm_get_vfs_state that'll result in AUTH_NULL requests getting bounced.
 
 To disable the kernel lock manager completely, you need to comment out
 the NFSLOCKD option and stop the module from building. One way to do
 this is to use the MODULE_OVERRIDE directive in your conf file, like:
 
 makeoptions    MODULES_OVERRIDE="acpi"
 
 Then rebuild and reinstall the kernel. If you go that route, you'll need
 to figure out which modules you need before doing that. A 'kldstat' on
 your system would tell you if you're using any modules beyond the base.
 The above is all I really need on my i386 box, but YMMV.
 
 Alternately, for a quick test you could do something like this:
 
 # kldunload nfslockd  # may fail if it's not loaded
 # mv /boot/kernel/nfslockd.ko /boot/kernel/nfslockd.ko.aside
 # rpc.lockd
 Can't find or load kernel support for rpc.lockd - using non-kernel implementation
 
 That last message should tell you that the userland lockd is running.
 
 Please note: The userland lockd has many limitations. FreeBSD will
 likely drop support for it in a later release.
 
 ...Zach
State-Changed-From-To: open->feedback 
State-Changed-By: jh 
State-Changed-When: Sat Mar 20 09:33:18 UTC 2010 
State-Changed-Why:  
Is this problem still relevant to the new NFS locking implementation? 


Responsible-Changed-From-To: freebsd-bugs->jh 
Responsible-Changed-By: jh 
Responsible-Changed-When: Sat Mar 20 09:33:18 UTC 2010 
Responsible-Changed-Why:  
Track. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=132934 
State-Changed-From-To: feedback->closed 
State-Changed-By: jh 
State-Changed-When: Mon Oct 25 15:53:02 UTC 2010 
State-Changed-Why:  
Feedback timeout. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=132934 
>Unformatted:
