fsmount not returning fd correctly

[jrahman]

I'm trying to use the fsmount() call for a disk mounting routine.

However, I'm getting the following error:

thread 'main' panicked at /home/azureuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.24/src/backend/linux_raw/io/errno.rs:216:9:
assertion failed: raw.is_in_range(-4095..0)
stack backtrace:
   0: rust_begin_unwind
             at /rustc/b00219924cc3f8d77bcade7a476631976296298f/library/std/src/panicking.rs:595:5
   1: core::panicking::panic_fmt
             at /rustc/b00219924cc3f8d77bcade7a476631976296298f/library/core/src/panicking.rs:67:14
   2: core::panicking::panic
             at /rustc/b00219924cc3f8d77bcade7a476631976296298f/library/core/src/panicking.rs:117:5
   3: rustix::backend::io::errno::try_decode_void
             at /home/azureuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.24/src/backend/linux_raw/io/errno.rs:216:9
   4: rustix::backend::conv::ret
             at /home/azureuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.24/src/backend/linux_raw/conv.rs:868:5
   5: rustix::backend::mount::syscalls::fsmount
             at /home/azureuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.24/src/backend/linux_raw/mount/syscalls.rs:55:14
   6: rustix::mount::fsopen::fsmount
             at /home/azureuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.24/src/mount/fsopen.rs:32:5

The fsmount() wrapper appears to expect a errno return value, but the documentation implies it returns a file descriptor instead: https://github.com/sunfishcode/linux-mount-api-documentation/blob/main/fsmount.md. Specifically, the wrapper here: https://github.com/bytecodealliance/rustix/blob/main/src/backend/linux_raw/mount/syscalls.rs#L55 uses ret() rather than ret_owned_fd(). The wrapper should be fixed to return a OwnedFd using ret_owned_fd().

[sunfishcode]

Thanks for the report! I've submitted #962 with a fix.

I believe we can fix this without waiting for a semver bump, because even though it's a public function signature change, the current function appears to be unusable as it'll practically always fail that assert.

[jrahman]

Great, thank you for the quick response and fix! Yes, based on the bug here, I can't imagine anyone was successfully using this in production code (unless the purpose of the production code was to intentionally crash... :) )

[sunfishcode]

This is now fixed in rustix 0.38.27.