NetBSD Problem Report #59571
From www@netbsd.org Sun Aug 3 23:11:14 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 944AF1A923A
for <gnats-bugs@gnats.NetBSD.org>; Sun, 3 Aug 2025 23:11:14 +0000 (UTC)
Message-Id: <20250803231113.1BD0A1A923C@mollari.NetBSD.org>
Date: Sun, 3 Aug 2025 23:11:13 +0000 (UTC)
From: mrg@eterna23.net
Reply-To: mrg@eterna23.net
To: gnats-bugs@NetBSD.org
Subject: new bind crashes on arm64
X-Send-Pr-Version: www-1.0
>Number: 59571
>Category: bin
>Synopsis: new bind crashes on arm64
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Aug 03 23:15:00 +0000 2025
>Last-Modified: Mon Aug 25 16:20:01 +0000 2025
>Originator: matthew green
>Release: netbsd 11 and netbsd-current
>Organization:
people's front against (bozotic) www (softwar foundation)
>Environment:
both arm64el and arm64eb crash for me.
>Description:
with both -current and -11 branch, trying to start named on an arm64 host
crashes while it is starting up.
when running inside GDB, the same problem occurs though it is usually some
hundreds of entries into _cds_wfcq_enqueue() function, but due to the
heavily threaded nature, the crash isn't 100% identical every time.
one thing i've noticed is that the corrupted pointer is the same bit-pattern
though interpreted in opposite directions on arm64 big and little endian:
little endian:
(gdb) p tail
$1 = (struct cds_wfcq_tail *) 0x1
big endian:
(gdb) p tail
$9 = (struct cds_wfcq_tail *) 0x100000000000000
here's the crash and bt:
Thread 4 "isc-loop-0003" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 3884 of process 27833]
_cds_wfcq_enqueue (new_tail=0xf989b44182e8, tail=0x1, head=...)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/include/urcu/static/wfcqueue.h:217
217 return ___cds_wfcq_append(head, tail, new_tail, new_tail);
(gdb) bt
#0 _cds_wfcq_enqueue (new_tail=0xf989b44182e8, tail=0x1, head=...)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/include/urcu/static/wfcqueue.h:217
#1 _call_rcu (head=head@entry=0xf989b44182e8, func=<optimized out>, crdp=0x1)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu-call-rcu-impl.h:705
#2 0x0000000003010028 in urcu_memb_call_rcu (head=0xf989b44182e8, func=<optimized out>)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/src/urcu-call-rcu-impl.h:732
#3 0x0000f989b586c11c in dispentry_destroy (resp=0xf989b0728290) at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:445
#4 dns_dispentry_unref (ptr=0xf989b0728290) at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:453
#5 0x0000f989b586d11c in udp_connected (handle=0x0, eresult=ISC_R_FAMILYNOSUPPORT, arg=<optimized out>)
at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:1950
#6 0x0000f989b56bdeb4 in isc_nm_udpconnect (mgr=<optimized out>, local=local@entry=0xf989b07282e0, peer=peer@entry=0xf989b0728310,
cb=cb@entry=0xf989b586d020 <udp_connected>, cbarg=cbarg@entry=0xf989b0728290, timeout=<optimized out>)
at /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/netmgr/udp.c:844
#7 0x0000f989b586af18 in udp_dispatch_connect (disp=disp@entry=0xf989b4418210, resp=resp@entry=0xf989b0728290)
at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:1961
#8 0x0000f989b586ea1c in dns_dispatch_connect (resp=0xf989b0728290) at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:2086
#9 0x0000f989b5834964 in dns_request_create (requestmgr=0xf989b5656150, message=0xf989b0886290, srcaddr=srcaddr@entry=0xf989b2788340,
destaddr=destaddr@entry=0xf989b07281f0, transport=0x0, tlsctx_cache=0xf989b55e1610, options=options@entry=0, key=0x0, timeout=timeout@entry=16,
udptimeout=udptimeout@entry=5, udpretries=udpretries@entry=2, loop=0xf989b4c84588, cb=cb@entry=0xf989b57ec980 <notify_done>, arg=arg@entry=0xf989b0728150,
requestp=requestp@entry=0xf989b0728170) at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/request.c:643
#10 0x0000f989b57ec304 in notify_send_toaddr (arg=0xf989b0728150) at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/zone.c:12678
#11 0x0000f989b56e95a4 in isc__async_cb (handle=<optimized out>) at /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/async.c:113
#12 0x0000f989b56fc22c in uv__async_io (loop=0xf989b4c845a0, w=<optimized out>, events=<optimized out>)
at /usr/src/external/mit/libuv/lib/../dist/src/unix/async.c:163
#13 0x0000f989b56f1708 in uv__io_poll (loop=0xf989b4c845a0, timeout=<optimized out>) at /usr/src/external/mit/libuv/lib/../dist/src/unix/kqueue.c:390
#14 0x0000f989b56f9794 in uv_run (loop=0xf989b4c845a0, mode=UV_RUN_DEFAULT) at /usr/src/external/mit/libuv/lib/../dist/src/unix/core.c:406
#15 0x0000f989b56e4410 in loop_thread (arg=arg@entry=0xf989b4c84588) at /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/loop.c:330
#16 0x0000f989b56e96c0 in thread_body (wrap=0xf989b450b660) at /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/thread.c:87
#17 thread_run (wrap=0xf989b450b660) at /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/thread.c:102
#18 0x0000f989b54dddb4 in pthread__create_tramp (cookie=0xf989b44b4800) at /usr/src/lib/libpthread/pthread.c:605
#19 0x0000f989b47334e0 in __mknod50 () from /usr/lib/libc.so.12
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
we can see at this point that "disp" from frame 3 has become NULL already:
(gdb) f 3
#3 0x0000f989b586c11c in dispentry_destroy (resp=0xf989b0728290) at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:445
445 dns_dispatch_detach(&disp); /* DISPATCH001 */
(gdb) p disp
$1 = (dns_dispatch_t *) 0x0
but this may be OK, since it appears to be the final reference and is
expected to go away.. it does appear to be valid upon entry in frame #3,
dispentry_destroy(), but GDB on arm64 is making it hard to know without
adding direct instrumentation.. but it does appear to be something that
happens during the call to dns_dispatch_detach() in dispentry_destroy()
that the issue occurs.
>How-To-Repeat:
# /usr/sbin/named -f
crashes. see above for what GDB has revealed.
>Fix:
spent an hour or two in GDB and the sources and i don't know what
is happening, though it seems to be the first time a udp connection
is destroyed and goes via the udp_connected() -> dispentry_destroy()
path show in the description.
i haven't figured out where the pointer is corrupted, though it
may be something in the userspace-rcu library as most of the code
below dns_dispatch_detach() is in here.
>Audit-Trail:
From: matthew green <mrg@eterna23.net>
To: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: re: bin/59571: new bind crashes on arm64
Date: Mon, 04 Aug 2025 15:37:08 +1000
more info:
i had a look at the urcu config.h and noticed an option to try
(CONFIG_RCU_USE_ATOMIC_BUILTINS) and while it didn't fix anything
it did give me a different crash in this udp disconnect path:
Thread 5 "isc-loop-0004" received signal SIGBUS, Bus error.
[Switching to LWP 26700 of process 7299]
0x000000000edb9dac in __aarch64_swp8_acq_rel ()
(gdb) bt
#0 0x000000000edb9dac in __aarch64_swp8_acq_rel ()
#1 0x000000000ed9e0c4 in ___cds_wfcq_append (new_tail=3D0xfc565553b4e8, n=
ew_head=3D0xfc565553b4e8, tail=3D0x1, u_head=3D...)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/i=
nclude/urcu/static/wfcqueue.h:182
#2 _cds_wfcq_enqueue (new_tail=3D0xfc565553b4e8, tail=3D0x1, head=3D...)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/i=
nclude/urcu/static/wfcqueue.h:217
#3 _call_rcu (head=3Dhead@entry=3D0xfc565553b4e8, func=3D<optimized out>,=
crdp=3D0x1)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/s=
rc/urcu-call-rcu-impl.h:705
#4 0x000000000ed9ffbc in urcu_memb_call_rcu (head=3D0xfc565553b4e8, func=3D=
<optimized out>)
at /usr/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/s=
rc/urcu-call-rcu-impl.h:732
#5 0x0000fc5658dec0dc in dispentry_destroy (resp=3D0xfc56535f63d0) at /us=
r/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:445
#6 dns_dispentry_unref (ptr=3D0xfc56535f63d0) at /usr/src/external/mpl/bi=
nd/lib/libdns/../../dist/lib/dns/dispatch.c:453
#7 0x0000fc5658ded0dc in udp_connected (handle=3D0x0, eresult=3DISC_R_FAM=
ILYNOSUPPORT, arg=3D<optimized out>)
at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c=
:1950
#8 0x0000fc5658c3deb4 in isc_nm_udpconnect (mgr=3D<optimized out>, local=3D=
local@entry=3D0xfc56535f6420, peer=3Dpeer@entry=3D0xfc56535f6450,
cb=3Dcb@entry=3D0xfc5658decfe0 <udp_connected>, cbarg=3Dcbarg@entry=3D=
0xfc56535f63d0, timeout=3D<optimized out>)
at /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/netmgr/udp=
.c:844
#9 0x0000fc5658deaed8 in udp_dispatch_connect (disp=3Ddisp@entry=3D0xfc56=
5553b410, resp=3Dresp@entry=3D0xfc56535f63d0)
at /usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c=
:1961
#10 0x0000fc5658dee9dc in dns_dispatch_connect (resp=3D0xfc56535f63d0) at =
/usr/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/dispatch.c:2086
#11 0x0000fc5658db4924 in dns_request_create (requestmgr=3D0xfc5658bdb150,=
message=3D0xfc5653600510, srcaddr=3Dsrcaddr@entry=3D0xfc5654fed340,
destaddr=3Ddestaddr@entry=3D0xfc56535f6330, transport=3D0x0, tlsctx_ca=
che=3D0xfc5658b21610, options=3Doptions@entry=3D0, key=3D0x0, timeout=3Dti=
meout@entry=3D16,
udptimeout=3Dudptimeout@entry=3D5, udpretries=3Dudpretries@entry=3D2, =
loop=3D0xfc5658232cb0, cb=3Dcb@entry=3D0xfc5658d6c980 <notify_done>, arg=3D=
arg@entry=3D0xfc56535f6290,
requestp=3Drequestp@entry=3D0xfc56535f62b0) at /usr/src/external/mpl/b=
ind/lib/libdns/../../dist/lib/dns/request.c:643
#12 0x0000fc5658d6c304 in notify_send_toaddr (arg=3D0xfc56535f6290) at /us=
r/src/external/mpl/bind/lib/libdns/../../dist/lib/dns/zone.c:12678
#13 0x0000fc5658c69574 in isc__async_cb (handle=3D<optimized out>) at /usr=
/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/async.c:113
#14 0x0000fc5658c7c1fc in uv__async_io (loop=3D0xfc5658232cc8, w=3D<optimi=
zed out>, events=3D<optimized out>)
at /usr/src/external/mit/libuv/lib/../dist/src/unix/async.c:163
#15 0x0000fc5658c716d8 in uv__io_poll (loop=3D0xfc5658232cc8, timeout=3D<o=
ptimized out>) at /usr/src/external/mit/libuv/lib/../dist/src/unix/kqueue.=
c:390
#16 0x0000fc5658c79764 in uv_run (loop=3D0xfc5658232cc8, mode=3DUV_RUN_DEF=
AULT) at /usr/src/external/mit/libuv/lib/../dist/src/unix/core.c:406
#17 0x0000fc5658c64410 in loop_thread (arg=3Darg@entry=3D0xfc5658232cb0) a=
t /usr/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/loop.c:330
#18 0x0000fc5658c69690 in thread_body (wrap=3D0xfc5657c12680) at /usr/src/=
external/mpl/bind/lib/libisc/../../dist/lib/isc/thread.c:87
#19 thread_run (wrap=3D0xfc5657c12680) at /usr/src/external/mpl/bind/lib/l=
ibisc/../../dist/lib/isc/thread.c:102
#20 0x0000fc5658a5ddb4 in pthread__create_tramp (cookie=3D0xfc5656e06400) =
at /usr/src/lib/libpthread/pthread.c:605
#21 0x0000fc5657cc3500 in __mknod50 () from /usr/lib/libc.so.12
though asn you can see at frame 1, "tail=3D0x1" is the same problem.
however, this seems to be *earlier* than the prior failure? ie,
it seems to be in the "set" part of the cds_wfcq queue ops, vs the
following "get" that crashed previously.
still not fully understanding ths urcu code.
.mrg.
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
mrg@eterna23.net
Subject: Re: bin/59571: new bind crashes on arm64
Date: Mon, 4 Aug 2025 09:01:20 +0300
--Apple-Mail=_4AEAE92A-FDF7-4499-9D20-468EF029E461
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
I would start by running the urcu tests... Perhaps something is wrong =
with the aarch64 atomics?
christos=
--Apple-Mail=_4AEAE92A-FDF7-4499-9D20-468EF029E461
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCaJBMsAAKCRBxESqxbLM7
OmRyAKCynxuEdylyH3fCfOi0Rpb83i2BzQCg8NMkEd8z79TDqkay2Af6eUyp4pQ=
=MDyj
-----END PGP SIGNATURE-----
--Apple-Mail=_4AEAE92A-FDF7-4499-9D20-468EF029E461--
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/59571: new bind crashes on arm64
Date: Mon, 4 Aug 2025 06:09:55 -0000 (UTC)
mrg@eterna23.net (matthew green) writes:
>more info:
The problem seems to be older:
on earmv7hf:
Core was generated by `named'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00f86e5c in ___cds_wfcq_append (new_tail=0x6d0280cc,
new_head=0x6d0280cc, tail=0x6e9d4d88, u_head=...)
at /scratch/netbsd-current/src/external/lgpl2/userspace-rcu/lib/liburcu-memb/../../dist/include/urcu/static/wfcqueue.h:193
But that's:
# named -v
BIND 9.20.9 (Stable Release) <id:98f2a5b>
# ls -l /usr/sbin/named
-r-xr-xr-x 1 root wheel 707000 May 31 05:15 /usr/sbin/named
From: matthew green <mrg@eterna23.net>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
gnats-bugs@netbsd.org
Subject: re: bin/59571: new bind crashes on arm64
Date: Mon, 04 Aug 2025 16:46:26 +1000
> I would start by running the urcu tests... Perhaps something is wrong
> with the aarch64 atomics?
got a cheat sheet for this? i've never looked at this code before
and it is ... macroriffic.
thanks.
.mrg.
From: matthew green <mrg@eterna23.net>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
gnats-bugs@netbsd.org
Subject: re: bin/59571: new bind crashes on arm64
Date: Mon, 04 Aug 2025 16:47:49 +1000
interestingly, there's another report of ucru crashes on hppa:
https://mail-index.netbsd.org/netbsd-users/2025/08/03/msg032919.html
but this is in the utils, not named itself.
.mrg.
From: Tobias Nygren <tnn@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: mrg@eterna23.net
Subject: Re: bin/59571: new bind crashes on arm64
Date: Mon, 4 Aug 2025 11:03:33 +0200
This is likely a duplicate of bin/59035.
I think there are problems with the ELF constructors in the library
which should initialize thread_call_rcu_data but for some reason don't.
I posted a workaround in that PR which helps for me.
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/59571: new bind crashes on arm64
Date: Mon, 4 Aug 2025 10:58:36 -0000 (UTC)
gnats-admin@NetBSD.org ("Tobias Nygren via gnats") writes:
> This is likely a duplicate of bin/59035.
> I think there are problems with the ELF constructors in the library
> which should initialize thread_call_rcu_data but for some reason don't.
> I posted a workaround in that PR which helps for me.
Possible, but then it also affects other architectures.
From: Tobias Nygren <tnn@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/59571: new bind crashes on arm64
Date: Mon, 4 Aug 2025 14:27:43 +0200
On Mon, 4 Aug 2025 11:00:02 +0000 (UTC)
"Michael van Elst via gnats" <gnats-admin@NetBSD.org> wrote:
> Possible, but then it also affects other architectures.
True and somewhat implies an md rtld issue to me.
Another data point is that it works fine as long as liburcu is built as
a dynamic library. We build it statically which upstream might not test
much so that could be something to look into.
Anyway, the fact that it works when dynamically linked suggests to me
the synchronization code in the library is ok.
From: matthew green <mrg@eterna23.net>
To: Tobias Nygren <tnn@NetBSD.org>
Cc: gnats-bugs@netbsd.org
Subject: re: bin/59571: new bind crashes on arm64
Date: Tue, 05 Aug 2025 08:34:27 +1000
Tobias Nygren writes:
> This is likely a duplicate of bin/59035.
> I think there are problems with the ELF constructors in the library
> which should initialize thread_call_rcu_data but for some reason don't.
> I posted a workaround in that PR which helps for me.
indeed, this appears to fix it for me..
.mrg.
From: matthew green <mrg@eterna23.net>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: re: bin/59571: new bind crashes on arm64
Date: Tue, 05 Aug 2025 10:45:11 +1000
having another look i see that the code i see it works around
lack of working ctor with:
void rcu_register_thread(void)
{
...
rcu_init(); /* In case gcc does not support constructor attrib=
ute */
rcu_init() is lacking concurrent support, but shouldn't matter
because all threads will have the same answer, and on netbsd
it will be rcu_sys_membarrier_status(false) (since we don't have
a membarrier(2).)
it should end up doing very little.. so i'm confused about what
is happening here. is the ctor running *too early* and trying
to access other state not available - some other ctor needed?
would be nice to properly understand what is going wrong here,
i notice that there is also a dtor in this file, that calls a
moderately complex function -- urcu_call_rcu_exit() -- which
handles safe teardown of worker threads.
.mrg.
From: matthew green <mrg@eterna23.net>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: re: bin/59571: new bind crashes on arm64
Date: Wed, 06 Aug 2025 09:20:53 +1000
i wonder if we could work around this by turning off the
RCU_MEMBARRIER version and forcing RCU_MB version, which is
effectively the one we end up using anyway, since membarrier()
is a linux feature only.
i tested this, seems to work fine. since it involves no code
changes to upstream, just this small diff (which includes a
fix for liburcu-signal/Makefile that doesn't matter.)
note this isn't a fix for whatever the underlying problem is,
but i think this is better anyway since it avoids code that
won't even run on netbsd being compiled in at all. (if we
go with this, and close this PR, a separate PR for the other
problem should be created.)
.mrg.
Index: lgpl2/userspace-rcu/lib/liburcu/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/src/external/lgpl2/userspace-rcu/lib/liburcu/Makefile,v
retrieving revision 1.1
diff -p -u -r1.1 Makefile
--- lgpl2/userspace-rcu/lib/liburcu/Makefile 17 Jan 2025 16:07:26 -0000 1.=
1
+++ lgpl2/userspace-rcu/lib/liburcu/Makefile 5 Aug 2025 23:17:51 -0000
@@ -4,7 +4,7 @@
=
LIBISPRIVATE=3Dyes
LIB=3Durcu
-CPPFLAGS+=3D-DRCU_MEMBARRIER
+CPPFLAGS+=3D-DRCU_MB
=
SRCS+=3D urcu.c urcu-pointer.c compat_arch.c compat_futex.c
=
Index: lgpl2/userspace-rcu/lib/liburcu-signal/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/src/external/lgpl2/userspace-rcu/lib/liburcu-signal/Mak=
efile,v
retrieving revision 1.1
diff -p -u -r1.1 Makefile
--- lgpl2/userspace-rcu/lib/liburcu-signal/Makefile 17 Jan 2025 16:07:27 -=
0000 1.1
+++ lgpl2/userspace-rcu/lib/liburcu-signal/Makefile 5 Aug 2025 23:17:51 -0=
000
@@ -3,7 +3,7 @@
.include <bsd.own.mk>
=
LIBISPRIVATE=3Dyes
-LIB=3Durcu-mb
+LIB=3Durcu-signal
CPPFLAGS+=3D-DRCU_SIGNAL -DRCU_MEMBARRIER
=
SRCS+=3D urcu.c urcu-pointer.c compat_arch.c compat_futex.c
Index: mpl/bind/Makefile.inc
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/src/external/mpl/bind/Makefile.inc,v
retrieving revision 1.17
diff -p -u -r1.17 Makefile.inc
--- mpl/bind/Makefile.inc 14 Jul 2025 10:25:52 -0000 1.17
+++ mpl/bind/Makefile.inc 5 Aug 2025 23:17:51 -0000
@@ -17,7 +17,7 @@ CWARNFLAGS.clang+=3D -Wno-unused-value -Wn
LIBUVDIR=3D ${NETBSDSRCDIR}/external/mit/libuv
LIBUVOBJDIR!=3D cd ${LIBUVDIR}/lib && ${PRINTOBJDIR}
LIBURCUDIR=3D ${NETBSDSRCDIR}/external/lgpl2/userspace-rcu
-LIBURCUMEMBOBJDIR!=3D cd ${LIBURCUDIR}/lib/liburcu-memb && ${PRINTOBJDI=
R}
+LIBURCUMBOBJDIR!=3D cd ${LIBURCUDIR}/lib/liburcu-mb && ${PRINTOBJDIR}
LIBURCUCDSOBJDIR!=3D cd ${LIBURCUDIR}/lib/liburcu-cds && ${PRINTOBJDIR}
LIBURCUCOMMONOBJDIR!=3D cd ${LIBURCUDIR}/lib/liburcu-common && ${PRINTO=
BJDIR}
CPPFLAGS+=3D -I${LIBUVDIR}/dist/include
@@ -57,7 +57,7 @@ DBG=3D-g3 -gstabs
.if defined(NAMED_DEBUG)
LDADD+=3D -lisccfg_g -ldns_g -lns_g
LDADD+=3D -lisccc_g -lisc_g
-LDADD+=3D -L${LIBURCUMEMBOBJDIR} -lurcu-memb_g
+LDADD+=3D -L${LIBURCUMBOBJDIR} -lurcu-mb_g
LDADD+=3D -L${LIBURCUCDSOBJDIR} -lurcu-cds_g
LDADD+=3D -L${LIBURCUCOMMONOBJDIR} -lurcu-common_g
LDADD+=3D -L${LIBUVOBJDIR} -luv_g
@@ -66,7 +66,7 @@ LDADD+=3D -lexecinfo_g -lelf_g -lkvm_g -l
LDADD+=3D -lisccfg -ldns -lns
DPADD+=3D ${LIBISCCFG} ${LIBDNS} ${LIBNS}
LDADD+=3D -lisccc -lisc =
-LDADD+=3D -L${LIBURCUMEMBOBJDIR} -lurcu-memb
+LDADD+=3D -L${LIBURCUMBOBJDIR} -lurcu-mb
LDADD+=3D -L${LIBURCUCDSOBJDIR} -lurcu-cds
LDADD+=3D -L${LIBURCUCOMMONOBJDIR} -lurcu-common
LDADD+=3D -L${LIBUVOBJDIR} -luv
Index: mpl/bind/bind2netbsd
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/src/external/mpl/bind/bind2netbsd,v
retrieving revision 1.10
diff -p -u -r1.10 bind2netbsd
--- mpl/bind/bind2netbsd 21 May 2025 14:47:34 -0000 1.10
+++ mpl/bind/bind2netbsd 5 Aug 2025 23:17:51 -0000
@@ -43,7 +43,7 @@
=
# U=3D/usr/src/external/lgpl2/userspace-rcu
# OBJ=3D/obj.amd64-x86_64
-# env LIBURCU_CFLAGS=3D"-I$U/include -I$U/dist/include" LIBURCU_LIBS=3D"-=
L$U/lib/liburcu-memb$OBJ -lurcu-memb -L$U/lib/liburcu-cds$OBJ -lurcu-cds -=
L$U/lib/liburcu-common$OBJ -lurcu-common" ./configure --enable-querytrace =
--enable-fixed-rrset
+# env LIBURCU_CFLAGS=3D"-I$U/include -I$U/dist/include" LIBURCU_LIBS=3D"-=
L$U/lib/liburcu-memb$OBJ -lurcu-mb -L$U/lib/liburcu-cds$OBJ -lurcu-cds -L$=
U/lib/liburcu-common$OBJ -lurcu-common" ./configure --enable-querytrace --=
enable-fixed-rrset --with-liburcu=3Dmb
=
# $ run make
# - use the binclude4netbsd to create and import the new headers in
Index: mpl/bind/include/config.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/src/external/mpl/bind/include/config.h,v
retrieving revision 1.23
diff -p -u -r1.23 config.h
--- mpl/bind/include/config.h 17 Jul 2025 19:01:47 -0000 1.23
+++ mpl/bind/include/config.h 5 Aug 2025 23:17:52 -0000
@@ -565,10 +565,10 @@
#define RCU_FLAVOR "liburcu"
=
/* Build with mb Userspace-RCU flavor */
-/* #undef RCU_MB */
+#define RCU_MB 1
=
/* Build with membarrier Userspace-RCU flavor */
-#define RCU_MEMBARRIER 1
+/* #undef RCU_MEMBARRIER */
=
/* Build with QSBR Userspace-RCU flavor */
/* #undef RCU_QSBR */
From: "matthew green" <mrg@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59571 CVS commit: src/external
Date: Sun, 24 Aug 2025 04:24:17 +0000
Module Name: src
Committed By: mrg
Date: Sun Aug 24 04:24:17 UTC 2025
Modified Files:
src/external/lgpl2/userspace-rcu/lib/liburcu: Makefile
src/external/lgpl2/userspace-rcu/lib/liburcu-signal: Makefile
src/external/mpl/bind: Makefile.inc bind2netbsd
src/external/mpl/bind/include: config.h
Log Message:
named: use liburcu-mb on netbsd.
make libucru use RCU_MB by default.
fix the liburcu-signal library name (built but unused.)
on netbsd, RCU_MEMBARRIER is identical to RCU_MB, except with some
extra code run at init time (in a ctor) and then falling back to
being identical because that code ultimately hard coded to fail.
this reduces the startup code very minimally, and avoids using
a linux-specific version (that has fallback for old linux that
works on netbsd.) it also avoids the problem in PR#59571, though
the problem seen there is 100% still a problem, and i'll file a
separate PR about that problem. (i'm hoping to provide a minimal
test case, but so far it is not very small.)
XXX: pullup-11.
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 \
src/external/lgpl2/userspace-rcu/lib/liburcu/Makefile
cvs rdiff -u -r1.1 -r1.2 \
src/external/lgpl2/userspace-rcu/lib/liburcu-signal/Makefile
cvs rdiff -u -r1.17 -r1.18 src/external/mpl/bind/Makefile.inc
cvs rdiff -u -r1.10 -r1.11 src/external/mpl/bind/bind2netbsd
cvs rdiff -u -r1.23 -r1.24 src/external/mpl/bind/include/config.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/59571 CVS commit: [netbsd-11] src/external
Date: Mon, 25 Aug 2025 16:17:26 +0000
Module Name: src
Committed By: martin
Date: Mon Aug 25 16:17:26 UTC 2025
Modified Files:
src/external/lgpl2/userspace-rcu/lib/liburcu [netbsd-11]: Makefile
src/external/lgpl2/userspace-rcu/lib/liburcu-signal [netbsd-11]:
Makefile
src/external/mpl/bind [netbsd-11]: Makefile.inc bind2netbsd
src/external/mpl/bind/include [netbsd-11]: config.h
Log Message:
Pull up following revision(s) (requested by mrg in ticket #16):
external/lgpl2/userspace-rcu/lib/liburcu-signal/Makefile: revision 1.2
external/mpl/bind/bind2netbsd: revision 1.11
external/lgpl2/userspace-rcu/lib/liburcu/Makefile: revision 1.2
external/mpl/bind/include/config.h: revision 1.24
external/mpl/bind/Makefile.inc: revision 1.18
named: use liburcu-mb on netbsd.
make libucru use RCU_MB by default.
fix the liburcu-signal library name (built but unused.)
on netbsd, RCU_MEMBARRIER is identical to RCU_MB, except with some
extra code run at init time (in a ctor) and then falling back to
being identical because that code ultimately hard coded to fail.
this reduces the startup code very minimally, and avoids using
a linux-specific version (that has fallback for old linux that
works on netbsd.) it also avoids the problem in PR#59571, though
the problem seen there is 100% still a problem, and i'll file a
separate PR about that problem. (i'm hoping to provide a minimal
test case, but so far it is not very small.)
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.1.2.1 \
src/external/lgpl2/userspace-rcu/lib/liburcu/Makefile
cvs rdiff -u -r1.1 -r1.1.2.1 \
src/external/lgpl2/userspace-rcu/lib/liburcu-signal/Makefile
cvs rdiff -u -r1.17 -r1.17.2.1 src/external/mpl/bind/Makefile.inc
cvs rdiff -u -r1.10 -r1.10.2.1 src/external/mpl/bind/bind2netbsd
cvs rdiff -u -r1.23 -r1.23.2.1 src/external/mpl/bind/include/config.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2025
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home