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

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

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

From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: port-hppa-maintainer%netbsd.org@localhost
Subject: Re: port-sparc/56788 Rump kernel panic: kernel diagnostic assertion "old == LOCK_LOCKED" failed
Date: Fri, 17 Jun 2022 19:47:37 -0400

 ... BTW, I now believe that this same issue affects a number of
 other test cases that have been unstable for me, including
 
 net/if_gif/t_gif:gif_basic_ipv6overipv6
 net/if_ipsec/t_ipsec:ipsecif_recursive_ipv6overipv4_esp_null
 net/if_lagg/t_lagg:lagg_lacp_vlan_ipv6
 net/if_lagg/t_lagg:lagg_lacp_vlanl2tp_ipv6
 net/if_wg/t_basic:wg_basic_ipv6_over_ipv6
 net/if_wg/t_basic:wg_payload_sizes_ipv4_over_ipv4
 net/if_wg/t_basic:wg_payload_sizes_ipv6_over_ipv6
 net/if_wg/t_tunnel:wg_tunnel_ipv6_over_ipv4
 net/mpls/t_ldp_regen:ldp_regen
 
 I see some of these also failing in the ARMv5 tests at
 https://www.netbsd.org/~martin/evbarm-atf/
 which is very likely the same issue given that old ARM is
 one of the affected arches.
 
 Maybe there's enough test cases here to justify a messy solution?
 I'm wondering about arranging for atomic_cas_generic.c's spinlock
 array to be kept in shared memory somehow.
 
 			regards, tom lane