Subtle NFS incompatibility with SunOS 4.1.1 on 68K

[Chris Hanson]

I'm netbooting SunOS 4.1.1 on a Sun-3/60 with 8MB RAM entirely diskless from a Raspberry Pi 3B+ running NetBSD 8.1 (as well as SunOS 4.1.4 on a Sun-4/110—and I'd been previously netbooting SunOS 4.1.1 on that system).

It turns out though that I can't compile anything on the Sun-3/60, at least when compilation is taking place in a directory served by NetBSD. My symptoms exactly match this 20+ year old Usenet post:

https://groups.google.com/d/msg/comp.sys.sgi.admin/W6buqXYcfJc/mU14C-wKb54J

Before I set up an external SCSI disk on my Sun-3/60 (so I can rebuild my kernel with the last NFS Jumbo Patch, hoping it fixes this), have there been any bugs identified in serving NFS from NetBSD that might be responsible for this? Or workarounds for known bugs in ancient operating systems that have been removed that would cause this?

-- Chris


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Chris Hanson
I'm netbooting SunOS 4.1.1 on a Sun-3/60 with 8MB RAM entirely diskless from a Raspberry Pi 3B+ running NetBSD 8.1 (as well as SunOS 4.1.4 on a Sun-4/110—and I'd been previously netbooting SunOS 4.1.1 on that system).
https://groups.google.com/d/msg/comp.sys.sgi.admin/W6buqXYcfJc/mU14C-wKb54J

From that post, the failed case (fd 4 is what we care about):

open ("/tmp/as68XXa00533", 0, 0666) = 5
ioctl (5, 0x40125401, 0xdfffdd4) = -1 ENOTTY (Inappropriate ioctl for
device)
fstat (5, 0xdfffe08) = 0
brk (0x894d4) = 0
read (5, "".., 32768) = 84
lseek (5, 0, 1) = 84
lseek (5, 132, 0) = 132
lseek (4, 152, 0) = 152
write (4, "".., 154) = 154
lseek (4, 268, 0) = 268
write (4, "".., 4) = 4
lseek (4, 0, 0) = 0
write (4, "", -32768) = -1 EINVAL (Invalid argument) <------ WTF??
write (2, "as: Assembler Error-- ", 22) = as: Assembler Error-- 22
write (2, "write error on file bla.o", 25) = write error on file bla.o25

Does this happen for you, as well? (Can you run "trace" on the Sun 3?)

Can you get a tcpdump of the failure from the RPI?

Post by Chris Hanson
Before I set up an external SCSI disk on my Sun-3/60 (so I can rebuild my kernel with the last NFS Jumbo Patch, hoping it fixes this), have there been any bugs identified in serving NFS from NetBSD that might be responsible for this? Or workarounds for known bugs in ancient operating systems that have been removed that would cause this?
-- Chris

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chris Hanson]

Post by Jason Thorpe
open ("/tmp/as68XXa00533", 0, 0666) = 5
ioctl (5, 0x40125401, 0xdfffdd4) = -1 ENOTTY (Inappropriate ioctl for
device)
fstat (5, 0xdfffe08) = 0
brk (0x894d4) = 0
read (5, "".., 32768) = 84
lseek (5, 0, 1) = 84
lseek (5, 132, 0) = 132
lseek (4, 152, 0) = 152
write (4, "".., 154) = 154
lseek (4, 268, 0) = 268
write (4, "".., 4) = 4
lseek (4, 0, 0) = 0
write (4, "", -32768) = -1 EINVAL (Invalid argument) <------ WTF??
write (2, "as: Assembler Error-- ", 22) = as: Assembler Error-- 22
write (2, "write error on file bla.o", 25) = write error on file bla.o25
Does this happen for you, as well? (Can you run "trace" on the Sun 3?)

Yes, here's the complete trace, same command line for maximum possible equivalence:

