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
F86832802: D31238.id92559.diff
Wed, Jun 26, 6:43 AM
Unknown Object (File)
Mon, Jun 24, 3:35 PM
Unknown Object (File)
Mon, Jun 24, 10:21 AM
Unknown Object (File)
Mon, Jun 24, 8:22 AM
Unknown Object (File)
Mon, Jun 24, 7:32 AM
Unknown Object (File)
Mon, Jun 24, 3:44 AM
Unknown Object (File)
Fri, Jun 21, 10:33 PM
Unknown Object (File)
May 26 2024, 3:00 PM
Subscribers

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 40589
Build 37478: arc lint + arc unit

Event Timeline

sys/kern/kern_umtx.c
1725

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
1732

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
1730

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 ))