Skip to content

Enable epoll_pwait2 only when the syscall is available #80060

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
michaelrj-google opened this issue Jan 30, 2024 · 5 comments
Open

Enable epoll_pwait2 only when the syscall is available #80060

michaelrj-google opened this issue Jan 30, 2024 · 5 comments
Assignees
Labels

Comments

@michaelrj-google
Copy link
Contributor

Had to be disabled here: #80051

We should enable it on systems that have the syscall, perhaps put this into excludes along with a compile check?

@llvmbot
Copy link
Member

llvmbot commented Jan 30, 2024

@llvm/issue-subscribers-libc

Author: None (michaelrj-google)

Had to be disabled here: https://github.com//pull/80051

We should enable it on systems that have the syscall, perhaps put this into excludes along with a compile check?

@michaelrj-google
Copy link
Contributor Author

Adding additional context: The epoll_pwait2 syscall was added in linux 5.11 and is unavailable on some of the buildbots. It should stay disabled until all of the buildbots support it.

michaelrj-google added a commit to michaelrj-google/llvm-project that referenced this issue Jul 22, 2024
This patch reverts llvm#99781 and part of llvm#99771 since `epoll_pwait2` is not
in fact available on all supported systems. It is my opinion that we
shouldn't provide a version of a function that doesn't perform as
expected, which is why this revert needs to happen.

The `epoll_pwait2` function can be reenabled when we have a way to check
if it is available on the target system, tracking bug for that is llvm#80060
michaelrj-google added a commit that referenced this issue Jul 22, 2024
This patch reverts #99781 and part of #99771 since `epoll_pwait2` is not
in fact available on all supported systems. It is my opinion that we
shouldn't provide a version of a function that doesn't perform as
expected, which is why this revert needs to happen.

The `epoll_pwait2` function can be reenabled when we have a way to check
if it is available on the target system, tracking bug for that is #80060
yuxuanchen1997 pushed a commit that referenced this issue Jul 25, 2024
This patch reverts #99781 and part of #99771 since `epoll_pwait2` is not
in fact available on all supported systems. It is my opinion that we
shouldn't provide a version of a function that doesn't perform as
expected, which is why this revert needs to happen.

The `epoll_pwait2` function can be reenabled when we have a way to check
if it is available on the target system, tracking bug for that is #80060
@nickdesaulniers
Copy link
Member

Wont the kernel fail with -ENOSYS if the syscall is unsupported? So I think we should unconditionally provide a decl+def of epoll_pwait2. On pre-5.11 kernels, our wrapper will simply bubble up the ENOSYS from the kernel. On 5.11+, it should work fine.

@nickdesaulniers
Copy link
Member

And the unit tests should handle the ENOSYS case.

@michaelrj-google
Copy link
Contributor Author

The kernel should fail with -ENOSYS of we call a syscall that isn't available, and detecting that and passing the unit tests should be straightforward. The problem is mostly with building, since if the syscall number isn't defined by the headers we currently don't have a way to determine it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants