Linux NFS development
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
Cc: andros@netapp.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 3/3] NFSD deferral processing
Date: Mon, 20 Oct 2008 13:58:44 -0400	[thread overview]
Message-ID: <20081020175844.GA23927@fieldses.org> (raw)
In-Reply-To: <RTPCLUEXC1-PRDNY30k000001cc-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>

On Fri, Oct 17, 2008 at 04:46:50PM -0400, Talpey, Thomas wrote:
> At 05:00 PM 10/15/2008, andros@netapp.com wrote:
> >From: Andy Adamson <andros@netapp.com>
> >
> >Use a slab cache for nfsd4_compound_state allocation
> >
> >Save the struct nfsd4_compound_state and set the save_state callback for
> >each request for potential deferral handling.
> >
> >If an NFSv4 operation causes a deferral, the save_state callback is called
> >by svc_defer which saves the defer_data with the deferral, and sets the
> >restore_state deferral callback.
> >
> >fh_put is called so that the deferral is not referencing the file handles,
> >allowing umount of the file system.
> 
> Can you explain the safety of this? If the COMPOUND starts off with an
> operation that uses them, what's the implication of one going stale
> partway through?

I suppose it means the compound could get an unexpected STALE error
partway through.

> Is fh_verify() when the deferral continues enough to
> ensure the fh is protected until the end of the op?

I'm not sure what you mean.

> There's a comment at the top of fh_verify() that it is "only called at
> the start of an nfsproc call", with some assumptions, for instance.

That comment could be improved.

--b.

commit 438d5d3ec385e6385856929719322d569de3e148
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date:   Mon Oct 20 13:01:59 2008 -0400

    nfsd: update fh_verify description

diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
index cd25d91..8cabcfa 100644
--- a/fs/nfsd/nfsfh.c
+++ b/fs/nfsd/nfsfh.c
@@ -253,14 +253,32 @@ out:
 	return error;
 }
 
-/*
- * Perform sanity checks on the dentry in a client's file handle.
+/**
+ * fh_verify - filehandle lookup and access checking
+ * @rqstp: pointer to current rpc request
+ * @fhp: filehandle to be verified
+ * @type: expected type of object pointed to by filehandle
+ * @access: type of access needed to object
+ *
+ * Look up a dentry from the on-the-wire filehandle, check the client's
+ * access to the export, and set the current task's credentials.
+ *
+ * Regardless of success or failure of fh_verify(), fh_put() should be
+ * called on @fhp when the caller is finished with the filehandle.
+ *
+ * fh_verify() may be called multiple times on a given filehandle, for
+ * example, when processing an NFSv4 compound.  The first call will look
+ * up a dentry using the on-the-wire filehandle.  Subsequent calls will
+ * skip the lookup and just perform the other checks and possibly change
+ * the current task's credentials.
  *
- * Note that the file handle dentry may need to be freed even after
- * an error return.
+ * @type specifies the type of object expected using one of the S_IF*
+ * constants defined in include/linux/stat.h.  The caller may use zero
+ * to indicate that it doesn't care, or a negative integer to indicate
+ * that it expects something not of the given type.
  *
- * This is only called at the start of an nfsproc call, so fhp points to
- * a svc_fh which is all 0 except for the over-the-wire file handle.
+ * @access is formed from the NFSD_MAY_* constants defined in
+ * include/linux/nfsd/nfsd.h.
  */
 __be32
 fh_verify(struct svc_rqst *rqstp, struct svc_fh *fhp, int type, int access)

  parent reply	other threads:[~2008-10-20 17:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-15 21:00 [PATCH 0/3] NFSD EOS deferral andros
2008-10-15 21:00 ` [PATCH 1/3] SUNRPC add deferral processing callbacks andros
2008-10-15 21:00   ` [PATCH 2/3] NFSD save, restore, and release deferred result pages andros
2008-10-15 21:00     ` [PATCH 3/3] NFSD deferral processing andros
2008-10-17 20:46       ` Talpey, Thomas
     [not found]         ` <RTPCLUEXC1-PRDNY30k000001cc-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 17:58           ` J. Bruce Fields [this message]
2008-10-17 17:48   ` [PATCH 1/3] SUNRPC add deferral processing callbacks J. Bruce Fields
2008-10-17 18:42     ` Andy Adamson
2008-10-17 20:35   ` Talpey, Thomas
     [not found]     ` <RTPCLUEXC1-PRDf3sll000001cb-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 18:42       ` J. Bruce Fields
2008-10-17 17:44 ` [PATCH 0/3] NFSD EOS deferral J. Bruce Fields
2008-10-17 18:44   ` Andy Adamson
2008-10-17 18:59   ` Marc Eshel
     [not found]     ` <OF9E4C4BA6.37418EC7-ON882574E5.0067FB2B-882574E5.0068487F@ us.ibm.com>
2008-10-17 20:26       ` Talpey, Thomas
     [not found]         ` <RTPCLUEXC1-PRDidcDj000001ca-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-17 20:36           ` J. Bruce Fields
2008-10-17 20:51             ` Talpey, Thomas
     [not found]               ` <RTPCLUEXC1-PRDarcR4000001cd-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 18:06                 ` J. Bruce Fields
  -- strict thread matches above, loose matches on Subject: below --
2008-10-22 18:12 andros
2008-10-22 18:12 ` [PATCH 1/3] SUNRPC add deferral processing callbacks andros
2008-10-22 18:12   ` [PATCH 2/3] NFSD save, restore, and release deferred result pages andros
2008-10-22 18:12     ` [PATCH 3/3] NFSD deferral processing andros

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=20081020175844.GA23927@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Thomas.Talpey@netapp.com \
    --cc=andros@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox