Linux NFS development
 help / color / mirror / Atom feed
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 --]

      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