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 |________/
On Friday December 29, [email protected] 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
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 |________/
On Friday December 29, [email protected] 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 |________/
On Sat, 30 Dec 2000, Neil Brown wrote:
> On Friday December 29, [email protected] 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 |________/
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 <[email protected]>
To: Alexander Zarochentcev <[email protected]>
Cc: Richard Henderson <[email protected]>, [email protected]
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
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~