From: Neil Brown <neilb@suse.de>
To: Steve Dickson <SteveD@redhat.com>
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH] bug in old-cache handling in mountd.
Date: Fri, 29 May 2009 11:49:19 +1000 [thread overview]
Message-ID: <18975.16159.264056.854413@notabene.brown> (raw)
Hi,
there is a bug in the old-cache behaviour of mountd.
Hopefully no-one is using this but you never know....
The bug was reported to redhat
https://bugzilla.redhat.com/show_bug.cgi?id=164186
It was fixed incorrectly and never (that I recall) reported
upstream. :-(
A SLES customer thinks they have hit the same problem, which is why
I'm looking at it. (They shouldn't really hit it because that
version of sles uses 'new_cache' but maybe nfsdfs was disabled
somehow - don't know yet).
Anyway, when mountd gets a mount request, it tells the kernel about it
and remembers that it told the kernel so it doesn't have to tell the
kernel again.
It is possible that "exportfs -r" will tell the kernel to forget that
information if the client has since unmounted.
So mountd really needs to tell the kernel even if it thinks the
kernel should already know.
The following patch does this if the kernel refuses to provide a
valid filehandle.
Does RHEL3 use old-cache or new-cache ??
Thanks,
NeilBrown
From: NeilBrown <neilb@suse.de>
Subject: retry export if getfh fails.
mountd tries to avoid telling the kernel to export something
when the kernel already knows to do that.
However sometimes (exportfs -r) the kernel can be told
to forget something without mountd realising.
So if mountd finds that it cannot get a valid filehandle,
make sure it really has been exported to the kernel.
This only applies if the nfsd filesystem is not mounted.
Signed-off-by: NeilBrown <neilb@suse.de>
diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
index 25d292b..b59f939 100644
--- a/utils/mountd/mountd.c
+++ b/utils/mountd/mountd.c
@@ -467,8 +467,12 @@ get_rootfh(struct svc_req *rqstp, dirpath *path, nfs_export **expret,
return NULL;
}
} else {
- if (exp->m_exported<1)
+ int did_export = 0;
+ retry:
+ if (exp->m_exported<1) {
export_export(exp);
+ did_export = 1;
+ }
if (!exp->m_xtabent)
xtab_append(exp);
@@ -482,6 +486,11 @@ get_rootfh(struct svc_req *rqstp, dirpath *path, nfs_export **expret,
fh = getfh_old ((struct sockaddr *) sin,
stb.st_dev, stb.st_ino);
}
+ if (fh == NULL && !did_export) {
+ exp->m_exported = 0;
+ goto retry;
+ }
+
if (fh == NULL) {
xlog(L_WARNING, "getfh failed: %s", strerror(errno));
*error = NFSERR_ACCES;
next reply other threads:[~2009-05-29 1:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-29 1:49 Neil Brown [this message]
[not found] ` <18975.16159.264056.854413-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2009-06-03 19:45 ` [PATCH] bug in old-cache handling in mountd Steve Dickson
2009-06-03 22:45 ` Neil Brown
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=18975.16159.264056.854413@notabene.brown \
--to=neilb@suse.de \
--cc=SteveD@redhat.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