[the8472]

View all comments

The workaround applies on kernels >= 6.9 according to the manpage.
It doesn't work on GHA runners, I suspect virtualization issues, maybe a faulty virtio implementation.
But both on my local machine and on the dev-desktop it works.

running test_append_write_at under strace:

strace: Process 460033 attached
[pid 460033] uname({sysname="Linux", nodename="dev-desktop-eu-1.infra.rust-lang.org", ...}) = 0
[pid 460033] openat(AT_FDCWD, "/tmp/rust-2231989334/file_test_append_write_at.txt", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3
[pid 460033] write(3, "it's not working!", 17) = 17
[pid 460033] openat(AT_FDCWD, "/tmp/rust-2231989334/file_test_append_write_at.txt", O_WRONLY|O_APPEND|O_CLOEXEC) = 3
[pid 460033] pwritev2(3, [{iov_base="   ", iov_len=3}], 1, 5, 0x20 /* RWF_??? */) = 3
[pid 460033] openat(AT_FDCWD, "/tmp/rust-2231989334/file_test_append_write_at.txt", O_RDONLY|O_CLOEXEC) = 4
[pid 460033] openat(AT_FDCWD, "/tmp/rust-2231989334", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_DIRECTORY) = 3
[pid 460033] +++ exited with 0 +++
[pid 460032] write(1, "{ \"type\": \"test\", \"name\": \"os::u"..., 92) = 92
[pid 460032] write(1, "{ \"type\": \"suite\", \"event\": \"ok\""..., 137) = 137
[pid 459907] write(1, ".", 1.)           = 1
[pid 459907] write(1, "\n", 1
)          = 1
[pid 459907] write(1, "\n", 1
)          = 1
[pid 459907] write(1, "test result: ok. 1 passed; 0 fai"..., 101test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 477 filtered out; finished in 794.28µs

partially addresses #140867

[rustbot]

r? @thomcc

rustbot has assigned @thomcc.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[the8472]

Weird, the kernel should be new enough.

[bors]

☔ The latest upstream changes (presumably #143294) made this pull request unmergeable. Please resolve the merge conflicts.

[the8472]

At this point I'm fairly sure this is a kernel bug in the runner. Tests pass locally, the pwritev2 also happens in CI and doesn't return an error, meaning the flag should be supported.

Filed actions/runner-images#12530

[rustbot]

Any special-casing of Miri in the standard library requires review.

cc @rust-lang/miri

[rustbot]

This PR was rebased onto a different main 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.

[RalfJung]

somewhat fixes #140867

GH will close that issue if this PR gets merged. Is that intentional, for a "somewhat" fix?

[RalfJung]

No, skip_missing_miri_shims is for tests only.

View changes since the review

[RalfJung]

You can add a SYS_pwritev2 case around here, making it always return ENOSYS to make Miri go through the fallback path.

EDIT: Or we can wait for rust-lang/miri#5602 to sync, then this should just work in Miri. (Miri will probably still be affected by the bug, but that is a separate issue.)

[the8472]

GH will close that issue if this PR gets merged. Is that intentional, for a "somewhat" fix?

Well it does our part but yeah it specifically mentions GHA so I guess we should leave it open.

[RalfJung]

We should probably file this as an issue with GHA that the flag does not work. That's a pretty clear violation of the documented behavior.

[the8472]

Filed one previously but those shifted responsibility to the ubuntu kernel. Canonical has been unresponsive to the bug I filed there.
considering this now spans multiple ubuntu releases, here's a new one: actions/runner-images#15277

[rust-bors]

☔ The latest upstream changes (presumably #165793) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[RalfJung]

It has been synced, so after a rebase this branch can be removed.

View changes since the review

[thomcc]

r=me once the miri fixes are in.

[the8472]

I'll have to update the test conditions again, turns out the the root cause is in overlayfs (used by docker) and not azure-specific.

https://lore.kernel.org/linux-unionfs/CAOQ4uxjEQMgLq=LFzpb5K20hgoHWXjyTxRQWs-qTPFym9p-jww@mail.gmail.com/T/#t