ferrari% trace as -o bla.o bla.s
open ("/usr/lib/ld.so", 0, 021044) = 3
read (3, "".., 32) = 32
mmap (0, 139264, 0x5, 0x80000002, 3, 0) = 0xdddc000
mmap (0xddfc000, 8192, 0x7, 0x80000012, 3, 24576) = 0xddfc000
munmap (0xdde2000, 106496) = 0
open ("/dev/zero", 0, 021152) = 4
getrlimit (3, 0xdfffdd8) = 0
mmap (0xde00000, 8192, 0x3, 0x80000012, 4, 0) = 0xde00000
close (3) = 0
getuid () = 1000
getgid () = 100
open ("/etc/ld.so.cache", 0, 01570000140) = 3
fstat (3, 0xdfffd48) = 0
mmap (0, 8192, 0x1, 0x80000001, 3, 0) = 0xddf8000
close (3) = 0
open ("/usr/lib/libc.so.0.15.2", 0, 01567347332) = 3
read (3, "".., 32) = 32
mmap (0, 409600, 0x5, 0x80000002, 3, 0) = 0xdd76000
mmap (0xddd6000, 16384, 0x7, 0x80000012, 3, 385024) = 0xddd6000
close (3) = 0
open ("/usr/lib/libdl.so.1.0", 0, 01567347162) = 3
read (3, "".., 32) = 32
mmap (0, 139264, 0x5, 0x80000002, 3, 0) = 0xdd52000
mmap (0xdd72000, 8192, 0x7, 0x80000012, 3, 8192) = 0xdd72000
close (3) = 0
close (4) = 0
sigblock (0x2) = 0
sigvec (2, 0xdfffe94, 0xdfffe88) = 0
sigvec (2, 0xdfffe58, 0) = 0
sigsetmask (0) = 0x2
open ("bla.s", 0, 0666) = 3
open ("bla.o", 03001, 0666) = 4
close (4) = 0
getpagesize () = 8192
brk (0x474d4) = 0
brk (0x494d4) = 0
brk (0x4d4d4) = 0
ioctl (3, 0x40125401, 0xdfffd98) = -1 ENOTTY (Inappropriate ioctl for device)
fstat (3, 0xdfffdcc) = 0
brk (0x5f4d4) = 0
read (3, "", 65536) = 0
lseek (3, 0, 0) = 0
open ("bla.o", 03001, 0666) = 4
fstat (4, 0xdfffe54) = 0
getpid () = 445
stat ("/tmp/as68XXa00445", 0xdfffe54) = -1 ENOENT (No such file or directory)
open ("/tmp/as68XXa00445", 03001, 0666) = 5
open ("/tmp/as68XXa00445", 01001, 0666) = 6
lseek (6, 0, 2) = 0
lseek (6, 0, 0) = 0
brk (0x714d4) = 0
brk (0x834d4) = 0
brk (0x954d4) = 0
brk (0xa74d4) = 0
read (3, "", 65536) = 0
close (5) = 0
close (6) = 0
open ("/tmp/as68XXa00445", 0, 0666) = 5
brk (0xb94d4) = 0
lseek (5, 0, 0) = 0
lseek (4, 32, 0) = 32
write (4, "", -32) = -1 EINVAL (Invalid argument)
write (2, "as: Assembler Error-- ", 22) = as: Assembler Error-- 22
write (2, "write error on file bla.o", 25) = write error on file bla.o25
close (0) = 0
close (1) = 0
close (2) = 0
close (3) = 0
close (4) = 0
close (5) = 0
exit (-1) = ?
ferrari%

Looks like the same issue, my system consistently passes -32 to write(4, ...) rather than -32768 but otherwise it's the same.

Post by Jason Thorpe
Can you get a tcpdump of the failure from the RPI?

I'll try! I'll have to figure out how, but I expect it should be straightforward, right?

-- Chris



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Chris Hanson
Looks like the same issue, my system consistently passes -32 to write(4, ...) rather than -32768 but otherwise it's the same.

Yah, that's completely weird why it would be passing a negative number to write(). Almost like it got a bad value from stat() or something?

Post by Chris Hanson

Post by Jason Thorpe
Can you get a tcpdump of the failure from the RPI?

I'll try! I'll have to figure out how, but I expect it should be straightforward, right?

On the RPI:

sudo tcpdump -w nfs-fail.pcap port 2049

...ought to do it. Run that command on the RPI, attempt the test case on the Sun, ^C the tcpdump on the RPI, and the .pcap file should have a packet capture that can be easily sliced and diced in Wireshark.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chris Hanson]

Post by Jason Thorpe

Post by Chris Hanson
Looks like the same issue, my system consistently passes -32 to write(4, ...) rather than -32768 but otherwise it's the same.

Yah, that's completely weird why it would be passing a negative number to write(). Almost like it got a bad value from stat() or something?

Interesting that you mention that, since this is the output of df on my Sun-3:

ferrari% df
Filesystem kbytes used avail capacity Mounted on
pi3bsd:/export/sun/root/ferrari.sun3.sunos.4.1.1
-1619144 -3584 -486024 65% /
pi3bsd:/export/sun/exec/sun3.sunos.4.1.1
-1619144 -3584 -486024 65% /usr
pi3bsd:/export/sun/exec/kvm/sun3.sunos.4.1.1
-1619144 -3584 -486024 65% /usr/kvm
pi3bsd:/export/sun/exec/share/sunos.4.1.1/man
-1619144 -3584 -486024 65% /usr/share/man
pi3bsd:/export/sun/exec/local/sun3.sunos.4.1.x
-1619144 -3584 -486024 65% /usr/local
pi3bsd:/export/sun/home
-1619144 -3584 -486024 65% /home
ferrari%


I wonder if something is getting screwed up by the obvious integer overflows in computing filesystem size.

Post by Jason Thorpe

Post by Chris Hanson

Post by Jason Thorpe
Can you get a tcpdump of the failure from the RPI?

I'll try! I'll have to figure out how, but I expect it should be straightforward, right?

