re: port-sparc/56788 Rump kernel panic: kernel diagnostic assertion "old == LOCK_LOCKED" failed

[matthew green <mrg%eterna.com.au@localhost>]

The following reply was made to PR port-sparc/56788; it has been noted by GNATS.

From: matthew green <mrg%eterna.com.au@localhost>
To: gnats-bugs%netbsd.org@localhost, tgl%sss.pgh.pa.us@localhost
Cc: port-sparc-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
    netbsd-bugs%netbsd.org@localhost, gson%gson.org@localhost (Andreas Gustafsson)
Subject: re: port-sparc/56788 Rump kernel panic: kernel diagnostic assertion "old == LOCK_LOCKED" failed
Date: Sat, 18 Jun 2022 13:33:35 +1000

 nice work Tom.
 
 >  It's striking though that SPARC is not in this list.  Perhaps
 >  it has some related failure mechanism?  I see that
 >  src/common/lib/libc/arch/sparc/atomic/atomic_cas.S
 >  makes use of a "locktab array" that looks like it'd have the
 >  same problem of being process-local, but I am not sure if that
 >  code is used in a rump kernel, or whether it applies to the
 >  SPARC variant being complained of here.
 
 yeah - sparc uses a similar mechanism last i looked at this,
 and tried to figured out why rump_server and more would not
 exit on sparc, and it always came down to mutexes not working
 like you're described here, but i didn't think about shared
 process spaces not being shared now.
 
 we knew this was a problem with some code bases (eg, related
 to shared futexes), but i did not know this was used by our
 own code/tests.
 
 
 .mrg.