NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)

NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)

[Dave Gilbert]

Hi,
  On the server:

bash$ ls -l
total 21
drwxrwxrwx  11 root     root         2048 Jul 23 02:32 arm
lrwxrwxrwx   1 root     root           14 Aug 22  1999 dg ->
/home/gilbertd
drwxr-xr-x   6 root     root         1024 Mar 21  1999 ftp
drwx------   5 g3oag    g3oag        1024 Oct  3  1999 g3oag
drwxr-xr-x 164 gilbertd gilbertd    12288 Dec 29 19:42 gilbertd
drwxr-xr-x   5 root     root         1024 Sep 21  1999 httpd
drwxr-xr-x   2 root     root         1024 Mar  8  2017 lost+found
drwx------   2 rmk      rmk          1024 Apr 11  1999 rmk
drwx------   5 rt       rt           1024 Sep 10 14:49 rt
drwxr-xr-x   2 root     nobody       1024 Apr 16  1999 samba

on the client:

[root@sol home]# ls -l
ls: gilbertd: No such file or directory
total 9
drwxrwxrwx   11 root     root         2048 Jul 23 02:32 arm
lrwxrwxrwx    1 root     root           14 Aug 22  1999 dg -> /home/gilbertd
drwxr-xr-x    6 root     root         1024 Mar 21  1999 ftp
drwx------    5 1000     1000         1024 Oct  3 1999 g3oag
drwxr-xr-x    5 root     root         1024 Sep 21  1999 httpd
drwxr-xr-x    2 root     root         1024 Mar  8  2017 lost+found
drwx------    2 9032     9032         1024 Apr 11  1999 rmk
drwx------    5 9033     9033         1024 Sep 10 14:49 rt
drwxr-xr-x    2 root     nobody       1024 Apr 16  1999 samba                  

-------------------------

So where did the gilbertd directory go ?

The Server is Linux/Alpha 2.4.0-test13pre4ac2
The clients are Linux/x86 2.0.36
            and Linux/SPARC 2.2.14

What gives ?

Dave
-- 
 ---------------- Have a happy GNU millennium! ----------------------   
/ Dr. David Alan Gilbert      | Running GNU/Linux on       |  Happy  \ 
\   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
 \ ___________________________|___ http://www.treblig.org  |________/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)

[Neil Brown]

On Friday December 29, gilbertd@treblig.org wrote:
> Hi,
>   On the server:
> 
> bash$ ls -l
> total 21
> drwxrwxrwx  11 root     root         2048 Jul 23 02:32 arm
> lrwxrwxrwx   1 root     root           14 Aug 22  1999 dg ->
> /home/gilbertd
> drwxr-xr-x   6 root     root         1024 Mar 21  1999 ftp
> drwx------   5 g3oag    g3oag        1024 Oct  3  1999 g3oag
> drwxr-xr-x 164 gilbertd gilbertd    12288 Dec 29 19:42 gilbertd
....
> 
> on the client:
> 
> [root@sol home]# ls -l
> ls: gilbertd: No such file or directory
> total 9
> drwxrwxrwx   11 root     root         2048 Jul 23 02:32 arm
> lrwxrwxrwx    1 root     root           14 Aug 22  1999 dg -> /home/gilbertd
> drwxr-xr-x    6 root     root         1024 Mar 21  1999 ftp
> drwx------    5 1000     1000         1024 Oct  3 1999 g3oag
....
> -------------------------
> 
> So where did the gilbertd directory go ?

Is there any chance that /home/gilbertd is a mount point?
Can you show us your /etc/exports, just incase there is something
significant there?
Can you get a tcpdump (-s 1024) of the network traffic while this is
happening?

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)

[Dave Gilbert]

On Sat, 30 Dec 2000, Neil Brown wrote:

> > So where did the gilbertd directory go ?
> 
> Is there any chance that /home/gilbertd is a mount point?

Nope; from the server:

[root@tardis gcc]# mount
/dev/hdc6 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc3 on /discs/c3 type ext2 (ro)
/dev/hdc4 on /discs/c4 type ext2 (rw)
/dev/hdc7 on /discs/c7 type ext2 (rw)
/dev/hdc8 on /discs/c8 type ext2 (rw)

(/home is actually /discs/c4/home).

/etc/exports is:

/discs/c4 sol(rw,no_root_squash,insecure) gort klaatu 
     oaktree(rw,no_root_squash,insecure)  
