Page MenuHomeFreeBSD

_umtx_op: final touches (manpage / libsysdecode / truss / kdump)
ClosedPublic

Authored by kevans on Nov 23 2020, 1:40 AM.
Tags
None
Referenced Files
F83727978: D27325.id79874.diff
Tue, May 14, 2:20 AM
Unknown Object (File)
Fri, May 3, 3:12 PM
Unknown Object (File)
Wed, May 1, 10:42 AM
Unknown Object (File)
Feb 22 2024, 10:28 AM
Unknown Object (File)
Dec 20 2023, 4:42 AM
Unknown Object (File)
Jul 28 2023, 12:35 AM
Unknown Object (File)
Jul 1 2023, 4:50 PM
Unknown Object (File)
Jun 28 2023, 10:29 AM
Subscribers

Details

Summary

(These weren't necessarily large enough on their own to split out, but I can commit them separately)

  • Document the new flags for _umtx_op(2)
  • Teach libsysdecode about them -- flags use a double underbar after UMTX_OP, command use a single.
  • Support decoding in kdump -- print the flag bits first, then the command
  • Same with truss
Test Plan

Observe the output:

ktrace:

root@viper:~/qemu-bsd-user/arm-bsd-user# kdump | grep -i -- _umtx_op | head -5
  2286 qemu-arm CALL  _umtx_op(0x7fffffffe8f0,0x3<UMTX_OP_WAKE>,0x1,0,0)
  2286 qemu-arm RET   _umtx_op 0
  2286 qemu-arm CALL  _umtx_op(0x8605f7008,0xf<UMTX_OP_WAIT_UINT_PRIVATE>,0,0,0)
  2286 qemu-arm CALL  _umtx_op(0x9fffdce8,0x80000003<UMTX_OP__32BIT|UMTX_OP_WAKE>,0x1,0,0)
  2286 qemu-arm RET   _umtx_op 0

These first two calls were indeed pure native ops, and I think this is still sensible looking.

truss samples:

10039 100540: _umtx_op(0x7fffffffda50,UMTX_OP_WAKE,0x1,0x0,0x0) = 0 (0x0)           
10057 100905: _umtx_op(0x9fffdd08,UMTX_OP__32BIT|UMTX_OP_WAKE,0x1,0x0,0x0) = 0 (0x0)

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

lib/libc/sys/_umtx_op.2
1284 ↗(On Diff #79874)

I do not think it is enough to say that. You need to really explain what does it mean.

  • Enumerate the exact implications of the new compat flags
  • Note the behavior with robust lists

I realized as I was writing this that I've done a terrible thing with robust lists. It returns EBUSY, but libthr will ignore the return value. Moreover, I can't see much room in the spec for this to fail.

This is slightly mitigated by the facts that we won't do robust list init until a robust mutex is entered or initialized, that these are on a per-thread basis, and the new flags are only/mostly useful for emulation.

For the last point, we could probably emphasize that the emulator must check the error from UMTX_OP_ROBUST_LISTS and do the needful, whatever that means.

You can make mutex_init_robust() either issue a message, or abort() in case of _umtx_op() returning error.

This revision is now accepted and ready to land.Nov 24 2020, 12:34 PM
This revision was automatically updated to reflect the committed changes.