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

Authored by kib on Jul 1 2021, 6:14 PM.

Details

Reviewers

dchagin
markj

Commits

rG747a6b7ace3d: cloudabi and linux ABIs: do not call umtx_thread_cleanup() from thr_exit syscall
rG28a66fc3da34: Do not call FreeBSD-ABI specific code for all ABIs
rG55976ce11a10: Move sv_onexit() sysentvec hook slightly later
rG71ab344524a1: Add sv_onexec_old() sysent hook for exec event

Summary

[!amd64 will follow later]

Requested by: dchagin

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

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

thanks!

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.

In D30987#698336, @markj 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.

In D30987#698405, @kib wrote:

In D30987#698336, @markj 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#698526, @markj wrote:

In D30987#698405, @kib wrote:

In D30987#698336, @markj 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#698526, @markj wrote:

In D30987#698405, @kib wrote:

In D30987#698336, @markj 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.