All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Bryan Schumaker <bjschuma@netapp.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2 1/2] NFSD: added FREE_STATEID operation
Date: Thu, 19 May 2011 12:30:51 -0400	[thread overview]
Message-ID: <20110519163051.GB976@fieldses.org> (raw)
In-Reply-To: <4DD53864.1010401@netapp.com>

On Thu, May 19, 2011 at 11:33:56AM -0400, Bryan Schumaker wrote:
> On 05/18/2011 06:56 PM, J. Bruce Fields wrote:
> > 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.
> 
> So having an open stateid doesn't necessarily mean that the file is open?

Looking back at it.... Sorry, you're right, open stateid's are destroyed
on close, so like delegation stateid's they should just never be
freeable.

> and having a lock stateid doesn't mean that the file is locked?

Here we don't know whether the file's locked or not, so we do have to
check.

> I'll look at making a "check_for_opens()" function to help with this check.

So actually I think it's really simple: always fail opens and
delegations, but check for locks.  (Except I'm not sure if
check_for_locks() does the right things, as it operates on a stateowner
not a stateid--I'm forgetting how those work....  If there's a unique
lock stateid per (stateowner,file) pair then check_for_locks() should do
what you want.)

--b.

> 
> > 
> > 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
> 
> Sounds simple enough.
> 
> > 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-19 16:30 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
2011-05-19  1:12     ` J. Bruce Fields
2011-05-19 15:33     ` Bryan Schumaker
2011-05-19 16:30       ` J. Bruce Fields [this message]
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=20110519163051.GB976@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.