Re: getmntinfo compatibility question

[Martin Husemann <martin%duskware.de@localhost>]

On Thu, Feb 13, 2025 at 11:13:07PM +0100, Thomas Klausner wrote:
> and versioned the statvfs syscall. I'm not sure how the syscall
> compatibility works, but rust's libc crate still has the old
> definition of the struct

Where is that struct definition?
It seems to be wrong somehow. I tried your program on a powerpc machine
and get:

Breakpoint 3, rust_getmntinfo::get_mount_points () at src/main.rs:20
20          let mut fs_infos: *mut libc::statvfs = std::ptr::null_mut();
(gdb) n
21          let count = unsafe { libc::getmntinfo(&mut fs_infos, libc::MNT_WAIT) };
(gdb) 
22          if count < 1 {
(gdb) p count
$1 = 7
(gdb) p fs_infos[0]
$3 = libc::unix::bsd::netbsdlike::netbsd::statvfs {f_flag: 86016, f_bsize: 4096, f_frsize: 32768, f_iosize: 116136549, f_blocks: 481244119186087439, f_bfree: 124951791354018455, f_bavail: 184717953468299, f_bresvd: 20480, f_files: 52110838204711, f_ffree: 1717990144, f_favail: 0, f_fresvd: 788529152, f_syncreads: 0, f_syncwrites: 0, f_asyncreads: 0, f_asyncwrites: 0, f_fsidx: libc::unix::bsd::fsid_t {__fsid_val: [0, 
      0]}, f_fsid: 0, f_namemax: 0, f_owner: 0, f_spare: [0, 0, 0, 0], f_fstypename: [
    0 <repeats 18 times>, 47, 100, 101, 118, 47, 100, 107, 48, 0, 0, 0, 0, 0, 0], f_mntonname: [
    0 <repeats 77 times>, 7, 16, 0, 0, 0, 2, 0, 0, 0, 2, 0, 0, 0, 0, 2, 0 <repeats 18 times>, 139, 1, 0, 
    1, 210, 139, 0, 0, 0, 0, 0, 0, 16, 0 <repeats 13 times>, 107, 101, 114, 110, 102, 115, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 47, 107, 101, 114, 110, 0 <repeats 85 times>, 107, 101, 114, 110, 102, 115, 
    0 <repeats 86 times>, 16, 0, 0, 0, 2, 0, 0, 0, 2, 0, 0, 0, 0, 2, 0 <repeats 18 times>, 123, 2, 0, 0, 
    107, 123, 0, 0, 0, 0, 0, 0, 16, 0 <repeats 13 times>, 112, 116, 121, 102, 115, 0 <repeats 11 times>, 
    47, 100, 101, 118, 47, 112, 116, 115, 0 <repeats 82 times>, 112, 116, 121, 102, 115, 
    0 <repeats 87 times>...], f_mntfromname: [0 <repeats 77 times>, 2, 0, 0, 0, 0, 2, 0, 0, 0, 32, 0, 127, 
    255, 255, 255, 127, 255, 255, 255, 96, 61, 106, 120, 21, 103, 253, 254, 21, 86, 181, 164, 0, 0, 11, 5, 
    0, 0, 7, 11, 0 <repeats 20 times>, 110, 102, 115, 0 <repeats 13 times>, 47, 109, 112, 51, 
    0 <repeats 86 times>, 101, 109, 109, 97, 115, 58, 47, 110, 111, 114, 97, 105, 100, 47, 109, 112, 51, 
    0 <repeats 74 times>, 2, 0, 0, 0, 0, 2, 0, 0, 0, 32, 0, 127, 255, 255, 255, 127, 255, 255, 255, 96, 
    61, 106, 120, 21, 103, 253, 254, 21, 86, 181, 164, 0, 0, 11, 6, 0, 0, 7, 11, 0 <repeats 20 times>, 
    110, 102, 115, 0 <repeats 13 times>, 47, 109, 110, 116, 0 <repeats 86 times>, 101, 109, 109, 97, 115, 
    58, 47, 110, 101, 108, 108...]}
(gdb) p sizeof(fs_infos[0].f_flag)
$5 = 4

Compare with:

 > df -G /
         / (/dev/dk0    ):   32768 block size         4096 frag size
 116136549 total blocks  112048377 free blocks   106241550 available
  29092606 total files    28605079 free files         a800 filesys id
       ffs fstype           0x5000 flag                255 filename length
         0 owner             12151 syncwrites         2684 asyncwrites


Nearly all fields are wrong or swapped with others (like f_bsize <->
f_frsize) and the f_mntonname field starts 18 bytes early (mountname
should be /dev/dk0, aka 47, 100, 101, 118, 47, 100, 107, 48, 0)

It would be good to compare with a C version calling __getvfsstat90
explicitly (e.g. via syscall()) or a static binary with debug info
compiled on netbsd-9, so we can find out if the error is in the compat
code or the C structure mapping in rust.

The kernel compat part works by calling do_sys_getvfsstat() with entry_sz =
sizeof (struct statvfs) and copyfn = copyout. This just copies mnt_stat
from each mountpoint out to userland (in the not-chrooted case). I see
no kind of translation happen anywhere here.

Martin