Support fallocate on Linux

[LorrensP-2158466]

Closes #5137

This PR implements the linux syscall fallocate and its 64-bit version. It is an extended version of posix_fallocate. So for now this pr only implements the posix_fallocate behaviour as explained in the man page.

All other "features" are rather specific and I couldn't find a reliable way to mimic them in Miri, they also specify that they require file system support, so i have no clue there.

If needed, I can include them here or in a follow-up PR.

[LorrensP-2158466]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[LorrensP-2158466]

@rustbot ready

[RalfJung]

Thanks a lot! And sorry for the slow review, I was dealing with a $job deadline.
@rustbot author

View changes since this review

[RalfJung]

Suggested change

	let this = self.eval_context_mut();
	// This is mostly a copy of `posix_fallocate` except that errors are returned via errno.
	let this = self.eval_context_mut();

Any idea how we could avoid all this code duplication?

[LorrensP-2158466]

3rd commit shows my vision of it.

[RalfJung]

Why are you packing these into closures?

[LorrensP-2158466]

posix_fallocate does the same and that was accepted and never changed (my pr).

I can remove both uses of closures.

[LorrensP-2158466]

split them up into 2 separate test functions. posix_fallocate is left untouched.

[RalfJung]

Yeah it is hard to apply consistent standards, especially in tests. ;)

But please just use comments or top-level functions for grouping here.

[LorrensP-2158466]

@rustbot ready

[RalfJung]

Yeah I like it :)
@rustbot author

View changes since this review

[LorrensP-2158466]

@RalfJung I have a feeling something is broken? When I try to fetch and rebase i get a merge conflict which seems easy to fix. Even though its weird i get a conflict in the first place since i didn't change anything in that file other than the rename of the io_error_to_errnum function.

And then when I fix that conflict i get the following:

~/oss/miri @41ba66fe9 rebase-i 7/7 ~1 +3 >> ./miri test --target i686-unknown-linux-gnu libc-fs.rs

error[E0425]: cannot find value `TooManyOpenFiles` in this scope
   --> src/shims/io_error.rs:105:20
    |
105 |         ("EMFILE", TooManyOpenFiles),
    |                    ^^^^^^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find value `TooManyOpenFiles` in this scope
   --> src/shims/io_error.rs:107:20
    |
107 |         ("ENFILE", TooManyOpenFiles),
    |                    ^^^^^^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find value `TooManyOpenFiles` in this scope
   --> src/shims/io_error.rs:262:39
    |
262 |         ("ERROR_TOO_MANY_OPEN_FILES", TooManyOpenFiles),
    |                                       ^^^^^^^^^^^^^^^^ not found in this scope

error[E0635]: unknown feature `io_error_too_many_open_files`
  --> src/lib.rs:21:37
   |
21 | #![cfg_attr(not(bootstrap), feature(io_error_too_many_open_files))]
   |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0769]: tuple variant `rustc_abi::BackendRepr::ScalarPair` written as struct variant
   --> src/shims/native_lib/mod.rs:316:33
    |
316 | ...                   let rustc_abi::BackendRepr::ScalarPair { a: _, b: _, b_offset } =
    |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
help: use the tuple variant pattern syntax instead
    |
316 -                             let rustc_abi::BackendRepr::ScalarPair { a: _, b: _, b_offset } =
316 +                             let rustc_abi::BackendRepr::ScalarPair(_, _) =
    |

I expect that these would be a conflict as well, but that is not the case?

[RalfJung]

Well, try pushing something that resolves the conflicts and we can see what happens. Did you remember to ./miri toolchain?

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[LorrensP-2158466]

Did you remember to ./miri toolchain

Oops... It has been some time 😅.

rebased to fix conflict and address second round of comments, @rustbot ready.

[RalfJung]

This looks great, thanks! Please squash the commits. You can squash manually if there are multiple independent commits you want to preserve, or use ./miri squash (make sure to pick a suitable commit message). Then write @rustbot ready after you force-pushed the squashed PR.

@rustbot author

[LorrensP-2158466]

1 commit is fine, I think. @rustbot ready