sudo tcpdump -w nfs-fail.pcap port 2049
...ought to do it. Run that command on the RPI, attempt the test case on the Sun, ^C the tcpdump on the RPI, and the .pcap file should have a packet capture that can be easily sliced and diced in Wireshark.

I don't have WireShark handy, I can share the pcap with you if you want though. I figure I'll spare the rest of the list that 8KB attachment.

-- Chris


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Chris Hanson

Post by Jason Thorpe
Yah, that's completely weird why it would be passing a negative number to write(). Almost like it got a bad value from stat() or something?

ferrari% df
Filesystem kbytes used avail capacity Mounted on
pi3bsd:/export/sun/root/ferrari.sun3.sunos.4.1.1
-1619144 -3584 -486024 65% /
pi3bsd:/export/sun/exec/sun3.sunos.4.1.1
-1619144 -3584 -486024 65% /usr
pi3bsd:/export/sun/exec/kvm/sun3.sunos.4.1.1
-1619144 -3584 -486024 65% /usr/kvm
pi3bsd:/export/sun/exec/share/sunos.4.1.1/man
-1619144 -3584 -486024 65% /usr/share/man
pi3bsd:/export/sun/exec/local/sun3.sunos.4.1.x
-1619144 -3584 -486024 65% /usr/local
pi3bsd:/export/sun/home
-1619144 -3584 -486024 65% /home
ferrari%

How big is the file system that you're sharing to the Sun 3? Is it larger than 2GB? (Probably...)

SunOS 4.1.1 is definitely going to be using NFSv2, and that's probably not an oft-exercised code path in the server these days.

Post by Chris Hanson
I wonder if something is getting screwed up by the obvious integer overflows in computing filesystem size.

Post by Jason Thorpe

Post by Chris Hanson

Post by Jason Thorpe
Can you get a tcpdump of the failure from the RPI?

I'll try! I'll have to figure out how, but I expect it should be straightforward, right?

sudo tcpdump -w nfs-fail.pcap port 2049
...ought to do it. Run that command on the RPI, attempt the test case on the Sun, ^C the tcpdump on the RPI, and the .pcap file should have a packet capture that can be easily sliced and diced in Wireshark.

I don't have WireShark handy, I can share the pcap with you if you want though. I figure I'll spare the rest of the list that 8KB attachment.
-- Chris

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Jason Thorpe
How big is the file system that you're sharing to the Sun 3? Is it larger than 2GB? (Probably...)

Indeed it is, I'm using a 64GB SD card with one NetBSD partition and one swap partition (which is hardly ever touched). So it's not just >2GB, it's >4GB.

Yah, what the NFS server really should do in this case is saturate the 32-bit values it vends over NFSv2... but it's probably not doing that ... it's probably just truncating them.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Tue, 17 Mar 2020 15:59:53 -0700
From: Chris Hanson <***@eschatologist.net>
Message-ID: <4F11714D-0E84-4E6F-A603-***@eschatologist.net>

| I'll try! I'll have to figure out how, but I expect it should be straightforward, right?


Yes

tcpdump -s 1600 -i <whatever> -w /tmp/trace host sun3-60

run on NetBSD (the RPI) Do include the -s arg. Then later

tcpdump -v -r /tmp/trace -s 1600 udp

(or use wireshark as Jason suggested)

Keep the trace file, it can be read over and over with different args.

But if y9ur setup is identical to teh old 1997 report, try removing
the unnecessay lines from fstab - that one had one exported filesystem
(plus swap - that's OK) so only needs to mount / (/usr/and /usr/share
should be already there). I can't see how that could cause a problem,
but as the issue seems likely to be bad data in the temp files (the only
reason for the bizarre write length I can imagine) it may be a buffering
problem, and complicating things by having unnecessary mounts cannot help.

kre



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[i***@netbsd.org]

hi,

Post by Jason Thorpe

Post by Jason Thorpe
How big is the file system that you're sharing to the Sun 3? Is it larger than 2GB? (Probably...)

Indeed it is, I'm using a 64GB SD card with one NetBSD partition and one swap partition (which is hardly ever touched). So it's not just >2GB, it's >4GB.

Yah, what the NFS server really should do in this case is saturate the 32-bit values it vends over NFSv2... but it's probably not doing that ... it's probably just truncating them.

Reminds me:

I vaguely remember needing to do mount tricks with 32bit clients
(NetBSD-i386) vs. 64bit server (NetBSD-Sparc)... "back then" at
work, but still running, there's one active emeritus remaining in
that work group.

Let me check whether that's still in the configuration... yes, but
the special option is on the client side, so a different case?
Here's the client's amd map file for /home

/defaults type:=nfs;opts:=rw,hard,intr,nodev,nosuid,xlatecookie,nocoredump
theory rhost:=theory;rfs:=/export/home/3;opts:=xlatecookie,rw,hard,intr,nodev,nosuid

Nothing special on the server (NetBSD-Sparc64)

