Abort a process when FD ownership is violated

[the8472]

When an owned FD has already been closed before it's dropped that means something else touched an FD in ways it is not allowed to. At that point things can already be arbitrarily bad, e.g. clobbered mmaps. Recovery is not possible.
All we can do is hasten the fire.

Unlike the previous attempt in #124130 this shouldn't suffer from the possibility that FUSE filesystems can return arbitrary errors.

[rustbot]

r? @jhpratt

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

[jhpratt]

r? libs

[RalfJung]

This is only applied in debug builds of std since assert_unsafe_precondition! isn't available outside core.

That comment seems outdated now? At least, this is using the ub_checks macro now, so it will honor -Zub-checks just like assert_unsafe_precondition!

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 072c32d has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[workingjubilee]

Died in rollup: #124452 (comment)

@bors r-

[tamird]

Happy to. Should I do that in the miri repo?

Depends on whether you need something changed in Miri or the standard library.

I suppose it would be in the standard library.

But if a Miri magic function to "create null FD" would be helpful, then a Miri issue sounds good. I don't quite understand how it helps or why the problem only arises under Miri, but adding such a function should be trivial so maybe I don't have to understand everything. ;)

The problem only arises under miri because otherwise we're using a standard library compiled without debug assertions.

After thinking about this for a while our use case is sufficiently niche that doing anything about it in the standard library or Miri doesn't make sense. Thanks for humoring me!

[saethlin]

because otherwise we're using a standard library compiled without debug assertions.

This check is based on intrinsics::ub_checks, so that shouldn't matter.

[tamird]

because otherwise we're using a standard library compiled without debug assertions.

This check is based on intrinsics::ub_checks, so that shouldn't matter.

huh?

rust/library/std/src/sys/pal/unix/fs.rs

Line 845 in a8773d5

if core::ub_checks::check_library_ub() {

->

rust/library/core/src/ub_checks.rs

Line 86 in a8773d5

pub use intrinsics::ub_checks as check_library_ub;

->

rust/library/core/src/intrinsics.rs

Lines 2721 to 2723 in a8773d5

	pub const fn ub_checks() -> bool {
	cfg!(debug_assertions)
	}

what am I missing?

[RalfJung]

You're missing the line you cut off here:

rust/library/core/src/intrinsics.rs

Lines 2720 to 2723 in a8773d5

	#[rustc_intrinsic]
	pub const fn ub_checks() -> bool {
	cfg!(debug_assertions)
	}

This is an intrinsic, the body is just the fallback when codegen backends don't overwrite it.

Our backends do overwrite it, using the value of -Cdebug-assertions at codegen time.

[tamird]

Oh, this probably is not specific to miri - it's just that we use nightly to run miri and stable otherwise, and this change hasn't yet hit stable. Does that sound right to you?

[saethlin]

The first work on ub_checks just hit stable today, actually. Perfect timing.

This PR of course won't be on stable until 1.80 releases. Each PR is automatically attached to a GitHub milestone so you can see when it will hit stable.