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.

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

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.