Regards,
-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by i***@netbsd.org
I vaguely remember needing to do mount tricks with 32bit clients
(NetBSD-i386) vs. 64bit server (NetBSD-Sparc)... "back then" at
work, but still running, there's one active emeritus remaining in
that work group.
Let me check whether that's still in the configuration... yes, but
the special option is on the client side, so a different case?
Here's the client's amd map file for /home

Yah, that seems like a different problem, maybe. I don't think this is a dir cookie problem.

Post by i***@netbsd.org
/defaults type:=nfs;opts:=rw,hard,intr,nodev,nosuid,xlatecookie,nocoredump
theory rhost:=theory;rfs:=/export/home/3;opts:=xlatecookie,rw,hard,intr,nodev,nosuid
Nothing special on the server (NetBSD-Sparc64)
Regards,
-is

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chris Hanson]

Post by Jason Thorpe
Yah, that seems like a different problem, maybe. I don't think this is a dir cookie problem.

Yeah, it does seem to create bla.o properly, it just passes a negative length to write() for some reason.

It *is* 68K code so I could probably figure out the debugger and try to debug where it's getting the negative value from.

-- Chris


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chris Hanson]

This definitely seems to be something at issue in NetBSD NFS; when I enable NFSv2 serving on my Linux box, I can mount a directory on the Sun-3 and compile/assemble to my heart’s content.

At some point in the next few days, I'll see if rebuilding the GENERIC kernel with several of the latest patches works.

-- Chris


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Brownlee]

Post by Chris Hanson
This definitely seems to be something at issue in NetBSD NFS; when I enable NFSv2 serving on my Linux box, I can mount a directory on the Sun-3 and compile/assemble to my heart’s content.
At some point in the next few days, I'll see if rebuilding the GENERIC kernel with several of the latest patches works.

Just a quick though - could you test creating a small filesystem
(under 2GB) and export that to see if SunOS 68k is happy with that?

David

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chris Hanson]

Post by David Brownlee

Post by Chris Hanson
This definitely seems to be something at issue in NetBSD NFS; when I enable NFSv2 serving on my Linux box, I can mount a directory on the Sun-3 and compile/assemble to my heart’s content.
At some point in the next few days, I'll see if rebuilding the GENERIC kernel with several of the latest patches works.

Just a quick though - could you test creating a small filesystem
(under 2GB) and export that to see if SunOS 68k is happy with that?

Good idea, I’ll give that a try! I should be able to do that with a loopback/virtual mount, yes?

— Chris



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chris Hanson]

Post by Chris Hanson

Post by David Brownlee

Post by Chris Hanson
This definitely seems to be something at issue in NetBSD NFS; when I enable NFSv2 serving on my Linux box, I can mount a directory on the Sun-3 and compile/assemble to my heart’s content.
At some point in the next few days, I'll see if rebuilding the GENERIC kernel with several of the latest patches works.

Just a quick though - could you test creating a small filesystem
(under 2GB) and export that to see if SunOS 68k is happy with that?

Good idea, I’ll give that a try! I should be able to do that with a loopback/virtual mount, yes?

Here’s what I did, on the RPi running NetBSD (pi3bsd):

# cd /export/sun
# dd if=/dev/zero of=smallfs.iso bs=1048576 count=404
# vnconfig vnd0 smallfs.iso
# newfs -O 2 /dev/rvnd0
# mkdir smallfs
# mount /dev/vnd0 smallfs
# cat >> /etc/exports
/export/sun/smallfs -maproot=root:wheel ferrari
^D
# kill -HUP `cat /var/run/mountd.pid`

And on the Sun-3/60 (ferrari):

# mkdir /mnt2
# mount pi3bsd:/export/sun/smallfs /mnt2
# cd /mnt2

Then I copied some stuff there and compiled it with stock cc, which uses stock as. From there, I can compile and assemble to my heart’s content.

So something is definitely going wrong in what the server is reporting under NFSv2 for a >2GB volume.

— Chris



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Chris Hanson
So something is definitely going wrong in what the server is reporting under NFSv2 for a >2GB volume.

NFSv2 uses signed 32bit integers and the code simply truncates larger numbers.

There is no perfect solution since NFSv2 cannot handle larger filesytems or
files, but clamping the values to INT32_MAX should help. There are two
places that are relevant: filesystem data (size, free+avail blocks)
and file data (file length).

For files there is a danger. SunOS did fail syscalls for large files
and hid them from directory listings to prevent programs from using
clamped or otherwise truncated size values. For simple things, like
writing a logfile that grows beyond 2GB that's maybe too strong.
On the other hand, Your SunOS client may not yet support large files,
so it would be a good thing.

[Chris Hanson]

Post by Michael van Elst

Post by Chris Hanson
So something is definitely going wrong in what the server is reporting under NFSv2 for a >2GB volume.

