From: "J. Bruce Fields" <bfields@fieldses.org>
To: Kinglong Mee <kinglongmee@gmail.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH] Do not enter setup_callback_client when finding backchannel failed
Date: Wed, 4 Dec 2013 12:10:52 -0500 [thread overview]
Message-ID: <20131204171052.GE14646@fieldses.org> (raw)
In-Reply-To: <529D4617.6080505@gmail.com>
On Tue, Dec 03, 2013 at 10:46:47AM +0800, Kinglong Mee wrote:
> On 12/02/2013 10:59 PM, J. Bruce Fields wrote:
> > On Wed, Nov 27, 2013 at 06:29:22PM +0800, Kinglong Mee wrote:
> >> If finding backchannel failed, nfsd should not enter setup_callback_client.
> >>
> >> Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
> >> ---
> >> fs/nfsd/nfs4callback.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/fs/nfsd/nfs4callback.c b/fs/nfsd/nfs4callback.c
> >> index 7f05cd1..755d6d6 100644
> >> --- a/fs/nfsd/nfs4callback.c
> >> +++ b/fs/nfsd/nfs4callback.c
> >> @@ -664,7 +664,7 @@ static int setup_callback_client(struct nfs4_client *clp, struct nfs4_cb_conn *c
> >> args.authflavor = clp->cl_cred.cr_flavor;
> >> clp->cl_cb_ident = conn->cb_ident;
> >> } else {
> >> - if (!conn->cb_xprt)
> >> + if (!conn->cb_xprt || !ses)
> >
> > It looks to me like ses should be set whenenver conn is. Do you have
> > reason to believe the contrary?
>
> No. It just a double check as conn->cb_xprt.
> I will drop it in v2 of this path.
>
> >
> >> return -EINVAL;
> >> clp->cl_cb_conn.cb_xprt = conn->cb_xprt;
> >> clp->cl_cb_session = ses;
> >> @@ -982,7 +982,7 @@ static void nfsd4_process_cb_update(struct nfsd4_callback *cb)
> >> }
> >> spin_unlock(&clp->cl_lock);
> >>
> >> - err = setup_callback_client(clp, &conn, ses);
> >> + err = c ? setup_callback_client(clp, &conn, ses) : -ENOENT;
> >
> > But, whoops, yes, this looks like a good fix. (Have you hit this
> > failure in practice?)
>
> Yes. When destroying the last session from client, nfsd4_probe_callback_sync
> will be called in function nfsd4_destroy_session.
>
> As that, callback client will be update in function nfsd4_process_cb_update,
> so __nfsd4_find_backchannel always failed with returning NULL.
On second thoughts, why is that actually a problem?
setup_callback_client() will fail and you'll get an unnecessary printk
from nfsd4_mark_cb_down, I guess. Is that the only problem?
--b.
> (Ps: Maybe needs
> another patch to avoid updating callback connect when destroying the last session ?)
>
> For debugging, add message when finding backchannel failed.
> Just testing mount/umount at client, the debug message will be print every umount.
>
> diff --git a/fs/nfsd/nfs4callback.c b/fs/nfsd/nfs4callback.c
> index 7f05cd1..1be4c61 100644
> --- a/fs/nfsd/nfs4callback.c
> +++ b/fs/nfsd/nfs4callback.c
> @@ -979,6 +979,8 @@ static void nfsd4_process_cb_update(struct nfsd4_callback *cb)
> svc_xprt_get(c->cn_xprt);
> conn.cb_xprt = c->cn_xprt;
> ses = c->cn_session;
> + } else {
> + printk("%s: found connet failed.\n", __func__);
> }
> spin_unlock(&clp->cl_lock);
>
> > But I think we should probably adopt the sort of
> > control flow that's more idiomatic in the kernel:
> >
> > c = __nfsd4_find_backchannel(clp)
> > if (!c)
> > goto out_unlock;
> > ...
> > spin_unlock(&clp->cl_lock);
> > err = setup_callback_client(clp, &conn, ses);
> > if (err)
> > goto out_err;
> >
>
> OK, it is really better.
>
> thanks,
> Kinglong Mee
>
> > etc.
> >
> > --b.
> >
> >> if (err) {
> >> nfsd4_mark_cb_down(clp, err);
> >> return;
> >> --
> >> 1.8.4.2
> >
>
next prev parent reply other threads:[~2013-12-04 17:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-27 10:29 [PATCH] Do not enter setup_callback_client when finding backchannel failed Kinglong Mee
2013-12-02 14:59 ` J. Bruce Fields
2013-12-03 2:46 ` Kinglong Mee
2013-12-04 17:10 ` J. Bruce Fields [this message]
2013-12-05 2:09 ` Kinglong Mee
2013-12-06 18:00 ` J. Bruce Fields
2013-12-09 1:17 ` Kinglong Mee
2013-12-03 3:40 ` [PATCH v2] " Kinglong Mee
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=20131204171052.GE14646@fieldses.org \
--to=bfields@fieldses.org \
--cc=kinglongmee@gmail.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.