Implement blocking eventfd

[tiif]

This PR

• Implemented blocking for both read and write of eventfd
• Added test for eventfd blocking read and write
• Removed eventfd blocking tests from fail-dep
• Added a new BlockReason::Eventfd

cc #3665

[tiif]

@rustbot author

[tiif]

Hmm...why is rustfmt complaining? Let me try rebase it instead.

[oli-obk]

Suggested change

	let mut blocked_read_tid = self.blocked_read_tid.borrow_mut();
	*blocked_read_tid = Some(ecx.active_thread());
	*self.blocked_read_tid.borrow_mut() = Some(ecx.active_thread());

You can save yourself a lot of RefCell panic trouble by doing the entire op in one go and thus not keeping the lock for the rest of the function

[oli-obk]

Shouldn't this be a vec? Multiple threads could write and thus end up being blocked. Maybe add a test for that

[tiif]

Yea I missed that and that's indeed a possible case. Multithreaded case is a bit more complicated, I need more time to think about this, but this is the case I am considering:

If there are main thread + 2 additional threads:
let the counter be u64::max, so any write happened after will block.
2. thread1 try to write, and get blocked.
3. thread2 try to write, also get blocked.
4. Main thread read. Now, will thread1 and thread2 both get unblocked?

If both are unblocked, and thread1 is executed first. if thread1 write a u64::max again, thread2 should be blocked again. But the current implementation won't allow this to happen because thread2 is currently calling the unblock callback.

It also doesn't make sense to only unblock one thread, because the moment read happens, both thread1 and thread2 indeed can write.

I will check what actually happened in real system.

[tiif]

I think eventfd will unblock every thread at once. So something like this will happen:

If there are main thread + 2 additional threads:

1. let the counter be (u64::max - 1), so any write happened after will block.
2. thread1 try to write, and get blocked.
3. thread2 try to write, also get blocked.
4. main thread read, so all thread gets unblocked
5. thread1 unblocked and writes (u64::max - 1)
6. thread 2 unblocked and try to continue writing (u64::max - 1), it gets block again

So essentially, we need might need to check the counter value and continue to block the thread again in the blocking callback functions. I am not sure how we can approach this without overcomplicated it because if we need to block a thread multiple times, we might run into something like:

1. block_thread
2. in the blocking callback, block_thread
3. In the second block_thread callback, block_thread again
   ... and it continues

[RalfJung]

You can have a fn eventfd_write that blocks the thread if necessary, and in the "unblock" callback calls eventfd_write again. Recursion is a thing. :)

[tiif]

Yea, I think this will work. I feel this has an unfortunate consequence of making it more complex, but I couldn't see another solution for this.

[bors]

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

[tiif]

EDIT: Resolved, there is //@error-in-other-file: deadlock

@oli-obk When running /miri test eventfd_block_twice --bless, the error below is shown. Is there any way to annotate the error when the diagnostics occured outside the test file?

error: there were 1 unmatched diagnostics that occurred outside the testfile and had no pattern
    Error: deadlock: the evaluated program deadlocked

error: there were 1 unmatched diagnostics
 --> tests/fail-dep/libc/eventfd_block_twice.rs:1:1
  |
1 | //@only-target: linux
  | ^ Error: deadlock: the evaluated program deadlocked
  |

[tiif]

I couldn't think of a testcase that can actually produce thread id duplication in blocked_write/read_id, but I will just keep the dedup here first.

[tiif]

@rustbot ready