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

["Martin Husemann" <martin%netbsd.org@localhost>]

The following reply was made to PR kern/60281; it has been noted by GNATS.

From: "Martin Husemann" <martin%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/60281 CVS commit: [netbsd-10] src
Date: Sat, 27 Jun 2026 15:25:57 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sat Jun 27 15:25:57 UTC 2026
 
 Modified Files:
 	src/distrib/sets/lists/debug [netbsd-10]: mi
 	src/distrib/sets/lists/tests [netbsd-10]: mi
 	src/sys/opencrypto [netbsd-10]: cryptodev.c cryptodev_internal.h
 	    cryptosoft.c ocryptodev.c
 	src/sys/rump/dev/lib/libopencrypto [netbsd-10]: OPENCRYPTO.ioconf
 	    opencrypto_component.c
 	src/tests/crypto/opencrypto [netbsd-10]: Makefile t_opencrypto.sh
 Added Files:
 	src/tests/crypto/opencrypto [netbsd-10]: h_thread.c
 
 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #1278):
 
 	sys/opencrypto/cryptodev.c: revision 1.130
 	sys/opencrypto/cryptodev.c: revision 1.131
 	sys/opencrypto/cryptodev.c: revision 1.132
 	sys/opencrypto/cryptodev.c: revision 1.133
 	tests/crypto/opencrypto/Makefile: revision 1.6
 	sys/opencrypto/cryptosoft.c: revision 1.67
 	sys/opencrypto/ocryptodev.c: revision 1.19
 	tests/crypto/opencrypto/h_thread.c: revision 1.1
 	sys/rump/dev/lib/libopencrypto/OPENCRYPTO.ioconf: revision 1.2
 	tests/crypto/opencrypto/h_thread.c: revision 1.2
 	sys/rump/dev/lib/libopencrypto/opencrypto_component.c: revision 1.7
 	tests/crypto/opencrypto/t_opencrypto.sh: revision 1.12
 	tests/crypto/opencrypto/t_opencrypto.sh: revision 1.13
 	sys/opencrypto/cryptodev_internal.h: revision 1.5
 	tests/crypto/opencrypto/t_opencrypto.sh: revision 1.14
 	sys/opencrypto/cryptodev.c: revision 1.129
 	distrib/sets/lists/debug/mi: revision 1.512
 	distrib/sets/lists/tests/mi: revision 1.1417
 
 Add a threaded test to test for races in cryptodev.
 new thread cryptodev test
 
 crypto(4): Make test more reliable, and test more.
 1. New thread to concurrently create and destroy sessions.
    (There should really be multiple threads to concurrently compete
    with each other to create and destroy sessions, but this is
    already surfacing more crashes, as I expected.)
 2. Handle EBUSY in CIOCFSESSION in case there is a concurrent
    CIOCCRYPT, as we are trying to test.
 3. Handle CIOCCRYPT failure if a concurrent CIOCFSESSION beat us to
    it, as we are trying to test
 4. Dump core if the threads get stuck for too long.
 5. Provide stack traces from the test program or rump server if they
    dump core.
 PR kern/60281: crypto(4): bugs in reference counting and test
 
 crypto(4): Take reference _before_ releasing the lock.
 
 Otherwise nothing ensures the object will still exist by the time we
 try to take the reference.
 
 Also guard against too many references, since this is only a 32-bit
 reference count.
 PR kern/60281: crypto(4): bugs in reference counting and test
 
 crypto(4): Fix missing membars on reference count release.
 
 If two threads A and B both hold references, we need to ensure that
 memory ops in thread A happen before memory free in thread B in:
 thread A                thread B                notes
 --------                --------                -----
 memory ops
 atomic_dec(&refcnt)                             goes from 2 to 1
                         atomic_dec(&refcnt)     goes from 1 to 0
                         memory free
 
 This requires a membar_release in thread A before the atomic_dec (or
 atomic_dec with memory_order_release), and a membar_acquire in thread
 B after the atomic_dec is found to have brought the reference count
 down to zero (or atomic_dec wiht memory_order_acquire).
 kern/60281: crypto(4): bugs in reference counting and test
 
 crypto(4): Disentangle initialization and attachment goo.
 Lotta unnecessary boilerplate deleted here!
 
 Disable module unloading: can't be done safely.  Explain precisely
 why it can't be done safely.
 
 This also fixes annoying `crypto: unable to register devsw, error 17'
 messages in rump dmesg by having exactly one path to devsw_attach.
 PR kern/60281: crypto(4): bugs in reference counting and test
 
 crypto(4): Omit needless locking in fcrypt_dtor.
 
 We must have exclusive access to the object for this function to work
 at all, so if removing the locks appeared to cause issues, it would
 necessarily happen only because there is a bug somewhere else.
 PR kern/60281: crypto(4): bugs in reference counting and test
 crypto(4): Nix spurious mutex_exit; add missing bounds checks.
 
 Consistently use `foo = kmem_alloc(n * sizeof(*foo), ...)' instead of
 `sizeof(struct whatever_foo_is)'.  Makes it easier for a reader to
 notice a discrepancy this way.
 
 Move CRYPTODEV_OPS_MAX to cryptodev_internal.h so it can be used by
 the compat ocryptodev.c shims too.  I think this is waaaaaaaaaaaaay
 too high, by the way.  For example, it looks like qat(4) puts a limit
 of 16384 on the number of sessions.  Other devices like hifn(4) look
 like they're limited to numbers of sessions ranging from 2 to around
 256.
 PR kern/60281: crypto(4): bugs in reference counting and test
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.394.2.15 -r1.394.2.16 src/distrib/sets/lists/debug/mi
 cvs rdiff -u -r1.1238.2.19 -r1.1238.2.20 src/distrib/sets/lists/tests/mi
 cvs rdiff -u -r1.125.4.1 -r1.125.4.2 src/sys/opencrypto/cryptodev.c
 cvs rdiff -u -r1.3.40.1 -r1.3.40.2 src/sys/opencrypto/cryptodev_internal.h
 cvs rdiff -u -r1.64.4.2 -r1.64.4.3 src/sys/opencrypto/cryptosoft.c
 cvs rdiff -u -r1.17.4.1 -r1.17.4.2 src/sys/opencrypto/ocryptodev.c
 cvs rdiff -u -r1.1 -r1.1.52.1 \
     src/sys/rump/dev/lib/libopencrypto/OPENCRYPTO.ioconf
 cvs rdiff -u -r1.6 -r1.6.24.1 \
     src/sys/rump/dev/lib/libopencrypto/opencrypto_component.c
 cvs rdiff -u -r1.5 -r1.5.8.1 src/tests/crypto/opencrypto/Makefile
 cvs rdiff -u -r0 -r1.2.4.2 src/tests/crypto/opencrypto/h_thread.c
 cvs rdiff -u -r1.9 -r1.9.8.1 src/tests/crypto/opencrypto/t_opencrypto.sh
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.