Page MenuHomeFreeBSD

linuxulator: Add FUTEX_REQUEUE for musl libc.
ClosedPublic

Authored by pitwuu_gmail.com on May 18 2021, 2:15 PM.

Details

Summary

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.

Test Plan

Tested on void linux chroot with x64.
With this patch, Qt applications enter and exit cleanly.

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

pitwuu_gmail.com created this revision.

Im don't understand what do you mean, I mean that musl it's a separate brand, see Elf_Brandinfo and linux_sysvec.c,
and only for musl brand we should change cmp_requeue, for glibc brand cmp_requeue should return EINVAL

sys/compat/linux/linux_futex.c
692

I think that comment is not needed here

Im don't understand what do you mean, I mean that musl it's a separate brand, see Elf_Brandinfo and linux_sysvec.c,
and only for musl brand we should change cmp_requeue, for glibc brand cmp_requeue should return EINVAL

Well. No. Musl doesn't have different brands for the elf files, only the path of the interp differs, and in any case we are a Linuxulator, not a glibculator, it's better to just remain agnostic of the userland and let it sort itself out like is expected of the kernel.

If there's a quirk for some ancient glibc version then make that a knob somewhere or break it in favour of modern (read from this decade) versions.

Im don't understand what do you mean, I mean that musl it's a separate brand, see Elf_Brandinfo and linux_sysvec.c,
and only for musl brand we should change cmp_requeue, for glibc brand cmp_requeue should return EINVAL

Well. No. Musl doesn't have different brands for the elf files, only the path of the interp differs, and in any case we are a Linuxulator, not a glibculator, it's better to just remain agnostic of the userland and let it sort itself out like is expected of the kernel.

If there's a quirk for some ancient glibc version then make that a knob somewhere or break it in favour of modern (read from this decade) versions.

I do not object to commit, I'm just saying that the FUTEX_REQUEUE is broken, and I would like to protect everyone except musl from using it.
Good method is check Brandinfo, but it is not easy as it seemed at first glance, as our struct sysentvec does not have ptr to Brandinfo.
I checked the glibc code, it no longer uses FUTEX_REQUEUE, so I propose to commit first version of patch.

This revision was not accepted when it landed; it landed in state Needs Review.Tue, Jul 20, 11:42 AM
This revision was automatically updated to reflect the committed changes.