* Non-blocking lock requests during the grace period
@ 2002-11-14 19:56 Juan Gomez
2002-11-15 2:33 ` Trond Myklebust
0 siblings, 1 reply; 7+ messages in thread
From: Juan Gomez @ 2002-11-14 19:56 UTC (permalink / raw)
To: nfs; +Cc: linux-kernel
I found out that the current Linux client of lockd blocks non-blocking lock
requests while the server is in the grace period.
I think this is incorrect behavior and I am wondering if the will exists
out there to correct this and return "resource not available"
to the process when a request is for a *non-blocking* lock while the server
is in the grace period.
It is extremelly odd to issue a *non-blocking* call and be blocked in the
kernel for about a minute when the server happens
to be in the grace period.
This consists of a minor change to nlmclnt_call() and I would send the
patch if someone will review and include it.
Regards, Juan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Non-blocking lock requests during the grace period
2002-11-14 19:56 Non-blocking lock requests during the grace period Juan Gomez
@ 2002-11-15 2:33 ` Trond Myklebust
0 siblings, 0 replies; 7+ messages in thread
From: Trond Myklebust @ 2002-11-15 2:33 UTC (permalink / raw)
To: Juan Gomez; +Cc: nfs, linux-kernel
>>>>> " " == Juan Gomez <juang@us.ibm.com> writes:
> I found out that the current Linux client of lockd blocks
> non-blocking lock requests while the server is in the grace
> period. I think this is incorrect behavior and I am wondering
> if the will exists out there to correct this and return
> "resource not available" to the process when a request is for a
> *non-blocking* lock while the server is in the grace period.
Would the following fix it?
Cheers,
Trond
--- linux-2.5.47/fs/lockd/clntproc.c.orig 2002-09-29 10:15:13.000000000 -0400
+++ linux-2.5.47/fs/lockd/clntproc.c 2002-11-14 21:32:26.000000000 -0500
@@ -256,10 +256,8 @@
msg.rpc_cred = NULL;
do {
- if (host->h_reclaiming && !argp->reclaim) {
- interruptible_sleep_on(&host->h_gracewait);
- continue;
- }
+ if (host->h_reclaiming && !argp->reclaim)
+ goto wait_on_grace;
/* If we have no RPC client yet, create one. */
if ((clnt = nlm_bind_host(host)) == NULL)
@@ -296,6 +294,9 @@
dprintk("lockd: server returns status %d\n", resp->status);
return 0; /* Okay, call complete */
}
+wait_on_grace:
+ if (!argp->block)
+ return -EAGAIN;
/* Back off a little and try again */
interruptible_sleep_on_timeout(&host->h_gracewait, 15*HZ);
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Non-blocking lock requests during the grace period
2002-11-15 19:09 Juan Gomez
@ 2002-11-15 20:01 ` Trond Myklebust
0 siblings, 0 replies; 7+ messages in thread
From: Trond Myklebust @ 2002-11-15 20:01 UTC (permalink / raw)
To: Juan Gomez; +Cc: linux-kernel, nfs
>>>>> " " == Juan Gomez <juang@us.ibm.com> writes:
> (note that F_GETLK man page does not provide EAGAIN as a
> possible error code).
Hmm....
In the Single UNIX spec, there appears to be a rather unexpected
difference between expected behaviour for lockf and fcntl here:
http://www.db.opengroup.org/cgi-bin/dbcgi?CALLER=sud2/indx.tpl&TOKEN=FIYR&TPL=sd_fileframe&dir=xsh&file=lockf
[EACCES] or [EAGAIN]
The function argument is F_TLOCK or F_TEST and the section is already
locked by another process.
OTOH
http://www.db.opengroup.org/cgi-bin/dbcgi?CALLER=sud2/indx.tpl&TOKEN=FIYR&TPL=sd_fileframe&dir=xsh&file=fcntl
[EACCES] or [EAGAIN]
The cmd argument is F_SETLK, and one of the following conditions
is true:
* The type of lock (l_type) is shared ( F_RDLCK) or exclusive
( F_WRLCK), and the segment of a file to be locked is
already exclusive locked by another process.
* The type of lock is exclusive, and some portion of the file
segment to be locked is already shared locked or exclusive
locked by another process.
Cheers,
Trond
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Non-blocking lock requests during the grace period
@ 2002-11-15 19:09 Juan Gomez
2002-11-15 20:01 ` Trond Myklebust
0 siblings, 1 reply; 7+ messages in thread
From: Juan Gomez @ 2002-11-15 19:09 UTC (permalink / raw)
To: trond.myklebust; +Cc: linux-kernel, nfs
On second thoughts, I think I wonder if we want to fail F_GETLK while in
the grace period? seems like we won't there it makes sense to hold until
the grace period clears otherwise the client app may think there is
something wrong (note that F_GETLK man page does not provide EAGAIN as
a possible error code).
The case for F_SETLK is different as the result is expected when the lock
is not available due to a previous holder (or, as I want to do it, when the
lock is not available ether by previous holder or grace period).
Juan
|---------+---------------------------->
| | Trond Myklebust |
| | <trond.myklebust@|
| | fys.uio.no> |
| | |
| | 11/15/02 09:35 AM|
| | Please respond to|
| | trond.myklebust |
| | |
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------|
| |
| To: Juan Gomez/Almaden/IBM@IBMUS |
| cc: linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net |
| Subject: Re: Non-blocking lock requests during the grace period |
| |
| |
>-------------------------------------------------------------------------------------------------------------------------|
> 2.-I also have this part enclosed in the if(resp->status ==
> NLM_LCK_DENIED_GRACE_PERIOD) as follows:
> if(resp->status == NLM_LCK_DENIED_GRACE_PERIOD) {
> blah blah...
> wait_on_grace:
> if ((proc == NLMPROC_LOCK) &&
> !argp->block)
> return -EAGAIN
> } else {
> ....
> }
> This with the intention to be very specific as to when we want
> the return -EAGAIN to be called.
The above means that you will still block on a F_GETLK query...
In any case, why would we want to return -EAGAIN in one case where
argp->block isn't set, and not in another? If there are cases where we
want to block and where we are not currently setting argp->block (the
only one I can think of might be NLMPROC_UNLOCK), then we should fix
the caller.
Cheers,
Trond
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Non-blocking lock requests during the grace period
@ 2002-11-15 18:48 Juan Gomez
0 siblings, 0 replies; 7+ messages in thread
From: Juan Gomez @ 2002-11-15 18:48 UTC (permalink / raw)
To: trond.myklebust; +Cc: linux-kernel, nfs
Guess you are right. I was just worried that this code does not become
active for any other case than the one we were trying to fix.
We should also return when called from test as it should be non-blocking.
Then we do have the problem with UNLOCKs so we
have two choices: either fix the caller or just check for either lock or
test and block. I rather the last one.
Juan
|---------+---------------------------->
| | Trond Myklebust |
| | <trond.myklebust@|
| | fys.uio.no> |
| | |
| | 11/15/02 09:35 AM|
| | Please respond to|
| | trond.myklebust |
| | |
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------|
| |
| To: Juan Gomez/Almaden/IBM@IBMUS |
| cc: linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net |
| Subject: Re: Non-blocking lock requests during the grace period |
| |
| |
>-------------------------------------------------------------------------------------------------------------------------|
> 2.-I also have this part enclosed in the if(resp->status ==
> NLM_LCK_DENIED_GRACE_PERIOD) as follows:
> if(resp->status == NLM_LCK_DENIED_GRACE_PERIOD) {
> blah blah...
> wait_on_grace:
> if ((proc == NLMPROC_LOCK) &&
> !argp->block)
> return -EAGAIN
> } else {
> ....
> }
> This with the intention to be very specific as to when we want
> the return -EAGAIN to be called.
The above means that you will still block on a F_GETLK query...
In any case, why would we want to return -EAGAIN in one case where
argp->block isn't set, and not in another? If there are cases where we
want to block and where we are not currently setting argp->block (the
only one I can think of might be NLMPROC_UNLOCK), then we should fix
the caller.
Cheers,
Trond
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Non-blocking lock requests during the grace period
2002-11-15 16:31 Juan Gomez
@ 2002-11-15 17:35 ` Trond Myklebust
0 siblings, 0 replies; 7+ messages in thread
From: Trond Myklebust @ 2002-11-15 17:35 UTC (permalink / raw)
To: Juan Gomez; +Cc: linux-kernel, nfs
> 2.-I also have this part enclosed in the if(resp->status ==
> NLM_LCK_DENIED_GRACE_PERIOD) as follows:
> if(resp->status == NLM_LCK_DENIED_GRACE_PERIOD) {
> blah blah...
> wait_on_grace:
> if ((proc == NLMPROC_LOCK) &&
> !argp->block)
> return -EAGAIN
> } else {
> ....
> }
> This with the intention to be very specific as to when we want
> the return -EAGAIN to be called.
The above means that you will still block on a F_GETLK query...
In any case, why would we want to return -EAGAIN in one case where
argp->block isn't set, and not in another? If there are cases where we
want to block and where we are not currently setting argp->block (the
only one I can think of might be NLMPROC_UNLOCK), then we should fix
the caller.
Cheers,
Trond
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Non-blocking lock requests during the grace period
@ 2002-11-15 16:31 Juan Gomez
2002-11-15 17:35 ` Trond Myklebust
0 siblings, 1 reply; 7+ messages in thread
From: Juan Gomez @ 2002-11-15 16:31 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-kernel, nfs
Trond,
I think this would fix it but the patch I have tested locally is a bit
different.
1).-Instead of
+wait_on_grace:
+ if (!argp->block)
+ return -EAGAIN;
I have
+wait_on_grace:
+ if ((proc == NLMPROC_LOCK) && !argp->block)
+ return -EAGAIN;
2.-I also have this part enclosed in the if(resp->status ==
NLM_LCK_DENIED_GRACE_PERIOD) as follows:
if(resp->status == NLM_LCK_DENIED_GRACE_PERIOD) {
blah blah...
wait_on_grace:
if ((proc == NLMPROC_LOCK) && !argp->block)
return -EAGAIN
} else {
....
}
This with the intention to be very specific as to when we want the return
-EAGAIN to be called.
Juan
|---------+---------------------------->
| | Trond Myklebust |
| | <trond.myklebust@|
| | fys.uio.no> |
| | |
| | 11/14/02 06:33 PM|
| | |
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------|
| |
| To: Juan Gomez/Almaden/IBM@IBMUS |
| cc: nfs@lists.sourceforge.net, linux-kernel@vger.kernel.org |
| Subject: Re: Non-blocking lock requests during the grace period |
| |
| |
>-------------------------------------------------------------------------------------------------------------------------|
>>>>> " " == Juan Gomez <juang@us.ibm.com> writes:
> I found out that the current Linux client of lockd blocks
> non-blocking lock requests while the server is in the grace
> period. I think this is incorrect behavior and I am wondering
> if the will exists out there to correct this and return
> "resource not available" to the process when a request is for a
> *non-blocking* lock while the server is in the grace period.
Would the following fix it?
Cheers,
Trond
--- linux-2.5.47/fs/lockd/clntproc.c.orig 2002-09-29
10:15:13.000000000 -0400
+++ linux-2.5.47/fs/lockd/clntproc.c 2002-11-14
21:32:26.000000000 -0500
@@ -256,10 +256,8 @@
msg.rpc_cred = NULL;
do {
- if (host->h_reclaiming && !argp->reclaim) {
-
interruptible_sleep_on(&host->h_gracewait);
- continue;
- }
+ if (host->h_reclaiming && !argp->reclaim)
+ goto wait_on_grace;
/* If we have no RPC client yet, create one. */
if ((clnt = nlm_bind_host(host)) == NULL)
@@ -296,6 +294,9 @@
dprintk("lockd: server returns status
%d\n", resp->status);
return 0; /* Okay, call
complete */
}
+wait_on_grace:
+ if (!argp->block)
+ return -EAGAIN;
/* Back off a little and try again */
interruptible_sleep_on_timeout(&host->h_gracewait,
15*HZ);
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-11-15 19:54 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-11-14 19:56 Non-blocking lock requests during the grace period Juan Gomez
2002-11-15 2:33 ` Trond Myklebust
2002-11-15 16:31 Juan Gomez
2002-11-15 17:35 ` Trond Myklebust
2002-11-15 18:48 Juan Gomez
2002-11-15 19:09 Juan Gomez
2002-11-15 20:01 ` Trond Myklebust
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®