From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
To: Jeff Layton <jlayton@kernel.org>
Cc: Calum Mackay <calum.mackay@oracle.com>,
linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] deleg: break infinite loop in DELEG8 test
Date: Tue, 15 Apr 2025 16:49:13 +0200 (CEST) [thread overview]
Message-ID: <865403842.27244482.1744728553871.JavaMail.zimbra@desy.de> (raw)
In-Reply-To: <5fb69477dfb9e372e70caf6d320170f6a20927af.camel@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]
In general, I want, but it's already happens on handling compound call:
```
for item in range(max_retries):
res = self.c.compound([seq_op] + ops, **kwargs)
res = self.update_seq_state(res, slot)
if res.status != NFS4ERR_DELAY or not handle_state_errors:
break
if res.resarray[0].sr_status != NFS4ERR_DELAY:
# As per errata ID 2006 for RFC 5661 section 15.1.1.3
# don't update the slot and sequence ID if the sequence
# operation itself receives NFS4ERR_DELAY
slot, seq_op = self._prepare_compound(saved_kwargs)
time.sleep(delay_time)
```
Tigran.
----- Original Message -----
> From: "Jeff Layton" <jlayton@kernel.org>
> To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>, "Calum Mackay" <calum.mackay@oracle.com>
> Cc: "linux-nfs" <linux-nfs@vger.kernel.org>
> Sent: Tuesday, 15 April, 2025 16:10:11
> Subject: Re: [PATCH] deleg: break infinite loop in DELEG8 test
> On Tue, 2025-04-15 at 13:48 +0200, Tigran Mkrtchyan wrote:
>> The test assumes that the server can return either OK or DELAY,
>> however, the 'break' condition checks only for OK.
>>
>> Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
>> ---
>> nfs4.1/server41tests/st_delegation.py | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/nfs4.1/server41tests/st_delegation.py
>> b/nfs4.1/server41tests/st_delegation.py
>> index ea4c073..60b0de6 100644
>> --- a/nfs4.1/server41tests/st_delegation.py
>> +++ b/nfs4.1/server41tests/st_delegation.py
>> @@ -181,8 +181,8 @@ def testDelegRevocation(t, env):
>> owner, how, claim)
>> while 1:
>> res = sess2.compound(env.home + [open_op])
>> - if res.status == NFS4_OK:
>> - break;
>> + if res.status == NFS4_OK or res.status == NFS4ERR_DELAY:
>> + break
>> check(res, [NFS4_OK, NFS4ERR_DELAY])
>> # just to keep sess1 renewed. This is a bit fragile, as we
>> # depend on the above compound waiting no longer than the
>
> Don't you want to loop on NFS4ERR_DELAY?
>
> It looks like this is supposed to loop (with no DELEGRETURN) until the
> open returns NFS4_OK. Presumably at that point the delegation will be
> revoked and you'll get the expected errors.
> --
> Jeff Layton <jlayton@kernel.org>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2826 bytes --]
prev parent reply other threads:[~2025-04-15 14:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 11:48 [PATCH] deleg: break infinite loop in DELEG8 test Tigran Mkrtchyan
2025-04-15 14:10 ` Jeff Layton
2025-04-15 14:49 ` Mkrtchyan, Tigran [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=865403842.27244482.1744728553871.JavaMail.zimbra@desy.de \
--to=tigran.mkrtchyan@desy.de \
--cc=calum.mackay@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox