epoll: handle edge case for epoll_ctl

[tiif]

There is a test case that revealed that our implementation differs from the real system:

• Set up an epoll watching the FD
• Call epoll_wait
• Set up another epoll watching the same FD
• Call epoll_wait on the first epoll. Nothing should be reported!

This happened because, in epoll_ctl, we used check_and_update_readiness, which is a function that would return notification for all epoll file description that registered a particular file description. But we shouldn't do that because no notification should be returned if there is no I/O activity between two epoll_wait (every first epoll_wait that happens after epoll_ctl is an exception, we should return notification that reflects the readiness of file description).

r? @oli-obk

[tiif]

Is there a better name to differentiate this function from check_and_update_readiness? They essentially do the same thing, but this function only checks one epoll_event_interest, where check_and_update_readiness checks all epoll_event_interest. As a result, this function can only return notification to one epoll instance where check_and_update_readiness can return notification to multiple epoll instances.

EDIT: currently named it as check_and_update_one_event_interest

[RalfJung]

Previously, in epoll_ctl, we used check_and_update_readiness, which is a function that would return notification for all epoll file description. But we shouldn't do that because no notification should be returned if there is no I/O activity between two epoll_wait.

I am confused by this description. There's only one epoll_wait in the first sentence so the second sentence seems to talk about a different case?

Looking at the testcase I think I understand now, but the PR description doesn't explain the problem. The problem is

• Set up an epoll watching the FD
• Call epoll_wait
• Set up another epoll watching the same FD
• Call epoll_wait on the first epoll. Nothing should be reported!

[tiif]

@rustbot author

[tiif]

@rustbot ready

[oli-obk]

@bors r+

[bors]

📌 Commit dbe9199 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

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

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout edgecase (switch to your branch)
2. git fetch upstream master (retrieve the latest master)
3. git rebase upstream/master -p (rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self edgecase --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging tests/pass-dep/libc/libc-epoll.rs
CONFLICT (content): Merge conflict in tests/pass-dep/libc/libc-epoll.rs
Auto-merging src/shims/unix/linux/epoll.rs
Automatic merge failed; fix conflicts and then commit the result.

[tiif]

Rebased and CI is green.

r? @oli-obk

[oli-obk]

@bors r+

[bors]

📌 Commit 830d679 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit 830d679 with merge 242df69...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 242df69 to master...