PR/59237 CVS commit: [netbsd-10] src

"Martin Husemann" <[email protected]>
Newsgroups gmane.os.netbsd.bugs
Message-ID <[email protected]>
The following reply was made to PR lib/59237; it has been noted by GNATS.

From: "Martin Husemann" <[email protected]>
To: [email protected]
Cc: 
Subject: PR/59237 CVS commit: [netbsd-10] src
Date: Sat, 27 Jun 2026 19:20:12 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sat Jun 27 19:20:12 UTC 2026
 
 Modified Files:
 	src/external/cddl/osnet/dist/lib/libuutil/common [netbsd-10]:
 	    libuutil_impl.h uu_avl.c uu_list.c uu_misc.c
 	src/lib/libbsdmalloc [netbsd-10]: malloc.c
 	src/lib/libc/gen [netbsd-10]: arc4random.c
 	src/lib/libc/stdlib [netbsd-10]: malloc.c
 
 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #1288):
 
 	external/cddl/osnet/dist/lib/libuutil/common/uu_list.c: revision 1.2
 	lib/libc/gen/arc4random.c: revision 1.51
 	external/cddl/osnet/dist/lib/libuutil/common/uu_misc.c: revision 1.5
 	lib/libbsdmalloc/malloc.c: revision 1.13
 	external/cddl/osnet/dist/lib/libuutil/common/uu_avl.c: revision 1.2
 	external/cddl/osnet/dist/lib/libuutil/common/libuutil_impl.h: revision 1.2
 	lib/libc/stdlib/malloc.c: revision 1.61
 
 arc4random(3): Use mutex_init, not mutex_unlock, in child post-fork.
 
 Using mutex_unlock may try to wake a thread that doesn't exist in the
 child, which could lead to trouble such as crash or deadlock.  But
 since the child is single-threaded, it is safe to just reinitialize
 the mutex memory anyway.
 
 PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
 libbsdmalloc: Use mutex_init, not mutex_unlock, in child post-fork.
 
 Using mutex_unlock may try to wake a thread that doesn't exist in the
 child, which could lead to trouble such as crash or deadlock.  But
 since the child is single-threaded, it is safe to just reinitialize
 the mutex memory anyway.
 
 PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
 osnet libuutil: Use mutex_init, not mutex_unlock, in child post-fork.
 
 Using mutex_unlock may try to wake a thread that doesn't exist in the
 child, which could lead to trouble such as crash or deadlock.  But
 since the child is single-threaded, it is safe to just reinitialize
 the mutex memory anyway.
 
 PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
 old malloc(3): Use mutex_init, not mutex_unlock, in child post-fork.
 
 Using mutex_unlock may try to wake a thread that doesn't exist in the
 child, which could lead to trouble such as crash or deadlock.  But
 since the child is single-threaded, it is safe to just reinitialize
 the mutex memory anyway.
 
 PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.1.1.1 -r1.1.1.1.56.1 \
     src/external/cddl/osnet/dist/lib/libuutil/common/libuutil_impl.h \
     src/external/cddl/osnet/dist/lib/libuutil/common/uu_list.c
 cvs rdiff -u -r1.1.1.2 -r1.1.1.2.12.1 \
     src/external/cddl/osnet/dist/lib/libuutil/common/uu_avl.c
 cvs rdiff -u -r1.4 -r1.4.12.1 \
     src/external/cddl/osnet/dist/lib/libuutil/common/uu_misc.c
 cvs rdiff -u -r1.2.106.2 -r1.2.106.3 src/lib/libbsdmalloc/malloc.c
 cvs rdiff -u -r1.33.2.1 -r1.33.2.2 src/lib/libc/gen/arc4random.c
 cvs rdiff -u -r1.60 -r1.60.6.1 src/lib/libc/stdlib/malloc.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.