Linux NFS development
 help / color / mirror / Atom feed
From: Andrew W Elble <aweits@rit.edu>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH RFC v3] nfs: nfs_do_return_delegation() needs to send FREE_STATEID
Date: Thu, 05 Nov 2015 10:19:27 -0500	[thread overview]
Message-ID: <m2twp0v5hc.fsf@discipline.rit.edu> (raw)
In-Reply-To: <CAHQdGtQmYV9Aq+=CivbmPTjHMZVhd8BznpMsmXXD=cZwzOO0Uw@mail.gmail.com> (Trond Myklebust's message of "Thu, 5 Nov 2015 09:27:06 -0500")


> If the server is revoking a delegation, then presumably it will also
> set one or more of the SEQ4_STATUS_EXPIRED_SOME_STATE_REVOKED,
> SEQ4_STATUS_ADMIN_STATE_REVOKED, SEQ4_STATUS_RECALLABLE_STATE_REVOKED,
> which should start up a state manager thread to do the
> test_stateid/free_stateid dance.
>
> So instead of adding the free stateid call above, why can't we just
> punt the freeing of the delegation to the state manager?

I inferred (perhaps incorrectly) that nfs_do_return_delegation() was a
place delegations went to and didn't come back from.

I managed to convince myself that since all callers of
nfs_do_return_delegation() detach the delegation, the state manager
wouldn't be able to perform that function without reattaching the
delegation - and that doesn't look quite so safe (and/or possible)
in all of those call paths?

Thanks,

Andy

-- 
Andrew W. Elble
aweits@discipline.rit.edu
Infrastructure Engineer, Communications Technical Lead
Rochester Institute of Technology
PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912

  reply	other threads:[~2015-11-05 15:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-05  0:43 [PATCH RFC v3] nfs: nfs_do_return_delegation() needs to send FREE_STATEID Andrew Elble
2015-11-05 14:27 ` Trond Myklebust
2015-11-05 15:19   ` Andrew W Elble [this message]
2015-11-05 16:31     ` Trond Myklebust
2015-11-09 18:03   ` J. Bruce Fields
2015-11-09 18:32     ` Trond Myklebust

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=m2twp0v5hc.fsf@discipline.rit.edu \
    --to=aweits@rit.edu \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@primarydata.com \
    /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