Complete and fix our eventfd implementation

[RalfJung]

eventfd is documented reasonably well in its man page. The current implementation in Miri is incomplete, doesn't have tests (it is only indirect exercised via the tokio MVP test but that's not a good way to test a specific low-level API), and is partially wrong.

It is incomplete in that read is not implemented, which means they can't actually be used to do anything.
That's also where EFD_NONBLOCK would come in.

It is partially wrong in that

• write panics in all sorts of situations that should be handled gracefully
• dup creates a new independent event object, rather than a second FD that refers to the same event object (this got fixed in the mean time)

Work on this should IMO follow the proposed "project" process.

[RalfJung]

Also the check here is bogus:

miri/src/shims/unix/linux/eventfd.rs

Lines 109 to 111 in 99be2b7

	if flags & (efd_cloexec | efd_nonblock | efd_semaphore) == 0 {
	throw_unsup_format!("{flags} is unsupported");
	}

That should be flags & !(efd_cloexec | efd_nonblock | efd_semaphore) != 0.

EDIT: but turns out we have the flags tokio needs.

[RalfJung]

dup creates a new independent event object, rather than a second FD that refers to the same event object

This should probably be fixed by implementing a proper notion of "file description", and making the file descriptor table a simple indirection for file descriptions. That would fix dup for all FDs once and for all, and it will anyway be needed for epoll.

[m-rph]

Hey @RalfJung I would like to give this a shot. May I just @rustbot claim it?

[RalfJung]

Please coordinate with @oli-obk -- I saw something about a potential GSoC project for epoll support, and I assume this would be part of it.

[oli-obk]

cc @tiif

There's probably some parallel development that can be done, but the file descriptor table refactor is likely gonna block other work, so the earlier it is done the better.

[m-rph]

I think it's probably for the best if I pick something simpler and isolated to start with.
Thank you!

[tiif]

@rustbot claim