NFSv2 uses signed 32bit integers and the code simply truncates larger numbers.
There is no perfect solution since NFSv2 cannot handle larger filesytems or
files, but clamping the values to INT32_MAX should help. There are two
places that are relevant: filesystem data (size, free+avail blocks)
and file data (file length).

I think I've found the spot in the code where this lives, this would be in nfsrv_statfs() sys/nfs/nfs_serv.c, correct? Where it sets sfp->sf_* to a bunch of txdr_unsigned() without clamping them?

Do I have to rebuild the entire kernel to attempt a fix or can I just rebuild NFS somehow? (If the latter, is there a walkthrough somewhere?)

Post by Michael van Elst
For files there is a danger. SunOS did fail syscalls for large files
and hid them from directory listings to prevent programs from using
clamped or otherwise truncated size values. For simple things, like
writing a logfile that grows beyond 2GB that's maybe too strong.
On the other hand, Your SunOS client may not yet support large files,
so it would be a good thing.

I'm not too worried about this personally, even if it's an issue generally. I don't expect to be working with files that large on an older NFSv2-only operating system, I don't think many others do either. It'd still be good to know for sure and have the bug logged, I'm sure, and also to fix eventually for correctness.

-- Chris


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Brownlee]

Post by Chris Hanson

Post by Michael van Elst

Post by Chris Hanson
So something is definitely going wrong in what the server is reporting under NFSv2 for a >2GB volume.

NFSv2 uses signed 32bit integers and the code simply truncates larger numbers.
There is no perfect solution since NFSv2 cannot handle larger filesytems or
files, but clamping the values to INT32_MAX should help. There are two
places that are relevant: filesystem data (size, free+avail blocks)
and file data (file length).

I think I've found the spot in the code where this lives, this would be in nfsrv_statfs() sys/nfs/nfs_serv.c, correct? Where it sets sfp->sf_* to a bunch of txdr_unsigned() without clamping them?

There are probably more - I suspect
https://nxr.netbsd.org/xref/src/sys/nfs/nfs_subs.c#1697 is going to be
needed for file sizes.

Post by Chris Hanson
Do I have to rebuild the entire kernel to attempt a fix or can I just rebuild NFS somehow? (If the latter, is there a walkthrough somewhere?)

You'll need to rebuild the entire kernel - if you have a faster box
with disk space its usually easier to download the source onto that,
then

./build.sh -U -m MACHINE tools kernel=GENERIC

(where MACHINE is the output of "uname -p" from the target box)

after the first build you can just use the config and nbmake-MACHINE
from obj/tooldir.*/bin/ to rebuild the kernel

Post by Chris Hanson

Post by Michael van Elst
For files there is a danger. SunOS did fail syscalls for large files
and hid them from directory listings to prevent programs from using
clamped or otherwise truncated size values. For simple things, like
writing a logfile that grows beyond 2GB that's maybe too strong.
On the other hand, Your SunOS client may not yet support large files,
so it would be a good thing.

I'm not too worried about this personally, even if it's an issue generally. I don't expect to be working with files that large on an older NFSv2-only operating system, I don't think many others do either. It'd still be good to know for sure and have the bug logged, I'm sure, and also to fix eventually for correctness.

I think it would be good to fix - if we have the nfsv2 code then it
should do something better in this case :) As Jason says saturating
the value would be better than the current behaviour.

I'm happy enough to have a poke at it if no-one else is interested :)

David

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chris Hanson]

Post by David Brownlee

Post by Chris Hanson
I think I've found the spot in the code where this lives, this would be in nfsrv_statfs() sys/nfs/nfs_serv.c, correct? Where it sets sfp->sf_* to a bunch of txdr_unsigned() without clamping them?

There are probably more - I suspect
https://nxr.netbsd.org/xref/src/sys/nfs/nfs_subs.c#1697 is going to be
needed for file sizes.

I just masked the input to txdr_unsigned() to 0x7fffffff before assigning it to sfp->sf_*; did a build of tools, kernel=RPI2 and distribution; and put the new kernel and nfsserver.kmod in place. Now I can compile & assemble from my Sun!

The Raspberry Pi 3B+ has been plenty fast at rebuilding everything. After all, even the original Raspberry Pi is *way* faster than a stock SPARCstation 20. ;)

Post by David Brownlee
I think it would be good to fix - if we have the nfsv2 code then it
should do something better in this case :) As Jason says saturating
the value would be better than the current behaviour.
I'm happy enough to have a poke at it if no-one else is interested :)

Unfortunately I can't share my actual code without jumping through some bureaucratic hoops, but hopefully knowing that this works is sufficient for someone to put a more complete fix than my quick hack into mainline. :)

-- Chris



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chris Hanson]

Post by Chris Hanson
I just masked the input to txdr_unsigned() to 0x7fffffff before assigning it to sfp->sf_*; did a build of tools, kernel=RPI2 and distribution; and put the new kernel and nfsserver.kmod in place. Now I can compile & assemble from my Sun!

I spoke too soon; `as -o bla.o bla.s` works for an empty bla.s, but `cc -o hello hello.c` for "Hello, world!" still gives me an error. I'll continue to investigate.

