sys_semop() retries redo the semop copyin() - why?

[Martin Husemann <martin%duskware.de@localhost>]

I am looking at PR 59352, trying to add compat_netbsd32 support for
semtimedop().

I noticed a very strange retry loop in do_semop() where it waits for
other processes and then redoes the whole copyin() of the semops passed
to the system call - which sounds bogus to me, but I might be missing
something.

Making the restart loop happen only after the initial copyin() will make
code sharing with the netbsd32 emulation a lot easier - so is the following
patch OK or is there some reason the userland records need to be copied in
again?

Martin
P.S.: this is a bit hard to read in a context diff - it just moves the
restart label down after the copyin().


Index: sysv_sem.c
===================================================================
RCS file: /cvsroot/src/sys/kern/sysv_sem.c,v
retrieving revision 1.101
diff -c -u -p -r1.101 sysv_sem.c
--- sysv_sem.c	6 Oct 2024 22:15:33 -0000	1.101
+++ sysv_sem.c	29 Apr 2025 16:29:57 -0000
@@ -828,7 +828,6 @@ do_semop(struct lwp *l, int usemid, stru
 		mutex_exit(p->p_lock);
 	}
 
-restart:
 	if (nsops <= SMALL_SOPS) {
 		sops = small_sops;
 	} else if (nsops <= seminfo.semopm) {
@@ -848,6 +847,7 @@ restart:
 		return error;
 	}
 
+restart:
 	mutex_enter(&semlock);
 	/* In case of reallocation, we will wait for completion */
 	while (__predict_false(sem_realloc_state))