All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: bjschuma@netapp.com
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2 1/2] NFSD: added FREE_STATEID operation
Date: Wed, 18 May 2011 18:56:09 -0400	[thread overview]
Message-ID: <20110518225609.GA26545@fieldses.org> (raw)
In-Reply-To: <1305575021-2841-2-git-send-email-bjschuma@netapp.com>

On Mon, May 16, 2011 at 03:43:40PM -0400, bjschuma@netapp.com wrote:
> +static __be32
> +nfsd4_free_file_stateid(stateid_t *stateid)
> +{
> +	struct nfs4_stateid *stp = search_for_stateid(stateid);
> +	if (!stp)
> +		return nfserr_bad_stateid;
> +	if (stateid->si_generation != 0) {
> +		if (stateid->si_generation < stp->st_stateid.si_generation)
> +			return nfserr_old_stateid;
> +		if (stateid->si_generation > stp->st_stateid.si_generation)
> +			return nfserr_bad_stateid;
> +	}
> +
> +	if (check_for_locks(stp->st_file, stp->st_stateowner))
> +		return nfserr_locks_held;

I think this catches a lock stateid, but not an open stateid that has
associated lock stateid's that in turn hold locks.

Hm, also:

	"The FREE_STATEID operation is used to free a stateid that no
	longer has any associated locks (including opens, byte-range
	locks, delegations, and layouts)"

So an open stateid also shouldn't be freeable as long as there are opens
associated with it.

Also I guess a client shouldn't be permitted to free a delegation that
it still holds.  That means we'll always just return nfserr_locks for
delegation stateid's.  I assume free_stateid is only useful in this case
for the case where a server forcibly revokes part of the client's state
and leaves some "stub" stateid's around in place of the revoked ones.

--b.

  reply	other threads:[~2011-05-18 22:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-16 19:43 [PATCH v2 0/2] NFSD: add FREE_STATEID and TEST_STATEID operations bjschuma
2011-05-16 19:43 ` [PATCH v2 1/2] NFSD: added FREE_STATEID operation bjschuma
2011-05-18 22:56   ` J. Bruce Fields [this message]
2011-05-19  1:12     ` J. Bruce Fields
2011-05-19 15:33     ` Bryan Schumaker
2011-05-19 16:30       ` J. Bruce Fields
2011-05-19 16:35         ` Bryan Schumaker
2011-05-20 18:29           ` Bryan Schumaker
2011-05-16 19:43 ` [PATCH v2 2/2] NFSD: Added TEST_STATEID opreation bjschuma
2011-05-18 23:57   ` J. Bruce Fields
2011-05-19 15:21     ` Bryan Schumaker

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=20110518225609.GA26545@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=bjschuma@netapp.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.