-- Chris



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chris Hanson]

Post by Chris Hanson

Post by Chris Hanson
I just masked the input to txdr_unsigned() to 0x7fffffff before assigning it to sfp->sf_*; did a build of tools, kernel=RPI2 and distribution; and put the new kernel and nfsserver.kmod in place. Now I can compile & assemble from my Sun!

I spoke too soon; `as -o bla.o bla.s` works for an empty bla.s, but `cc -o hello hello.c` for "Hello, world!" still gives me an error. I'll continue to investigate.

Looking at the output of trace when trying to assemble the "Hello, world!" .s file, the issue is the same: Passing a size of -32 to write(2). I do notice that there's a difference in df output on the Sun with my hack in place on the NFS server, but still plenty of negatives:

Filesystem kbytes used avail capacity Mounted on
pi3bsd:/export/sun/root/ferrari.sun3.sunos.4.1.1
-1619144 733976-1223584 80% /
pi3bsd:/export/sun/exec/sun3.sunos.4.1.1
-1619144 733976-1223584 80% /usr
pi3bsd:/export/sun/exec/kvm/sun3.sunos.4.1.1
-1619144 733976-1223584 80% /usr/kvm
pi3bsd:/export/sun/exec/share/sunos.4.1.1/man
-1619144 733976-1223584 80% /usr/share/man
pi3bsd:/export/sun/exec/local/sun3.sunos.4.1.x
-1619144 733976-1223584 80% /usr/local
pi3bsd:/export/sun/home
-1619144 733976-1223584 80% /home

So there's more to tweak. At least my next build will be super-quick!

-- Chris


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[i***@cs.uni-bonn.de]

Post by Chris Hanson
I just masked the input to txdr_unsigned() to 0x7fffffff before assigning it to sfp->sf_*; did a build of tools, kernel=RPI2 and distribution; and put the new kernel and nfsserver.kmod in place. Now I can compile & assemble from my Sun!

Wouldn't the right thing to do to do the equivalent

target = input > MAXINT_32bit ? MAXINT_32bit : target

instead?

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Chris Hanson
I spoke too soon; `as -o bla.o bla.s` works for an empty bla.s, but `cc -o hello hello.c` for "Hello, world!" still gives me an error. I'll continue to investigate.

It's a bit irritating what the assembler does.

It opens the destination file, skips the (not yet written) 32 byte exec
header and then tries to write an output buffer of size zero reduced
by the size of the exec header (thus the -32).

I'd like to see what st_blksize value you get when you stat() a file
on the SunOS client. Unfortunately there is no stat(1) program, maybe
adb can help and you can get the result of:

| fstat (4, 0xdfffe54) = 0


Greetings,

[Michael van Elst]

Post by i***@cs.uni-bonn.de

Post by Chris Hanson
I just masked the input to txdr_unsigned() to 0x7fffffff before assigning it to sfp->sf_*; did a build of tools, kernel=RPI2 and distribution; and put the new kernel and nfsserver.kmod in place. Now I can compile & assemble from my Sun!

Wouldn't the right thing to do to do the equivalent
target = input > MAXINT_32bit ? MAXINT_32bit : target

Depends on what you query. Filesystem statistics shouldn't be a problem
to clamp.

File sizes on the other hand. It's probably better to fail stat() calls for
large files. lseek() would also need to handle large files, but I don't know
how the NFS server could influence it. I guess you can only fail read() and
write() when you pass the 32bit limit.

[Chris Hanson]

Post by Michael van Elst

Post by Chris Hanson
I spoke too soon; `as -o bla.o bla.s` works for an empty bla.s, but `cc -o hello hello.c` for "Hello, world!" still gives me an error. I'll continue to investigate.

It's a bit irritating what the assembler does.
It opens the destination file, skips the (not yet written) 32 byte exec
header and then tries to write an output buffer of size zero reduced
by the size of the exec header (thus the -32).
I'd like to see what st_blksize value you get when you stat() a file
on the SunOS client. Unfortunately there is no stat(1) program, maybe
| fstat (4, 0xdfffe54) = 0

I can always mount an NFS directory served by Linux and compile something there. (I did that to build gas and gcc, which work for building stuff via NetBSD-served NFS.)

I'll write a little thing and get back to you.

-- Chris



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Chris Hanson

Post by Michael van Elst
I'd like to see what st_blksize value you get when you stat() a file
on the SunOS client. Unfortunately there is no stat(1) program, maybe
| fstat (4, 0xdfffe54) = 0

I can always mount an NFS directory served by Linux and compile something there. (I did that to build gas and gcc, which work for building stuff via NetBSD-served NFS.)

Yes, check what st_blksize is reported by Linux and what write() size
you get there.

Greetings,

[Chris Hanson]

Post by Michael van Elst

Post by Chris Hanson

