Failed mount tests on x86_64 Ubuntu 16.04.4

[henninglive]

thread 'main' panicked at 'write failed: Value too large for defined data type (os error 75)', test/test_mount.rs:53
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:371
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:495
   7: test_mount::test_mount::test_mount_tmpfs_without_flags_allows_rwx::{{closure}}
             at ./test/test_mount.rs:53
   8: <core::result::Result<T, E>>::unwrap_or_else
             at /checkout/src/libcore/result.rs:706
   9: test_mount::test_mount::test_mount_tmpfs_without_flags_allows_rwx
             at ./test/test_mount.rs:47
  10: test_mount::main
             at ./test/test_mount.rs:217
  11: std::panicking::try::do_call
             at /checkout/src/libstd/panicking.rs:454
  12: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  13: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:433
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:57
  14: main
  15: __libc_start_main
  16: _start
test test_mount::test_mount_tmpfs_without_flags_allows_rwx ... error: test failed

[Susurrus]

Can you give me any more details that this? Ideally you could provide enough details for us to reproduce this, like a code sample we could run.

[henninglive]

I don’t know what is going on here. I get this error every time I run the test harness. At first I thought my system might be corrupt, but I tested this again on my other laptop that is also running ubuntu, and I get the same error there. This is probably not a bug in nix, but I would still like to understand what's wrong

$ rustup show
active toolchain
----------------
stable-x86_64-unknown-linux-gnu (default)
rustc 1.17.0 (56124baa9 2017-04-24)

$ cat /proc/version
Linux version 4.4.0-71-generic (buildd@lcy01-05) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #92-Ubuntu SMP Fri Mar 24 12:59:01 UTC 2017

$ ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu7) 2.23

[Susurrus]

That's the same error I get locally, so now we just need someone to dig into this.

[Susurrus]

@kamalmarhubi Looks like these are tests you wrote that are now failing. They fail locally for me but also on CI on Rust 1.13, so I don't think this was from a CI change or a Rust change. Failure is at test/test_mount.rs:53 and says we're writing too much data, but it's ~20 bytes. So I don't get what's happening here.

[asomers]

For the record, I can't reproduce these failures in my Ubuntu 16.10 VMs, either on x86 or x86_64. Both use Rust 1.15.1 and the BHyve hypervisor.

[asomers]

This is a Linux bug. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1659087 . It looks like the workaround is to access the from within the namespace instead of from without it. I can reproduce it on a Ubuntu 16.04 physical machine even though I can't on my Ubuntu 16.10 VMs.

[Susurrus]

@asomers Do you know enough about this to apply the workaround in our tests?

[asomers]

No. I've never used Linux namespaces before. My first attempt, putting all of the file accesses within an unshare block, didn't work. My next attempt will be to bind setfsuid and try to use that in the mount tests.

[asomers]

I spent an hour or so and couldn't find a working workaround. But the test still passes on Ubuntu 16.10. I suggest that we check uname(), and skip the test if the kernel is 4.4.0.