Summary: | linuxulator: Add FUTEX_REQUEUE for musl libc. | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | pitwuu | ||||
Component: | kern | Assignee: | Dmitry Chagin <dchagin> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | dchagin, emaste | ||||
Priority: | --- | ||||||
Version: | Unspecified | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 247219 | ||||||
Attachments: |
|
In my TODO list is to move patches to the Phabricator, including this issue here. Comment on attachment 225031 [details]
futex requeue patch
Moved comment likely requires updating:
+ * Glibc versions prior to 2.3.3 fall back to FUTEX_WAKE when
+ * FUTEX_REQUEUE returned EINVAL.
This is true, but not so relevant now as we're not going to return EINVAL?
Should I then get rid of all these comments, and the warning flag "LINUX_XDEPR_REQUEUEOP" as well? In my POV this should be fixed in musl instead of using the broken feature, or, at least, you can add flag to the brandinfo and check it. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=cf8d74e3fe63da7359d6ca7e0b4b57c5684c2845 commit cf8d74e3fe63da7359d6ca7e0b4b57c5684c2845 Author: Dmitry Chagin <dchagin@FreeBSD.org> AuthorDate: 2021-07-20 11:39:20 +0000 Commit: Dmitry Chagin <dchagin@FreeBSD.org> CommitDate: 2021-07-20 11:39:20 +0000 linux(4): Allow musl brand to use FUTEX_REQUEUE op. Initial patch from submitter was adapted by me to prevent unconditional FUTEX_REQUEUE use. PR: 255947 Submitted by: Philippe Michaud-Boudreault Differential Revision: https://reviews.freebsd.org/D30332 sys/amd64/linux/linux_sysvec.c | 3 ++- sys/amd64/linux32/linux32_sysvec.c | 3 ++- sys/compat/linux/linux.h | 5 ++++ sys/compat/linux/linux_futex.c | 49 +++++++++++++++++++++++++------------- sys/i386/linux/linux_sysvec.c | 3 ++- 5 files changed, 43 insertions(+), 20 deletions(-) I don't plan to MFC this A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6698c1a28d09b58fbb0921ec727b9917fd5d2b7a commit 6698c1a28d09b58fbb0921ec727b9917fd5d2b7a Author: Dmitry Chagin <dchagin@FreeBSD.org> AuthorDate: 2021-07-20 11:39:20 +0000 Commit: Dmitry Chagin <dchagin@FreeBSD.org> CommitDate: 2022-06-17 19:33:12 +0000 linux(4): Allow musl brand to use FUTEX_REQUEUE op. Initial patch from submitter was adapted by me to prevent unconditional FUTEX_REQUEUE use. PR: 255947 Submitted by: Philippe Michaud-Boudreault Differential Revision: https://reviews.freebsd.org/D30332 (cherry picked from commit cf8d74e3fe63da7359d6ca7e0b4b57c5684c2845) sys/amd64/linux/linux_sysvec.c | 3 ++- sys/amd64/linux32/linux32_sysvec.c | 3 ++- sys/compat/linux/linux.h | 5 ++++ sys/compat/linux/linux_futex.c | 49 +++++++++++++++++++++++++------------- sys/i386/linux/linux_sysvec.c | 3 ++- 5 files changed, 43 insertions(+), 20 deletions(-) |
Created attachment 225031 [details] futex requeue patch The comment about FUTEX_REQUEUE is true, however musl libc makes uses of this operation, and so I want to add support for it as there is legitimate use of FUTEX_REQUEUE. The call itself is per the documentation the same as FUTEX_CMD_REQUEUE except that the val3 is not checked. Tested on void linux chroot with x64. With this patch, Qt applications enter and exit cleanly.