/discs/c3 sol(rw,no_root_squash,insecure) gort klaatu
     oaktree(rw,no_root_squash,insecure)  
/mnt/dvd sol(rw,no_root_squash,insecure)

Server is tardis, client is sol.


> Can you get a tcpdump (-s 1024) of the network traffic while this is
> happening?

Yep; to avoid posting to the list I've put it at:
http://www.treblig.org/nfs_bug_netlog

its 14K and is the output of:

 /usr/sbin/tcpdump -vv -x -s 1024 host sol and tardis > /tmp/netlog 2>&1

Thanks,

Dave

-- 
 ---------------- Have a happy GNU millennium! ----------------------   
/ Dr. David Alan Gilbert      | Running GNU/Linux on       |  Happy  \ 
\   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
 \ ___________________________|___ http://www.treblig.org  |________/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)

[Neil Brown]

On Friday December 29, gilbertd@treblig.org wrote:
> On Sat, 30 Dec 2000, Neil Brown wrote:
> 
> > > So where did the gilbertd directory go ?

It suffered the curse of the 8-character file name....

> > 
> > Can you get a tcpdump (-s 1024) of the network traffic while this is
> > happening?
> 
> Yep; to avoid posting to the list I've put it at:
> http://www.treblig.org/nfs_bug_netlog
> 
> its 14K and is the output of:
> 
>  /usr/sbin/tcpdump -vv -x -s 1024 host sol and tardis > /tmp/netlog 2>&1
> 

Well......
The trace contains a number of lookup requests.
For example, there is a lookup of "samba" which contains the
encoded file name:

0000 0005 7361 6d62 6100
          s a  m b  a

The "0000 0005" is the file name length.
The corresponding part of the lookup request for gilbertd looks like:

6572 7464 6572 7464 0072 7464
e r  t d  e r  t d    r  t d

Note there is no leading length count.  This is not actually
surprising when you look at  
  net/sunrpc/xdr.c:xdr_decode_string

If the length of the string is a multiple of 4, there is no spare
following byte to be a nul terminator for the string, so the whole
string is copied back 4 bytes using memmove.  This change takes place
in the actual packet in the network buffer which is why tcpdump sees
it's effect.  But you would expect to see:

6769 6c62 6572 7464 0072 7464
g i  l b  e r  t d    r  t d

but you don't.  Why?

My only guess is that memmove is doing the wrong thing, and moving
from the end of the string instead of from the start.
What architecture are you doing this on? Your signature lists 4!:-)

Could you
  gdb vmlinux
  disassemble xdr_decode_string
  disassemble memmove

and see if the code looks right?

You might like to try:

 1/ move gilbertd to gilbertdd and see if you can then access it over
    nfs.
 2/ create a file called "ertdertd" and see if you get that when you
    try to access gilbertd

> Thanks,
> 
> Dave
> 
> -- 
>  ---------------- Have a happy GNU millennium! ----------------------   
> / Dr. David Alan Gilbert      | Running GNU/Linux on       |  Happy  \ 
> \   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
>  \ ___________________________|___ http://www.treblig.org  |________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)

[Dave Gilbert]

On Sat, 30 Dec 2000, Neil Brown wrote:

> On Friday December 29, gilbertd@treblig.org wrote:
> > On Sat, 30 Dec 2000, Neil Brown wrote:
> > 
> > > > So where did the gilbertd directory go ?
> 
> It suffered the curse of the 8-character file name....

Ah well spotted! It also happens to 12 byte names.

> Could you
>   gdb vmlinux
>   disassemble xdr_decode_string
>   disassemble memmove

A job for tomorrow.

> and see if the code looks right?
> 
> You might like to try:
> 
>  1/ move gilbertd to gilbertdd and see if you can then access it over
>     nfs.

Yep - it starts working.

>  2/ create a file called "ertdertd" and see if you get that when you
>     try to access gilbertd

Hehe yes; accessing gilbertd gives you the contents or ertdertd.


The server architecture is Alpha. (Client Sparc and x86).

Dave

-- 
 ---------------- Have a happy GNU millennium! ----------------------   
/ Dr. David Alan Gilbert      | Running GNU/Linux on       |  Happy  \ 
\   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
 \ ___________________________|___ http://www.treblig.org  |________/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

memmove broken on alpha - was Re: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)

[Neil Brown]

[ extra detail included because I have added linux-alpha and lins to
the cc list] 

It appears that memmove is broken on the alpha architecture.

memmove is used by net/sunrpc/xdr.c:xdr_decode_string
to move a string 4 bytes down in memory.
memmove(X-4, X, 8) should change
    
 X:  00 00 00 08  67 69 6c 62 65 72 74 64
to
 X:  67 69 6c 62  65 72 74 64 65 72 74 64

Instead it changes it to

 X:  65 72 74 64  65 72 74 64 65 72 74 64

This is my first time in alpha assembler, but it looks fairly readable
and the comments help....

Working from 
  arch/alpha/lib/memmove.S

As the two regions overlap, it doesn't fall back on memcpy,
As the two regions are not co-aligned so it jumps to $misaligned.

Now the code in $misaligned, like all the code in memmove.S seems to
move a block of memory starting at the top, and moving downwards.
But in this example, we need to start at the bottom and move upwards.

Currently the code falls back on memcpy :

 if (dest+n <= src || dest >= src + n)

However if should also fall back on memcpy:
 
 if (dest <= src)

So the test should be:

  if (dest <= src || dest >= src + n)

which I think translates to the following patch:

--- arch/alpha/lib/memmove.S	2000/12/30 01:59:28	1.1
+++ arch/alpha/lib/memmove.S	2000/12/30 01:59:49
@@ -17,7 +17,7 @@
 memmove:
 	addq $16,$18,$4
 	addq $17,$18,$5
-	cmpule $4,$17,$1		/*  dest + n <= src  */
+	cmpule $16,$17,$1		/*  dest <= src  */
 	cmpule $5,$16,$2		/*  dest >= src + n  */
 
 	bis $1,$2,$1


NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: memmove broken on alpha - was Re: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)

[Matti Aarnio]

On Sat, Dec 30, 2000 at 01:02:44PM +1100, Neil Brown wrote:
> [ extra detail included because I have added linux-alpha and lins to
> the cc list] 
> 
> It appears that memmove is broken on the alpha architecture.

  Indeed it is, and your observation/patch isn't the first one:

Date:   Thu, 21 Dec 2000 18:40:46 +0300
From:   Ivan Kokshaysky <ink@jurassic.park.msu.ru>
To:     Alexander Zarochentcev <zam@namesys.com>
Cc:     Richard Henderson <rth@twiddle.net>, linux-kernel@vger.kernel.org
Subject: Re: memmove() in 2.4.0-test12, alpha platform

  As the patch by mr. Kokshaysky is quite different doing more work
  (and not only label name changes), I would prefer Richard Henderson
  to act as an umpire to tell if your patch is sufficient, or if that
  big thing by Kokshaysky is needed.

  Full email (and patch) by Kokshaysky is at:
    http://www.uwsg.indiana.edu/hypermail/linux/kernel/0012.2/0712.html

> memmove is used by net/sunrpc/xdr.c:xdr_decode_string
> to move a string 4 bytes down in memory.
> memmove(X-4, X, 8) should change
>     
>  X:  00 00 00 08  67 69 6c 62 65 72 74 64
> to
>  X:  67 69 6c 62  65 72 74 64 65 72 74 64
> 
> Instead it changes it to
> 
>  X:  65 72 74 64  65 72 74 64 65 72 74 64
> 
> This is my first time in alpha assembler, but it looks fairly readable
> and the comments help....
> 
> Working from 
>   arch/alpha/lib/memmove.S
.... 
> which I think translates to the following patch:
> 
> --- arch/alpha/lib/memmove.S	2000/12/30 01:59:28	1.1
> +++ arch/alpha/lib/memmove.S	2000/12/30 01:59:49
> @@ -17,7 +17,7 @@
>  memmove:
>  	addq $16,$18,$4
>  	addq $17,$18,$5
> -	cmpule $4,$17,$1		/*  dest + n <= src  */
> +	cmpule $16,$17,$1		/*  dest <= src  */
>  	cmpule $5,$16,$2		/*  dest >= src + n  */
>  
>  	bis $1,$2,$1
> 
> NeilBrown

/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: memmove broken on alpha - was Re: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)

[Richard Henderson]

On Sat, Dec 30, 2000 at 05:18:25AM +0200, Matti Aarnio wrote:
>   As the patch by mr. Kokshaysky is quite different doing more work
>   (and not only label name changes), I would prefer Richard Henderson
>   to act as an umpire to tell if your patch is sufficient, or if that
>   big thing by Kokshaysky is needed.

Ivan's code is needed.  You can't fall back to memcpy when
there is overlap.  The ev6 version _will_ corrupt data if
you do.


r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/