Re: pthread_spin_unlock and ownership behaviour

2020-10-03 Thread Theo de Raadt
> For shits and giggles I deceided to look into pthread_spin_unlock and > saw that we return EPERM here, while POSIX states that this behaviour > is unconditionally undefined.[0] Is there a reason why we shouldn't > abort here as well? Undefined doesn't mean it can turn into a bowl of petunias. A

Re: pthread_spin_unlock and ownership behaviour

2020-10-03 Thread Stuart Henderson
Ports-wise, from a Nov 2019 build on i386, these used it: $ grep -Rl pthread_spin_unlock wrkscan wrkscan/devel/libivykis wrkscan/x11/gnustep/base wrkscan/x11/e17/eina wrkscan/misc/posixtestsuite wrkscan/net/libunbound wrkscan/net/libshout wrkscan/net/icecast wrkscan/net/bird/1,-doc wrkscan/net/bi

pthread_spin_unlock and ownership behaviour

2020-10-03 Thread Martijn van Duren
Back in 2012 kurt@ added an abort call for the undefined behaviour cases on pthread_mutex_unlock. This helped me a great deal in examining the cause of some weird behaviour in icinga (or in the case of openbsd, just plain crash). For shits and giggles I deceided to look into pthread_spin_unlock an