From: "J. Bruce Fields" <bfields@fieldses.org>
To: linux-nfs@vger.kernel.org
Subject: Re: nfsd dropping requests after lazy umount
Date: Mon, 1 Jul 2013 16:26:49 -0400 [thread overview]
Message-ID: <20130701202649.GE19945@fieldses.org> (raw)
In-Reply-To: <20130625191008.GA20277@us.ibm.com>
On Tue, Jun 25, 2013 at 02:10:08PM -0500, Malahal Naineni wrote:
> Hi All,
>
> I have found an issue with lazy/forced unmounts with nfsd. Let us say
> /nfs is a mount point, and we are exporting /nfs/exp directory.
>
> After mounting from a client, this export will have a cache entry
> "svc_export" in the kernel. The exports pathname
> d_path(svc_export->ex_path) correctly resolves to "/nfs/exp"
>
> After the /nfs is lazy unmounted, the d_path(svc_export->ex_path)
> resolves to "/exp" only.
>
> Now, if the cache entry needs revalidation, you will see "/exp" in the
> nfsd.export/channel file that never gets cleared as that cache entry
> will be in a forever CACHE_PENDING state. We will also see
> svc_export_parse() failing with -2 err as such a pathname doesn't exist
> in the system any more.
So, mountd is trying to do a downcall for "/exp" but it's failing
because the kern_path("/exp",.,.) fails?
> I noticed that svc_export has two fields: ex_path and ex_pathname.
Not any more--see 2f1ddda1749a223d1a05e16dc6ea28632b9ec570 "NFSD: Remove
the ex_pathname field from struct svc_export".
--b.
> Is
> it possible to make a string comparison of d_path(ex_path) and
> ex_pathname? If so, we should be able to fail the upcall without making
> the upcall if those two don't match.
>
> Regards, Malahal.
>
prev parent reply other threads:[~2013-07-01 20:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-25 19:10 nfsd dropping requests after lazy umount Malahal Naineni
2013-07-01 20:26 ` J. Bruce Fields [this message]
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=20130701202649.GE19945@fieldses.org \
--to=bfields@fieldses.org \
--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.