Page MenuHomeFreeBSD

umtx: Split do_unlock_pi on two counterparts.
ClosedPublic

Authored by dchagin on Jul 20 2021, 2:14 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 6, 1:43 PM
Unknown Object (File)
Sun, Nov 3, 11:12 PM
Unknown Object (File)
Fri, Nov 1, 11:26 AM
Unknown Object (File)
Fri, Oct 25, 4:12 PM
Unknown Object (File)
Wed, Oct 23, 8:55 PM
Unknown Object (File)
Oct 5 2024, 4:08 AM
Unknown Object (File)
Oct 3 2024, 6:02 AM
Unknown Object (File)
Oct 1 2024, 10:11 PM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sys/kern/kern_umtx.c
2100

If exposing such function as the generic KPI, we should assert there that key is locked and busy. For that, you need to add corresponding primitives.

sys/kern/kern_umtx.c
2107

Shouldn't #endif go before this line? Otherwise uc is not defined.

It might be better to define some helper e.g. UMTXQ_ASSERT_LOCKED_BUSY(key) and expand it into block as you write for INVARIANTS, otherwise keep it empty.

done,
sleep_pi may be should refactored to use this macros

sys/kern/kern_umtx.c
2105

No, pass the key to UMTXQ_LOCKED_ASSERT_BUSY(), so that the INVARIANTS block above is not needed.

sys/kern/kern_umtx.c
93

arg should be key and not uc

99

This is better, but please do

#ifdef INVARIANTS
#define UMTXQ_ASSERT_LOCKED_BUSY(key) <your definition>
#else 
#define UMTXQ_ASSERT_LOCKED_BUSY(key) do {} while (0)
#endif

So that uc is not calculated for !INVARIANTS case. Also note a suggested name change

sys/kern/kern_umtx.c
94

UMTXQ_ASSERT_LOCKED_BUSY

done,
UMTXQ_LOCKED_ASSERT?

UMTXQ_LOCKED_ASSERT?

Are you suggesting to call UMTXQ_ASSERT_LOCKED_BUSY() by UMTXQ_LOCKED_ASSERT() instead? The assert does both lock and busy checks, so IMO the longer name is more correct.

This revision is now accepted and ready to land.Jul 21 2021, 10:10 PM
In D31238#704112, @kib wrote:

UMTXQ_LOCKED_ASSERT?

Are you suggesting to call UMTXQ_ASSERT_LOCKED_BUSY() by UMTXQ_LOCKED_ASSERT() instead? The assert does both lock and busy checks, so IMO the longer name is more correct.

no, I prefer to follow to the same style in code, naming, etc, that's why i named the macro like UMTXQ_LOCKED_ASSERT_BUSY. Thank you for your patience ))