Keep epoll interest alive while a duplicate of the registered fd survives

[Will Portnoy (willportnoy)]

Problem

Linux epoll(7) removes a descriptor from an interest list only after every descriptor referring to the underlying open file description (OFD) has been closed. The shim instead anchored each interest to the per-descriptor TypedFd, so closing the registered descriptor dropped the interest even when a dup referring to the same OFD was still open — EpollEntry::poll bailed on a dead Weak<TypedFd> and readiness was never delivered.

Fix

Anchor epoll interest to the open file description:

• Add WeakEntryHandle to litebox::fd — a durable, dup-surviving weak reference to a descriptor's shared entry, plus EntryHandle::downgrade/as_ptr/with_shared_metadata.
• Re-point epoll's DescriptorRef at a per-subsystem WeakEntryHandle, key interests by the OFD's stable address, and re-poll through the shared entry (eventfd/unix/pipe via the entry's IOPollable, socket/file via aliased metadata). Observer registration is unchanged; it already targets the shared pollable.
• Expose with_iopollable on the pipe entry so a pipe can be polled without a live per-descriptor PipeFd.

Covers all six epoll-able fd types on main (eventfd, unix, pipe, socket, file, and the pre-existing epoll-on-epoll unimplemented!()), via exhaustive matches.

Test

tests/epoll_dup.c: register an eventfd, dup it, close the original, and verify the interest still delivers events and survives re-arming. Passes natively, fails without this change under Litebox, and passes with it.

[Weiteng Chen (CvvT)]

One subtle issue with this lies on

litebox/litebox/src/fd/mod.rs

Lines 133 to 153 in e18e65a

	pub(crate) fn close_and_duplicate_if_shared<
	Subsystem: FdEnabledSubsystem,
	F: FnOnce(&Subsystem::Entry) -> bool,
	>(
	&mut self,
	fd: &TypedFd<Subsystem>,
	can_close_immediately: F,
	) -> Option<CloseResult<Subsystem>> {
	let idx = fd.x.as_usize()?;
	let Some(old) = self.entries[idx].take() else {
	unreachable!();
	};
	if Arc::strong_count(&old.x) == 1 {
	// Unique, so we can just return it if allowed.
	if can_close_immediately(old.x.entry.read().as_subsystem::<Subsystem>()) {
	fd.x.mark_as_closed();
	let entry = Arc::into_inner(old.x)
	.map(|shared| RwLock::into_inner(shared.entry))
	.map(DescriptorEntry::into_subsystem_entry::<Subsystem>)
	.unwrap();
	Some(CloseResult::Closed(entry))

Now Arc::into_inner(old.x)...unwrap() may panic. Closing a socket cannot be done simply via Drop. It needs to take the ownership of the entry. One potential fix suggested by copilot is to replace it with Arc::try_unwrap and return CloseResult::Duplicated on the error path.

[Will Portnoy (willportnoy)]

AI-authored, human-reviewed.

Good catch — fixed in fb43794. You're right the Arc::strong_count == 1 check followed by Arc::into_inner(...).unwrap() is racy now: a WeakEntryHandle::upgrade() (which this PR newly lets epoll interests do) runs lock-free, so it can transiently bump the strong count between the check and the unwrap and panic it.

Switched to Arc::try_unwrap; on the error path it puts the entry back and returns CloseResult::Duplicated, so the descriptor is closed once the transient reference drops — the same self-healing queued-closure path already taken when the entry is genuinely shared.

I also checked the sibling remove(): it uses Arc::into_inner(...).map(...) (no unwrap), and its socket callers discard the entry via let _ =, so there's no analogous panic or orderly-close regression there.

[github-actions]

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.