From owner-freebsd-current@FreeBSD.ORG  Tue May 13 22:45:43 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 705B637B401; Tue, 13 May 2003 22:45:43 -0700 (PDT)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id B6E9143F3F; Tue, 13 May 2003 22:45:42 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.12.9/8.12.9) with ESMTP id h4E5jWM7052038;
	Tue, 13 May 2003 22:45:36 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200305140545.h4E5jWM7052038@gw.catspoiler.org>
Date: Tue, 13 May 2003 22:45:32 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: rwatson@FreeBSD.org
In-Reply-To: <Pine.NEB.3.96L.1030513171731.72145j-100000@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
cc: bsder@allcaps.org
cc: alfred@FreeBSD.org
cc: current@FreeBSD.org
Subject: Re: rpc.lockd spinning; much breakage
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2003 05:45:43 -0000

On 13 May, Robert Watson wrote:
> On Tue, 13 May 2003, Don Lewis wrote:

> So that change sounds like a winner for that issue.  This leaves the
> problem of getting EACCES back for locks contended by an NFS client
> against consumers directly on the server, rather than the client retrying. 

Non-blocking, blocking, or both?  What about the case if the lock is
held by another client?

I think the following code in lock_answer() is the culprit:

        if (version == NLM_VERS4)
                switch (result) {
                case nlm4_granted:
                        ans.la_errno = 0;
                        break;
                default:
                        ans.la_errno = EACCES;
                        break;
                case nlm4_denied:
                        if (pid_p == NULL)
                                ans.la_errno = EACCES;
                        else {
                                /* this is an answer to a nlm_test msg */
                                ans.la_set_getlk_pid = 1;
                                ans.la_getlk_pid = *pid_p;
                                ans.la_errno = 0;
                        }
                        break;

I think the last assignment to ans.la_errno in this snippet of code
should be EAGAIN.  I'm working under the assumption that this case
handles a non-blocking lock being denied, and that the blocking case is
handled by nlm4_blocked a bit further down.  It looks like pid_p is only
used to implement fcntl(fd, F_GETLK, ...).  If the code above is
incorrect, the NFSv2 code below will need a similar fix.

I don't know if the the client will retry in the blocking case or if the
server side will have to grow the code to poll any local locks that it
might encounter.