Post by Michael van Elst
I'd like to see what st_blksize value you get when you stat() a file
on the SunOS client. Unfortunately there is no stat(1) program, maybe
| fstat (4, 0xdfffe54) = 0

I can always mount an NFS directory served by Linux and compile something there. (I did that to build gas and gcc, which work for building stuff via NetBSD-served NFS.)

Yes, check what st_blksize is reported by Linux and what write() size
you get there.

NFS from NetBSD (with my hack mentioned earlier):
ferrari% ./stat ~/projects/stat/stat.c
stat("/home/cmh/projects/stat/stat.c")
stat.st_blksize = 65536 (0x10000)
stat.st_blocks = 16 (0x10)

NFS from Linux:
ferrari% ./stat /mnt2/projects/stat/stat.c
stat("/mnt2/projects/stat/stat.c")
stat.st_blksize = 4096 (0x1000)
stat.st_blocks = 8 (0x8)

And below is a trace of assembling hello.c with cwd on NFS from Linux.

— Chris

ferrari% trace /bin/as -o hello.o -mc68020 /tmp/ccom.09488.1.s
open ("/usr/lib/ld.so", 0, 021044) = 3
read (3, "".., 32) = 32
mmap (0, 139264, 0x5, 0x80000002, 3, 0) = 0xdddc000
mmap (0xddfc000, 8192, 0x7, 0x80000012, 3, 24576) = 0xddfc000
munmap (0xdde2000, 106496) = 0
open ("/dev/zero", 0, 021152) = 4
getrlimit (3, 0xdfffdb4) = 0
mmap (0xde00000, 8192, 0x3, 0x80000012, 4, 0) = 0xde00000
close (3) = 0
getuid () = 1000
getgid () = 100
open ("/etc/ld.so.cache", 0, 01570000140) = 3
fstat (3, 0xdfffd24) = 0
mmap (0, 8192, 0x1, 0x80000001, 3, 0) = 0xddf8000
close (3) = 0
open ("/usr/lib/libc.so.0.15.2", 0, 01567347332) = 3
read (3, "".., 32) = 32
mmap (0, 409600, 0x5, 0x80000002, 3, 0) = 0xdd76000
mmap (0xddd6000, 16384, 0x7, 0x80000012, 3, 385024) = 0xddd6000
close (3) = 0
open ("/usr/lib/libdl.so.1.0", 0, 01567347162) = 3
read (3, "".., 32) = 32
mmap (0, 139264, 0x5, 0x80000002, 3, 0) = 0xdd52000
mmap (0xdd72000, 8192, 0x7, 0x80000012, 3, 8192) = 0xdd72000
close (3) = 0
close (4) = 0
sigblock (0x2) = 0
sigvec (2, 0xdfffe70, 0xdfffe64) = 0
sigvec (2, 0xdfffe34, 0) = 0
sigsetmask (0) = 0x2
open ("/tmp/ccom.09488.1.s", 0, 0666) = 3
open ("hello.o", 03001, 0666) = 4
close (4) = 0
getpagesize () = 8192
brk (0x474d4) = 0
brk (0x494d4) = 0
brk (0x4d4d4) = 0
ioctl (3, 0x40125401, 0xdfffd74) = -1 ENOTTY (Inappropriate ioctl for device)
fstat (3, 0xdfffda8) = 0
brk (0x5f4d4) = 0
read (3, "LL0:\n\t.data\n\t.text\n\t.proc\n|#PROC".., 65536) = 354
read (3, "", 65536) = 0
lseek (3, 0, 0) = 0
open ("hello.o", 03001, 0666) = 4
fstat (4, 0xdfffe30) = 0
getpid () = 9492
stat ("/tmp/as68XXa09492", 0xdfffe30) = -1 ENOENT (No such file or directory)
open ("/tmp/as68XXa09492", 03001, 0666) = 5
open ("/tmp/as68XXa09492", 01001, 0666) = 6
lseek (6, 0, 2) = 0
lseek (6, 60, 0) = 60
brk (0x614d4) = 0
read (3, "LL0:\n\t.data\n\t.text\n\t.proc\n|#PROC".., 65536) = 354
ioctl (5, 0x40125401, 0xdfffc38) = -1 ENOTTY (Inappropriate ioctl for device)
fstat (5, 0xdfffc6c) = 0
brk (0x734d4) = 0
read (3, "", 65536) = 0
write (5, "".., 24) = 24
close (5) = 0
close (6) = 0
open ("/tmp/as68XXa09492", 0, 0666) = 5
ioctl (5, 0x40125401, 0xdfffd74) = -1 ENOTTY (Inappropriate ioctl for device)
fstat (5, 0xdfffda8) = 0
read (5, "".., 65536) = 24
lseek (5, 0, 1) = 24
lseek (5, 60, 0) = 60
lseek (4, 88, 0) = 88
write (4, "".., 58) = 58
lseek (4, 128, 0) = 128
write (4, "".., 4) = 4
close (5) = 0
unlink ("/tmp/as68XXa09492") = 0
lseek (4, 0, 0) = 0
write (4, "".., 32) = 32
lseek (4, 72, 0) = 72
write (4, "Hello, world!\n\0", 15) = 15
lseek (4, 32, 0) = 32
write (4, "".., 36) = 36
close (0) = 0
close (1) = 0
close (2) = 0
close (3) = 0
close (4) = 0
exit (0) = ?



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Chris Hanson
And below is a trace of assembling hello.c with cwd on NFS from Linux.
lseek (4, 88, 0) = 88

