NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: port-sh3/60773: sh3 __sync_val_compare_and_swap_1 test failures



> Date: Thu, 24 Sep 2026 15:14:33 +0300
> From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
> 
> Tangential to the topic at hand, but since I had to read the code, I
> might as well ask - why is atomic_init_testset.c statically
> initializes the _fn variables to _up functions only immediately to set
> them to _mp functions in __libc_atomic_init (and later set them back
> to _up if we are on a UP system and rasctl(2) was successful)?  Any
> reason not to init the vars to _mp directly?  _mp functions use the
> locks array that is statically initialized, so it should be safe to
> call them before __libc_atomic_init, shouldn't it?

The code was originally added with no initializer by ad@ in 2008,
under the assumption the constructor would always run before use, and
the constructor started with the always-safe _mp variants before
deciding on the basis of sysctl whether to use the cheaper _up
variants if safe:

https://mail-index.netbsd.org/source-changes/2008/02/09/msg002110.html
https://nxr.netbsd.org/xref/src/common/lib/libc/atomic/atomic_init_testset.c?r=1.1#63

skrll@ added the initializer because the constructor didn't always run
before use, but it's unclear why he chose _up:

https://mail-index.netbsd.org/source-changes/2009/01/30/msg216500.html
https://nxr.netbsd.org/xref/src/common/lib/libc/atomic/atomic_init_testset.c?r=1.6#63

This actually caused some trouble for us later on with the _up
variants getting inadvertently used in ld.elf_so until martin@ changed
it to call __libc_atomic_init in 2023:

PR lib/57628: multithread programs may deadlock in ld.elf_so (sparc on
sparc64)
https://gnats.NetBSD.org/57628
https://mail-index.netbsd.org/source-changes/2023/10/03/msg147830.html
https://nxr.netbsd.org/xref/src/libexec/ld.elf_so/rtld.c?r=1.216#72

> If there's a reason why it's done in this way, it probably warrants a
> comment.

I think the reason is `hysterical raisins' and this warrants a commit
to make the static initializers use _mp and then delete the
now-redundant initial assignments in __libc_atomic_init.



Home | Main Index | Thread Index | Old Index