Skip the mount tests on kernel 4.4.0

[asomers]

Some versions of that kernel have a known bug with tmpfs in namespaces.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1659087

Fixes #610

[Susurrus]

We've got a bunch of failures because of rustup and then a openpty failure. You mentioned that rustup failure in another PR, I don't know what's going on there. Did you ever look into that?

[asomers]

@Susurrus I'm looking at the rustup failure now, but I don't know what's going on. It looks like it's affected every PR for the last 3 days. Travis updated their build images 6 days ago, but we've had successful builds since then, so I don't think that's it. Is there any way to get an interactive session in Travis?

[Susurrus]

I don't think Travis has interactive sessions. I'm wondering if you could reproduce in a VM, maybe it's a Rustup bug?

[Susurrus]

For the record, this fails for me on 4.11.3-202 on Fedora 25.

[asomers]

Perhaps we should just screw the namespaces and require the mount tests to run as root? We're already using sudo in Travis.

[Susurrus]

That's fine. Is there anyway to test for root easily within the tests?

[asomers]

Sure. you can just use getpid() == 0. But I don't know how to tell Cargo to use sudo for the mount tests.

[asomers]

Actually, we're making this way too complicated. There is absolutely no reason why open(2) should return EOVERFLOW. If we see that error code, then we know we're running on a buggy kernel. So we can delete the kernel version check. All we have to do is skip (or pass, since Cargo doesn't know about skipped tests yet) this test whenever we see EOVERFLOW.

[Susurrus]

open() can actually return EOVERFLOW, but I agree it shouldn't in these situations given the manpages for open(2):

 EOVERFLOW
         pathname refers to a regular file that is too large to be opened.  The usual  sce‐
         nario  here  is  that  an  application  compiled  on  a  32-bit  platform  without
         -D_FILE_OFFSET_BITS=64 tried to open a file whose size  exceeds  (1<<31)-1  bytes;
         see  also  O_LARGEFILE  above.  This is the error specified by POSIX.1; in kernels
         before 2.6.24, Linux gave the error EFBIG for this case.

[Susurrus]

Just tested this locally and it works on my end. So I think we might be on to something here. @henninglive Care to give this branch a spin and confirm it fixes things on your end?

[asomers]

I fixed #634, so this PR is the last thing standing between us and green builds again.

[Susurrus]

One thing I'd point out here is that these tests don't just fail on Linux 4.4, they also fail on my 4.11.3 box, so it's something more than that Ubuntu error you linked. I'd expand the comment to include this information as well.

[asomers]

I'm going to go ahead and merge this, without feedback from @henninglive, since the build is broken without it and all other PRs are blocked.

bors r+

[bors]

Build failed

• continuous-integration/travis-ci/push

[asomers]

bors failed because test_aio_cancel_all failed for powerpc on linux. I haven't seen that before, and I don't know what could cause it. I'm going to try again, because we need this mount fix.

bors r+

[bors]

Build succeeded

• buildbot/nix-rust/nix fbsd11
• continuous-integration/travis-ci/push