All of lore.kernel.org
 help / color / mirror / Atom feed
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 */

  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.