Disable rmake test inaccessible-temp-dir on riscv64

[Hoverbear]

In #126279 the inaccessible-temp-dir test was moved to rmake, I followed up with a 'fix' derived from #126355 in #126707.

That 'fix' was misguided and hiding the true issue of the linker being incorrect for riscv64gc-unknown-linux-gnu (addressed in #126916).

Unfortunately, even with the linker fixed, this test doesn't work. I asked myself why this appeared to work on other platforms and investigated why. Both the containers for armhf-gnu and riscv64gc run their tests as root and have NO_CHANGE_USER set:

rust/src/ci/docker/host-x86_64/disabled/riscv64gc-gnu/Dockerfile

Line 99 in 553a690

ENV NO_CHANGE_USER=1

This means the tests are run as root. As root, it's perfectly normal and reasonable to violate permission checks this way:

$ sudo mkdir scratch
$ sudo chmod o-w scratch
$ sudo mkdir scratch/backs
$

Because of this, this PR makes the test ignored on riscv64gc for now.

As an alternative, I believe the best long-term strategy would be to not run the tests as root for this job.

Testing

Note

riscv64gc-unknown-linux-gnu is a Tier 2 with Host Tools platform, all tests may not necessarily pass! This change should only ignore inaccessible-temp-dir and not affect other tests.

You can test out the job locally:

mv src/ci/docker/host-x86_64/disabled/riscv64gc-gnu src/ci/docker/host-x86_64/riscv64gc-gnu
DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-gnu

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
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

[rustbot]

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

[workingjubilee]

@Hoverbear does the test suite fail in CI if we run them as non-root?

[Hoverbear]

I'm glad you asked! I'm gonna find out. :)

[Hoverbear]

I did some investigation and here are some of the issues that pop up.

Commenting out this is fine:

rust/src/ci/docker/host-x86_64/disabled/riscv64gc-gnu/Dockerfile

Line 97 in 9b88232

ENV NO_CHANGE_USER=1

(You may need to remove the obj/ folder in the repo if you get weird errors.)

After that this line trips up with a permission error, that's relatively trivial to solve by making it rootfs/tmp/testd:

rust/src/tools/remote-test-client/src/main.rs

Line 109 in 9b88232

t!(fs::copy(server, rootfs.join("testd")));

Sadly the mkfs call here is the next to trip up, it wants to create a .pwd.lock in a readonly directory:

rust/src/tools/remote-test-client/src/main.rs

Lines 161 to 164 in 9b88232

	let mut mkfs = Command::new("mkfs.ext4");
	mkfs.arg("-d").arg(rootfs).arg(rootfs_img);
	let mut mkfs_child = t!(mkfs.spawn());
	assert!(t!(mkfs_child.wait()).success());

[TIMING] core::build_steps::tool::RemoteTestClient { compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu }, target: x86_64-unknown-linux-gnu } -- 0.061
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.23445 s, 870 MB/s
mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: done                            
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 9c29c0d6-f579-46a6-93a1-85535823300a
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (8192 blocks): done
Copying files into the device: do_write_internal: Permission denied while opening ".pwd.lock" to copy
__populate_fs: Permission denied while writing file ".pwd.lock"
mkfs.ext4: Permission denied while populating file system
thread 'main' panicked at src/tools/remote-test-client/src/main.rs:164:5:
assertion failed: t!(mkfs_child.wait()).success()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:11
  local time: Tue Jun 25 20:26:54 UTC 2024
  network time: Tue, 25 Jun 2024 20:26:57 GMT

Using a different workdirectory (since it's called pwd.lock) does not help, setting -e ignore to ignore errors does not allow progress either.

I guess the solution would be to stop using -d, however that opens a new set of problems since we then need to mount the filesystem and copy over the files manually. I guess that's not entirely different than what's done with arm-unknown-linux-gnueabihf though:

rust/src/tools/remote-test-client/src/main.rs

Lines 135 to 149 in 9b88232

	thread::spawn(move || add_files(&mut stdin, &rootfs, &rootfs));
	t!(io::copy(&mut child.stdout.take().unwrap(), &mut t!(File::create(&rootfs_img))));
	assert!(t!(child.wait()).success());
	fn add_files(w: &mut dyn Write, root: &Path, cur: &Path) {
	for entry in t!(cur.read_dir()) {
	let entry = t!(entry);
	let path = entry.path();
	let to_print = path.strip_prefix(root).unwrap();
	t!(write!(w, "{}\u{0}", to_print.to_str().unwrap()));
	if t!(entry.file_type()).is_dir() {
	add_files(w, root, &path);
	}
	}
	}

[workingjubilee]

....huh, weird.

[Hoverbear]

I realized I could temporarily hack around this by setting this to rw, just to see if there are other issues:

https://github.com/rust-lang/stdarch/blob/df3618d9f35165f4bc548114e511c49c29e1fd9b/ci/run-docker.sh#L35

This results in further issues:

mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: done                            
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: e43c16af-4e66-4156-b0c3-f98d8984d124
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

mount: /tmp/scratch: failed to setup loop device for /checkout/obj/build/tmp/rootfs.img.
thread 'main' panicked at src/tools/remote-test-client/src/main.rs:171:5:
assertion failed: t!(mount_child.wait()).success()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:14
  local time: Wed Jun 26 13:54:42 UTC 2024
  network time: Wed, 26 Jun 2024 13:54:45 GMT

Originating from:

rust/src/tools/remote-test-client/src/main.rs

Line 172 in 9b88232

match target {

Suffice it to say, I don't think this is a trivial enablement and it may be more suitable for a future PR which impacts both the riscv64-gnu and armhf-gnu targets.

[jieyouxu]

Thanks, I'm fine with ignoring this test for riscv64 for now. Could you convert the Reason into a FIXME? i.e. this is something we should eventually fix in the long term.

[jieyouxu]

r=me once you add a FIXME in the comment explaining the ignore. Maybe also include some of the steps you tried but did not work in the test comment (helpful for future person trying to enable this test for riscv64).

@bors delegate+

[bors]

✌️ @Hoverbear, you can now approve this pull request!

If @jieyouxu told you to "r=me" after making some further change, please make that change, then do @bors r=@jieyouxu

[jieyouxu]

@rustbot author

[bors]

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

[Hoverbear]

@bors r=@jieyouxu

[bors]

📌 Commit 8c353cb has been approved by jieyouxu

It is now in the queue for this repository.

[bors]

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.