Page MenuHomeFreeBSD

Only handle robust mutexes and sigfastblock on exec and exit for native FreeBSD ABIs
ClosedPublic

Authored by kib on Jul 1 2021, 6:14 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 8, 7:35 PM
Unknown Object (File)
Thu, Mar 7, 8:32 PM
Unknown Object (File)
Jan 15 2024, 6:22 PM
Unknown Object (File)
Dec 23 2023, 12:13 AM
Unknown Object (File)
Dec 12 2023, 12:13 PM
Unknown Object (File)
Dec 10 2023, 3:37 AM
Unknown Object (File)
Sep 21 2023, 5:53 AM
Unknown Object (File)
Sep 20 2023, 3:04 AM
Subscribers
None

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

kib requested review of this revision.Jul 1 2021, 6:14 PM
kib created this revision.

it would be nice to eliminate umtx_thread_exit() call from linux_exit().
I'm AFK till monday, went to pick up the boat after repair, so im ok with the proposed change

No need to call umtx_cleanup_thread() from cloudabi/linux thread exit syscalls either

This revision is now accepted and ready to land.Jul 5 2021, 8:05 AM

Looks ok, but why? Now in the native case we converted direct function calls to an indirect call, but umtx and sigfastblock already do nothing in the !native case.

Looks ok, but why? Now in the native case we converted direct function calls to an indirect call, but umtx and sigfastblock already do nothing in the !native case.

It was requested by dchagin. Obvious but vague reason is to not call freebsd-abi specific methods on other ABIs. But my guess is that linuxolator would get robust mutexes rework that might reuse parts of native code, including the structures pointed from struct thread. Then calling freebsd-native directly would be problematic.

In D30987#698405, @kib wrote:

Looks ok, but why? Now in the native case we converted direct function calls to an indirect call, but umtx and sigfastblock already do nothing in the !native case.

It was requested by dchagin. Obvious but vague reason is to not call freebsd-abi specific methods on other ABIs. But my guess is that linuxolator would get robust mutexes rework that might reuse parts of native code, including the structures pointed from struct thread. Then calling freebsd-native directly would be problematic.

It makes some sense to hide sigfastblock this way, but umtx is not really tied to any particular ABI as I understand it. So it feels to me that the umtx code should internally handle any extensions required to support the futex implementation. Probably I'm just quibbling.

In D30987#698405, @kib wrote:

Looks ok, but why? Now in the native case we converted direct function calls to an indirect call, but umtx and sigfastblock already do nothing in the !native case.

It was requested by dchagin. Obvious but vague reason is to not call freebsd-abi specific methods on other ABIs. But my guess is that linuxolator would get robust mutexes rework that might reuse parts of native code, including the structures pointed from struct thread. Then calling freebsd-native directly would be problematic.

It makes some sense to hide sigfastblock this way, but umtx is not really tied to any particular ABI as I understand it. So it feels to me that the umtx code should internally handle any extensions required to support the futex implementation. Probably I'm just quibbling.

IMO umtx is very FreeBSD-specific. But I wonder what Dmitry would end up with.

In D30987#698633, @kib wrote:
In D30987#698405, @kib wrote:

Looks ok, but why? Now in the native case we converted direct function calls to an indirect call, but umtx and sigfastblock already do nothing in the !native case.

It was requested by dchagin. Obvious but vague reason is to not call freebsd-abi specific methods on other ABIs. But my guess is that linuxolator would get robust mutexes rework that might reuse parts of native code, including the structures pointed from struct thread. Then calling freebsd-native directly would be problematic.

It makes some sense to hide sigfastblock this way, but umtx is not really tied to any particular ABI as I understand it. So it feels to me that the umtx code should internally handle any extensions required to support the futex implementation. Probably I'm just quibbling.

IMO umtx is very FreeBSD-specific. But I wonder what Dmitry would end up with.

well, for now I rewrote the futex code with umtx and started writing new pi code.