Date: Tue, 13 May 2003 22:45:32 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: rwatson@FreeBSD.org Cc: current@FreeBSD.org Subject: Re: rpc.lockd spinning; much breakage Message-ID: <200305140545.h4E5jWM7052038@gw.catspoiler.org> In-Reply-To: <Pine.NEB.3.96L.1030513171731.72145j-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305140545.h4E5jWM7052038>