-> skip headers and string section

Post by Chris Hanson
write (4, "".., 58) = 58

-> write code(?) segment

That's different. What about trying the empty file again ?

N.B. if my assumption is right that the preferred blocksize of 64k
is truncated somewhere and causing this behaviour, then you either need
to serve a filesystem with smaller blocks or patch the NFS server
code in nfsm_srvfattr() to verify this. For NFSv2 the value is transmitted
in fa2_blocksize.

[Chris Hanson]

Post by Michael van Elst
N.B. if my assumption is right that the preferred blocksize of 64k
is truncated somewhere and causing this behaviour, then you either need
to serve a filesystem with smaller blocks or patch the NFS server
code in nfsm_srvfattr() to verify this. For NFSv2 the value is transmitted
in fa2_blocksize.

I'll see whether doing so fixes anything, and just use the same preferred block size as my Linux box (4096). Or should I use the server's page size (8192)?

-- Chris


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Chris Hanson

Post by Michael van Elst
N.B. if my assumption is right that the preferred blocksize of 64k
is truncated somewhere and causing this behaviour, then you either need
to serve a filesystem with smaller blocks or patch the NFS server
code in nfsm_srvfattr() to verify this. For NFSv2 the value is transmitted
in fa2_blocksize.

I'll see whether doing so fixes anything, and just use the same preferred block size as my Linux box (4096). Or should I use the server's page size (8192)?

For testing, either should work.

[David Brownlee]

Post by Chris Hanson

Post by Michael van Elst
N.B. if my assumption is right that the preferred blocksize of 64k
is truncated somewhere and causing this behaviour, then you either need
to serve a filesystem with smaller blocks or patch the NFS server
code in nfsm_srvfattr() to verify this. For NFSv2 the value is transmitted
in fa2_blocksize.

I'll see whether doing so fixes anything, and just use the same preferred block size as my Linux box (4096). Or should I use the server's page size (8192)?

As an aside - you mentioned that exporting a <2GB filesystem from
NetBSD worked - what blocksize did that report?

David

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chris Hanson]

Post by David Brownlee

Post by Chris Hanson

Post by Michael van Elst
N.B. if my assumption is right that the preferred blocksize of 64k
is truncated somewhere and causing this behaviour, then you either need
to serve a filesystem with smaller blocks or patch the NFS server
code in nfsm_srvfattr() to verify this. For NFSv2 the value is transmitted
in fa2_blocksize.

I'll see whether doing so fixes anything, and just use the same preferred block size as my Linux box (4096). Or should I use the server's page size (8192)?

As an aside - you mentioned that exporting a <2GB filesystem from
NetBSD worked - what blocksize did that report?

stat.st_blksize = 8192 (0x2000)
stat.st_blocks = 70 (0x46)

-- Chris


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Chris Hanson

Post by Michael van Elst
N.B. if my assumption is right that the preferred blocksize of 64k
is truncated somewhere and causing this behaviour, then you either need
to serve a filesystem with smaller blocks or patch the NFS server
code in nfsm_srvfattr() to verify this. For NFSv2 the value is transmitted
in fa2_blocksize.

I'll see whether doing so fixes anything, and just use the same preferred block size as my Linux box (4096). Or should I use the server's page size (8192)?

Can you please try the patch at:

http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/nfs.diff

?

Greetings,

[Chris Hanson]

Post by Michael van Elst

Post by Chris Hanson

Post by Michael van Elst
N.B. if my assumption is right that the preferred blocksize of 64k
is truncated somewhere and causing this behaviour, then you either need
to serve a filesystem with smaller blocks or patch the NFS server
code in nfsm_srvfattr() to verify this. For NFSv2 the value is transmitted
in fa2_blocksize.

I'll see whether doing so fixes anything, and just use the same preferred block size as my Linux box (4096). Or should I use the server's page size (8192)?

http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/nfs.diff

I'll give it a try! I did just rebuild with a hardcoded blocksize of 8192 and that works perfectly, so I expect your fix will work well too.

-- Chris



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chris Hanson]

Post by Chris Hanson

Post by Michael van Elst
http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/nfs.diff

I'll give it a try! I did just rebuild with a hardcoded blocksize of 8192 and that works perfectly, so I expect your fix will work well too.

Your patch works: I'm able to compile pretty much arbitrary code, and I'm even building a new kernel on SunOS against the fixed NFS code and it works fine.

Thanks so much!

-- Chris


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de