From: Ralf Baechle <ralf@linux-mips.org>
To: Kaz Kylheku <kaz@zeugmasystems.com>
Cc: linux-mips@linux-mips.org
Subject: Re: "exportfs -a" -> stale NFS filehandle
Date: Thu, 15 Nov 2007 00:48:21 +0000 [thread overview]
Message-ID: <20071115004821.GA32332@linux-mips.org> (raw)
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C547AF5B@exchange.ZeugmaSystems.local>
On Wed, Nov 14, 2007 at 03:19:43PM -0800, Kaz Kylheku wrote:
> I have an NFS problem on a multi-node MIPS system running kernel
> 2.6.17.7. NFS utils is 1.1.0. ABI is n32.
>
> One node (call it primary) exports a directory which is mounted by
> several others (the secondaries) as their root filesystem.
>
> If I run "exportfs -a" on the primary, the secondary nodes lose their
> root filesystem and so everything stops working.
>
> I turned on all NFS debugging on a secondary node (sysctl -w
> sunrpc.nfs_debug=65535). What is happening is that NFS operations
> suddenly start returning error -151 (stale NFS filehandle).
>
> I don't see exportfs causing this problem on other systems. If I run
> "exportfs -a" on a big NFS server (Fedora Core 5, i686) which has lots
> of diskless clients, nothing bad happens. (And some of those diskless
> clients are MIPS systems just like this one!)
>
> I'm pretty sure that exportfs -a shouldn't screw up the existing mounted
> clients.
>
> Could there be some ABI problem that corrupts up the effect of the
> re-exporting operation on the server?
Can you test below patch?
Ralf
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
diff --git a/arch/mips/kernel/scall64-n32.S b/arch/mips/kernel/scall64-n32.S
index 118be24..01993ec 100644
--- a/arch/mips/kernel/scall64-n32.S
+++ b/arch/mips/kernel/scall64-n32.S
@@ -293,7 +293,7 @@ EXPORT(sysn32_call_table)
PTR sys_ni_syscall /* 6170, was get_kernel_syms */
PTR sys_ni_syscall /* was query_module */
PTR sys_quotactl
- PTR sys_nfsservctl
+ PTR compat_sys_nfsservctl
PTR sys_ni_syscall /* res. for getpmsg */
PTR sys_ni_syscall /* 6175 for putpmsg */
PTR sys_ni_syscall /* res. for afs_syscall */
next prev parent reply other threads:[~2007-11-15 0:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-14 23:19 "exportfs -a" -> stale NFS filehandle Kaz Kylheku
2007-11-14 23:19 ` Kaz Kylheku
2007-11-15 0:48 ` Ralf Baechle [this message]
2007-11-15 18:38 ` Kaz Kylheku
2007-11-15 18:38 ` Kaz Kylheku
2007-11-15 19:26 ` Kaz Kylheku
2007-11-15 19:26 ` Kaz Kylheku
2007-11-15 19:45 ` Ralf Baechle
2007-11-15 20:15 ` Kaz Kylheku
2007-11-15 20:15 ` Kaz Kylheku
2007-11-15 23:02 ` Ralf Baechle
2007-11-19 22:26 ` Kaz Kylheku
2007-11-19 22:26 ` Kaz Kylheku
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=20071115004821.GA32332@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=kaz@zeugmasystems.com \
--cc=linux-mips@linux-mips.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.